Proyecto Redes: Parte IX

Hoy no voy a hablar de un bloqueo como los mencionados, sino que quiero contar algo mas "ligero" y que quedaria fuera por estar en desuso aparentemente (en realidad no es asi y ya veremos por qué), que es el uso de proxys.

Recordamos que un proxy es un equipo que actua de intermediario entre el servidor de destino y el nuestro, enmascarando nuestra dirección, o sirviendo para redireccionar el tráfico.

En el caso que hoy nos ocupa, veremos lo que ocurre con los bloqueos regionales en un servidor.

Esta clase de bloqueo se usa en las paginas que no dan servicio a determinados paises (o que no permiten el acceso a cierto contenido).

El uso de proxys se suele aplicar solo a un cierto tipo de trafico, principalmente trafico web (HTTP y/o HTTPS) y no afecta al resto de las conexiones, aunque algunos programas permitan tambien aplicarlo a determinados protocolos (uTorrent permite aplicarlo de manera independiente a trackers y a peers).

Existen varias formas de acceder a una pagina usando un proxy, mediante un proxy integrado en una pagina web (por ejemplo hidemyass.com) o configurandolo a traves de las opciones de Internet de nuestro sistema operativo.

Para configurarlo, vais a vuestro panel de control y ahi a las opciones de Internet.

En la pestaña Conexiones aparece una opcion que es Configuracion de LAN. Aunque no se trate de la red local, funciona igual.

Ahi marcamos que queremos usar un proxy e introducimos la dirección que queremos usar. Se pueden usar distintos proxys segun el tipo de trafico presionando en Opciones avanzadas:

Podeis encontrar una lista de proxys en http://proxylist.hidemyass.com/

Tened en cuenta que estais pasando trafico por un servidor desconocido, asi que puede ser facilmente interceptado. Intentad no usar cuentas de usuario ni poner contraseñas.

Y mañana mas. Un saludo.

Proyecto Redes: Parte VIII

Comenzamos con los bloqueos que nos podemos ir encontrando. Empezaré con el bloqueo por DNS, el mas simple de comprender y el mas rudimentario que puedan aplicarnos.

Como recordareis, el servidor DNS lo que hacia era traducir el nombre del dominio (como www.tiendaonline.com) a su dirección IP (12.34.56.78). Le enviabamos esa solicitud de informacion directamente a su IP (que nos proporcionó nuestro proveedor de Internet) y este nos respondia con la IP correspondiente.

Ahora bien, cuando se establece un bloqueo, el servidor DNS en vez de devolvernos la IP correcta nos indica una IP distinta (por ejemplo 87.65.43.21) con una pagina de "contenido bloqueado" o simplemente dar un error como si desconociera la IP de ese dominio.

La solucion es bastante simple. Al igual que accedemos a nuestro DNS podemos acceder a otro distinto, de otra compañia o de otro pais incluso. En la imagen aparece una explicación gráfica: mientras DNS está bloqueado (circulo rojo), se puede usar el DNS-2 (circulo verde).

Existen DNS disponibles para cada proveedor o pertenecientes a compañias como Google u OpenDNS.

Las direcciones IP de los servidores DNS de Google son 8.8.8.8 y 8.8.4.4.

OpenDNS ofrece tambien las direcciones 208.67.222.222 y 208.67.220.220, y ofrece servicio de bloqueo parental y contra phishing.

Veamos ahora como cambiar nuestras DNS. Para el ejemplo usare Windows 7. Para ello, accedemos a la pantalla de "Conexiones de red" (la forma mas rapida es tecleando "Conexiones" en el cuadro del buscador del menu inicio).

Tras ello, nos apareceran las conexiones que tengamos en nuestro equipo. En mi caso, aparecen dos conexiones. Presionamos el boton derecho sobre la que queremos modificar y escogemos "Propiedades".

Aparecerán distintas opciones, pero la que nos interesa es la del protocolo IP version 4. Lo seleccionamos y presionamos "Propiedades".

Alli podremos cambiar nuestra IP de manera manual y/o los servidores DNS. Si modificamos nuestra IP tendremos que poner tambien a mano los DNS.

Ponemos los DNS que queremos, en el ejemplo usaré los de Google. Podemos encontrar listados de DNS con una sencilla busqueda en Internet.

Y por ultimo, para que pase a tener efecto, aceptamos en todas las ventanas (pueden tardar un poco en cerrarse) y borramos nuestra tabla nombre de dominio-IP mediante el comando IPCONFIG /FLUSHDNS.

Con esto doy por concluida la entrega de hoy. Espero vuestros comentarios. Un saludo.

Proyecto Redes: Parte VII

Empiezo hoy con la parte dedicada a los bloqueos, y que seguramente sea una de las mas esperadas. He decidido prolongar un poco el proyecto, asi que todavia tendremos unas cuantas partes mas.

Cuando se bloquea una pagina, lo que se intenta es que no se pueda llegar desde un equipo (o mas de uno) a un servidor que está censurado. Para ello, es necesario intervenir en algun punto intermedio. Veamos donde puede actuar nuestro "censor" en el siguiente dibujo, que es nuestra red de ejemplo con unos cambios.

En la imagen aparecen marcados seis puntos en color rojo. Son todos los puntos en que un censor puede intervenir para limitar con exito el acceso al sitio censurado. Vamos a ver como funciona cada bloqueo.

Empezamos con el bloqueo directo del sitio censurado. Se desconecta tal cual. No puede acceder nadie, ya que esta desconectado. Es el metodo definitivo para evitar que se acceda a el. Esto suele aplicarse con una orden judicial.

El siguiente bloqueo es el se produce sobre la conexion entre el sitio censurado y las conexiones con el resto de la nube. Si bien el servidor no se ve afectado, queda incomunicado y nadie puede acceder. Se ejecuta por parte del proveedor de Internet de ese sitio, ya sea por orden judicial o por incumplir los acuerdos de servicio con el proveedor. Al igual que el anterior, es definitivo.

Otro bloqueo posible se daría en el router de la nube mas cercano a mi equipo. Este se suele aplicar de una manera mas selectiva. El equipo bloquea las solicitudes de parte de mi IP (o de las IPs de un determinado origen o destino). Existen varios casos a poner como ejemplo:
- El "gran cortafuegos" chino: bloquea todas las conexiones a ciertas paginas o a los paquetes de determinado contenido (ya sea revisando el contenido del paquete o limitando que los paquetes con un puerto de origen o destino determinado puedan pasar).
- El sistema de censura anti-pornografía británico: desde hace unos meses, los usuarios de Internet en el Reino Unido deben solicitar de manera expresa el acceso a contenido pornográfico. En caso contrario, queda bloqueado. Tambien está disponible en casi todos los proveedores de Internet un filtro similar.

Un bloqueo mas cercano es el que se efectua sobre la puerta de enlace. Es algo comun en las redes compartidas, como las de una institucion educativa, una red publica de un aeropuerto o muy frecuentemente en las empresas. Se introduce un proxy (que tambien sirven para esto) entre el nuestro equipo y la nube. Este bloqueo es propio de cada red, no depende de ningun gobierno.

El bloqueo mas cercano de todos es el que se realiza en el propio equipo. Este generalmente se usa en equipos compartidos como los que hay en las bibliotecas. Limita cada equipo de forma individual sin afectar al resto de la red.

Y he dejado como ultimo caso el bloqueo mas rudimentario de todos, que es el bloqueo por DNS. Consiste en algo tan simple como reprogramar el DNS para que cuando se solicite la IP del sitio censurado se responda con una IP distinta (como puede ser la de una pagina de advertencia de que el sitio se ha bloqueado) o con un error, como si el dominio no existiera. Es facil de aplicar y hacerlo tiene un coste minimo. Se suele hacer por orden judicial, como en el caso del bloqueo a la pagina de Uber que se produjo hace unos dias.

Vistos esos bloqueos, en la siguiente entrega explicaré como eludirlos.

Proyecto Redes: Parte VI

Hoy explico dos elementos inicialmente diseñados para el mundo empresarial y que luego se han adaptado a otros ambitos, que son los proxys y las VPN.

Un proxy es un equipo intermedio que se usa a la hora de acceder a otro de una red, y si es necesario adaptar los datos que vienen de este.

Pongo varios casos, para entenderlo facilmente:

- Supongamos que tenemos un equipo al que queremos proteger especialmente por seguridad o por disponibilidad. Por ejemplo, una base de datos con informacion medica, o un banco o algo parecido. Todos los accesos deben estar controlados, nadie debe acceder sin autorizacion, y debe mantenerse funcionando sin problemas, puesto que puede necesitar que este disponible desde varios sitios (por ejemplo, para acceso de los clientes y tambien para la intercomunicacion entre bancos).

Pues se autoriza a los equipos (proxys) que sean necesarios para que accedan y que todas las peticiones se realicen a esos equipos. En caso de que se intente realizar un ataque para "tirar" el equipo con la base de datos el unico que sufriria seria el equipo intermedio, no se sobrecargaria el que mantiene la base de datos, y quedaria funcional para los otros servicios, y en el caso de que haya que hacer modificaciones de seguridad se realizan sin necesidad de tocar el equipo con la base de datos.

- El siguiente caso es usarlo como "cache". Supongamos este ejemplo: estamos en una residencia universitaria. Todos los alumnos usan una misma salida a Internet, pero al mismo tiempo todos van a las mismas paginas. Si no queremos que se sature la conexion, podemos optar por guardar una copia de ciertas paginas en un equipo (el proxy) y que cuando alguien intente acceder a las paginas que ya tiene guardadas en vez de salir a Internet a buscar esa informacion se utilizan las copias que hay dentro de la misma red.

- El tercer y ultimo caso que voy a explicar es el que siguen algunos navegadores moviles como Opera, o las redes de telefonia movil para mejorar la velocidad. Supongamos que queremos acceder a una pagina con imagenes. Esas imagenes normalmente son demasiado grandes, requieren muchos datos y además no se captan con todo detalle desde un telefono. ¿Se podria reducir ese tamaño sin que se note demasiado? Claramente si. Para eso se usa un proxy, el dispositivo le hace la peticion al servidor proxy, que a su vez le pide la informacion al servidor de destino. Una vez recibida esa informacion, la optimiza y la reenvia a quien la pidio originalmente. Aparentemente, el navegador Chrome tambien realiza algo similar para mejorar la velocidad usando un protocolo llamado SPDY.


El siguiente (y ultimo) elemento que explico hoy son las Redes Privadas Virtuales (o VPN, Virtual Private Network).

El concepto consiste en crear una conexion encriptada hacia otra red, y acceder a ella como si formase parte de esta. Supongamos que quiero acceder a la red de Amigo 2. Creo una conexion segura hasta uno de los equipos (que ya esta preparado para ello, con sus puertos abiertos) y este me permite acceder a la red de mi amigo como si estuviera alli. Inicialmente se usa para conectar oficinas que están en distintos puntos geográficos o para jugar en red con otras personas.


Con esto ya doy por concluidas las explicaciones de conceptos. Si lo habeis seguido hasta ahora ya conoceis como funciona Internet y los principales servicios.

La siguiente parte ya sera la ultima. En ella explicaré cuales son las formas que se usan para bloquear una pagina web y como eludir esos bloqueos.

Proyecto Redes: Parte V

Como ya adelantaba en la anterior entrega, hoy voy a explicar algo que es imprescindible que los que descargan mediante P2P conozcan: NAT.

Recordemos que existian dos tipos de redes, la "red local", con unas IPs pertenecientes a unos rangos mas limitados, y la "nube", una gran red que interconecta equipos entre si y con otras redes locales (a traves de equipos intermedios).

Para conectar unas con otras se usan dispositivos llamados routers. Esos dispositivos funcionan como un embudo. Cogen todos los datos de varios equipos de una red local y los sacan por una unica salida. Veamos como lo hacen.

Cada equipo en una red tiene su IP. Un router tiene (al menos) dos IPs, una por cada red a la que pertenece. Para sacar los datos a la nube un router recibe un mensaje desde un equipo de su red local, pero como no puede sacarlo directamente (al haber varias redes conectadas a la nube, con equipos con la misma IP no seria posible que las respuestas volvieran correctamente) lo que hace es re-empaquetar el mensaje con su IP y un nuevo puerto. Pensemos el siguiente caso de ejemplo:

Equipo 1: tiene la IP 192.168.1.100
Router (red interna): IP 192.168.1.1
Router (red externa): IP 9.8.7.6
Tienda online: 12.34.56.78

- El equipo 1 quiere acceder al servidor web (puerto 80) de la tienda online. Para eso crea un mensaje desde un puerto cualquiera (2222) con esta cabecera: 192.168.1.100:2222 -> 12.34.56.78:80
- Como no tiene acceso directamente a la tienda, al estar en otra red, manda el paquete a su puerta de enlace 192.168.1.1.
- El router lo recoge y lo reempaqueta con su IP externa y un puerto nuevo al azar (el 9999), enviando el paquete 9.8.7.6:9999 -> 12.34.56.78:80.
- El servidor de la tienda online recibe el mensaje, y genera una respuesta, que la envia al equipo que realizo la solicitud: 12.34.56.78:80 -> 9.8.7.6:9999
- El router recibe la respuesta y la reenvia a quien creo el paquete original. Este recibe el paquete 12.34.56.78:80 -> 192.168.1.100:2222, como si no hubiera ningun intermediario.

A esto se le llama NAT ("Network address translation", "Traduccion de direcciones de red"), y permite que varios equipos de una misma red compartan una salida comun a otra red distinta.

Esto, tan comodo en este caso, crea un problema en el caso contrario. ¿Que ocurre si lo que se pretende es acceder a un equipo dentro de una red local desde la nube? La solucion esta en la configuracion del router (lo que se denomina "abrir puertos").

Al "abrir un puerto" le decimos al router que reserve un determinado puerto para un determinado equipo. Si un equipo de una red local quisiera ofrecer servicios web, usaria su puerto 80 para "escuchar" las peticiones. Si "redirigimos" el puerto 80 del router (de la red externa) al puerto 80 de un equipo, a todos los efectos será como si ese equipo estuviera conectado de manera directa, sin que hubiera ningun router entre medias.

Eso lo puede hacer el propietario del router de manera manual o el programa mediante un protocolo llamado UPnP. Ese sistema automatizado no todos los routers lo activan por defecto por razones de seguridad (no conviene que un programa vaya abriendo puertos a lo loco), y no todos los programas lo incorporan.

Existe un caso importante que quiero tratar ahora: los programas de P2P.

Un programa de P2P actua de dos maneras, como "cliente" que envia peticiones a un "servidor" y como "servidor" que recibe peticiones de un cliente. Obviamente, para conectarse entre dos equipos el que actua como servidor tiene que estar accesible. En las redes P2P hay un "apaño" consistente en que como los participantes de la red conocen a los demas las peticiones no solo las hace el cliente sino que el servidor tambien va preguntando a los clientes si necesitan datos, en lugar de quedarse simplemente a la espera.

La cuestion importante es que SIEMPRE tiene que haber alguien con los puertos redirigidos. Si una persona no tiene un numero de telefono puede usar una cabina para llamar, aunque no pueda recibir llamadas, pero jamas se podran comunicar dos personas sin numero de telefono, pues ninguno puede llamar al otro.

Por eso siempre es conveniente tener los puertos abiertos al usar P2P, para poder recibir solicitudes y que no se de el caso de que no podamos conectar con otros clientes al tener ellos los puertos cerrados.

Explicado todo esto, segun mi planificacion ya solo me quedan dos asuntos, que son los proxys y las VPNs y como funcionan los bloqueos para censurar un servidor.

Si hay dudas o quereis dar vuestra opinion, publicad un comentario y os respondere.

Un saludo

Proyecto Redes: Parte IV

Para hoy os traigo un tema que jamas, en todo el tiempo que llevo navegando por Internet, he visto bien explicado: que son los puertos.

Mencioné en la primera parte los paquetes, pero no les he dado mas importancia hasta ahora. Se trata de los bloques de datos que enviamos desde el origen al destino. Aparte de los datos en si, contienen varios elementos (en realidad son mas, pero voy solo a explicar lo que nos interesa) metidos en una "cabecera":

- El tamaño.
- El orden del paquete.
- La IP de origen.
- El puerto de origen
- La IP de destino.
- El puerto de destino.

Lo que es el tamaño, es evidente. La cantidad de datos que van en el paquete, para evitar que se junten dos paquetes de distintos tamaños o que se manden datos "en blanco".

El orden del paquete es un indicador de que parte del mensaje se esta transmitiendo. Si quieres transmitir el mensaje "bienvenido a mi blog" y solo puedes usar paquetes de cuatro letras (los espacios cuentan como letra) los tienes que ir numerando para poder reconstruir el mensaje. Entonces envias "bien"(1), "veni"(2), "do a"(3), " mi "(4), " blo"(5) y "g___"(6). Si por casualidad llegasen desordenados por ir por distinto camino podria reordenarlos.

Ademas, podemos ver que quedan datos en blanco. Si hubiera puesto tambien el tamaño del paquete, esos datos no se habrian emitido.

Las IPs de origen y destino, tambien las hemos explicado, asi que ahora vamos a por los puertos.

Si en un servidor ofrecemos distintos "servicios", como servicio de paginas web, servicios de correo o servicios de base de datos en el mismo equipo. ¿Como sabe el servidor que programa se tiene que hacer cargo de las peticiones que le haga otro equipo? Para eso están los puertos.

Un puerto es una marca adicional que sirve para que un equipo reparta los datos que recibe a los programas correspondientes. Veamoslo de forma mas detallada: el puerto 80 por defecto esta asignado al servidor web. Entonces si accedemos a la tienda online del ejemplo hacemos la solicitud a 12.34.56.78:80 (o sea, IP:Puerto) para poder entrar en su servidor web. El servidor ve que se lo han mandado al puerto 80 y automaticamente lo manda al programa que hace de servidor web. No lo manda al servidor de base de datos o al de correo electronico, que se preguntarian "¿y esto que es?" aparte de malgastar recursos en algo que solo va a dar error.

Pero esto que hemos visto es el puerto de destino, y hemos visto tambien que existe un puerto de origen. ¿Cual es su funcion? Exactamente la misma, pero a la hora de recoger las respuestas.

Ampliamos el ejemplo, ahora llevandolo mucho mas alla. Nuestro Amigo 1 coge su telefono movil (al que le vamos a poner la IP 1.2.3.4) y teclea la direccion de "tiendavirtual.com". Como en principio no sabe a que IP corresponde "tiendavirtual.com", pregunta a su servidor DNS cual es la IP correspondiente, y este le responde que es 12.34.56.78. El telefono de nuestro Amigo 1 ahora manda una peticion a 12.34.56.78:80 compuesta por uno o mas paquetes, que van cada uno por su camino. En esos paquetes pone como remitente 1.2.3.4:9999 (el puerto de origen en muchas ocasiones se escoge de manera aleatoria, en este caso he escogido 9999). El servidor que tiene la IP 12.34.56.78 recibe la peticion, mira que tiene el puerto 80 y envia esos datos al programa que funciona de servidor web, y este responde con los datos que pidio al remitente de los paquetes, esto es, a 1.2.3.4:9999. Al ver los paquetes, el telefono movil recuerda que el navegador habia lanzado una peticion con ese puerto y le envia el mensaje correspondiente, y se muestra en pantalla lo que Amigo 1 habia pedido.

Termino esta parte explicando un concepto nuevo, el firewall. Un firewall es un programa que bloquea las peticiones a un determinado puerto o a un determinado programa para protegerlo de ataques (entre otras posibles razones). Tambien puede bloquear los accesos restringiendo las IPs de origen (si bien un equipo determinado puede tener acceso a una base de datos, no debe permitirse el acceso a cualquiera).

Bueno, ya toca descansar un poco la cabeza. En la siguiente parte explicaré por que he usado como ejemplo a un equipo fuera de una red local y que es "abrir los puertos".

Proyecto Redes: Parte III

Hoy voy a introducir un concepto nuevo, el DNS, y a ampliar un poco mas los posts anteriores, pero esta vez de forma mas interactiva.

Recordemos el caso anterior de la tienda online. La idea era la siguiente: para acceder a una tienda online mando paquetes de datos a su servidor y este me responde con otros paquetes. Sin embargo, ¿como se la IP de su servidor?

Mirad de nuevo la imagen del post. Podeis ver un servidor, que he puesto cerca de mi red local, llamado DNS. Los servidores DNS ("Domain name server" o servidor de nombre de dominio) funcionan al igual que un listin telefonico. Asocian nombres de dominio, como puede ser "tiendavirtual.com" con una direccion IP, como puede ser 12.34.56.78. Yo ya conozco la direccion IP del DNS ya que me la proporciona mi ISP (a traves del router), asi que cuando accedo a la tienda online hago lo siguiente.

1. Tecleo el nombre de la tienda en mi navegador (tiendavirtual.com)
2. Mi ordenador no sabe su IP, asi que se la pregunta al DNS (que puede ser un DNS o mi router, que se encargaria de pedirsela a otro DNS).
3. El DNS responde a mi ordenador que la IP de tiendavirtual.com es 12.34.56.78.
4. Mi ordenador envia los paquetes que van a tiendavirtual.com a la dirección 12.34.56.78.

Y pocos secretos mas tiene la navegacion web "basica".

Os preguntareis, ¿y por que ha metido esto aquí? Pues porque nos va a aparecer el concepto de DNS en el siguiente bloque.

Ahora viene la parte práctica. ¿Que tal si veis cada uno como funciona aplicado a vuestros equipos? Para ello, usaremos una serie de herramientas en nuestros ordenadores. Voy a dar las explicaciones para Windows, principalmente, y quizas alguna para Linux. OSX es muy parecido a Linux, por lo que los comandos seguramente os funcionaran.

Lo primero que debemos hacer es abrir una ventana de "simbolo de sistema" en Windows (en Accesorios) o de "terminal" en Linux.

Ahora vamos a ver cual es nuestra IP. Vereis que puede ser distinto en vuestros equipos. Mi configuracion es manual, y posiblemente la vuestra sea automatica (usando un protocolo llamado DHCP). Para ello, los que useis Windows teneis que teclear IPCONFIG. Os saldra algo parecido a esto (voy a tachar cierta informacion).

En vuestro equipo lo vereis mas simple. Nos vamos a centrar en las dos primeras conexiones, Adaptador Ethernet VirtualBox Host-only network y Adaptador Ethernet Conexiones de red inalambricas.

¿Veis que aparece la dirección IP? Cada conexion de red tiene su propia IP, una es la 192.168.56.1 y la otra la 192.168.1.100. Tambien existen una serie de direcciones IP mas largas, que he tachado, que utilizan un protocolo distinto al que estoy explicando. Vemos tambien que la conexion de red inalambrica (que es mi conexion principal) tiene una Puerta de enlace predeterminada (el router al que se mandan las peticiones para equipos fuera de mi red), que es 192.168.1.1. Podeis encontrar aun mas información si en vez de IPCONFIG tecleais IPCONFIG /ALL. En mi caso ocupa mas de una pantalla, pero si nos limitamos a una sola conexion podemos ver algo como esto:

Aqui no solo vemos el nombre de "Conexiones de red inalambricas" sino tambien el tipo de dispositivo, la "dirección fisica" (la MAC, que se asigna de forma unica para cada dispositivo de red por parte del fabricante), si la configuracion esta realizada de forma automatica (DHCP) y los servidores DNS. Es bastante mas informacion.

¿Y en Linux? Uso tres comandos distintos (lo hago en otro equipo, por eso los datos son distintos), ifconfig, cat /etc/resolv.conf y route -n y nos sale lo siguiente:

Tras teclear ifconfig encontramos como antes que tengo varias conexiones. La que me interesa es la tercera, la que aparece junto a wlan0, que es mi conexion inalambrica (eth0 es la conexion por cable, ahora desconectada). Me indica mi IP, 192.168.1.103, entre otros muchos datos sobre la calidad de la transmision.

El segundo comando, cat /etc/resolv.conf me informa de cual es mi DNS. En este caso me aparece que mi "nameserver" (NS) es 192.168.1.1, correspondiente a mi router.

La salida del tercer comando, route -n, es tambien mas complicada que lo que se ve en Windows. Dice que para las conexiones a cualquier IP en general (0.0.0.0) use como puerta de enlace la dirección 192.168.1.1.

He dejado muchas cosas sin explicar, puesto que esto es solo la introduccion a las redes, no un tratado exhaustivo.

La siguiente cosa que vamos a ver es el comando ping. Este comando manda una solicitud de respuesta a otro equipo para medir cuanto tarda en regresar.

Veamos los resultados de un ping a twitter desde Windows:

Envia cuatro paquetes de prueba y calcula lo que tarda, indicandonos el tiempo mas rapido, el mas lento y la media. Con Linux es identico, aunque si no marcamos el numero de paquetes que queremos enviar, con la opcion -c, lo hace de manera continua y hay que pararlo con CTRL+C. Aqui va el mismo ejemplo, con cuatro paquetes de prueba.

Podeis ver que twitter.com me responde desde distintas IPs. Lo he realizado desde distintos equipos en distintos momentos, asi que me responden varios servidores de Twitter segun su disponibilidad.

La siguiente herramienta que usare es Traceroute, que va indicandonos el recorrido que sigue un paquete de datos dentro de Internet. Aplicamos el comando tracert en Windows:

Y desde Linux, el comando traceroute:

En ambas trazas, observamos por que servidores pasa el paquete y que aparece el tiempo minimo, maximo y medio de los pings entre cada servidor. Tambien que hay servidores que no facilitan esa informacion, por seguridad.

Ahora, para no extenderme, os comento un par de comandos interesantes para Windows con respecto a los servidores DNS:

IPCONFIG /DISPLAYDNS: muestra las asociaciones nombre de dominio-IP mas recientes devueltas por los servidores DNS a vuestro equipo.
IPCONFIG /FLUSHDNS: borra esa tabla de asociaciones. Por si quereis comprobar como al borrarlos y volver a entrar en las paginas se vuelve a regenerar.

Linux, en las distintas distribuciones, puede almacenar o no una tabla similar. No puedo daros unos comandos equivalentes ya que no hay un estandar.

Lo se, la tercera parte ha sido larga y complicada. Tambien ha sido lioso explicarla. Si teneis dudas, que las tendreis, planteadlas en los comentarios en vez de guardaroslas. Las redes son un tema complicado y poco de lo que he explicado aqui es facil, y menos para gente sin conocimientos previos.


Aviso a los tiquismiquis: si, existen algunas cosas que no son 100% exactas, pero he sacrificado la exactitud para mejorar la comprension.