Redes - Tercera Parte

Tercera parte de los artículos de redes publicados en la revista Tuxinfo. Corresponde al número #58.

Redes para las masas – Tercera Parte

En los artículos pasados vimos elementos que nos permitieron conocer aspectos más que nada físicos de las redes de datos. Sus materiales, velocidades, y normas, entre otros.

En éste analizaremos algo que nos permitirá entender cómo es que dos o más máquinas logran comunicarse sin fallar en el intento. Veremos qué es el modelo de las siete capas OSI, y por qué es tan necesario que exista un estándar como ese.

Finalmente, y como para amenizar tanta teoría, nos pondremos a filtrar paquetes de red, entendiendo qué es lo que ocurre por debajo de una comunicación entre sistemas informáticos. ¡Manos a la obra!

Una arquitectura modelo

El conjunto de protocolos TCP/IP es conocido de esta forma por dos de sus más importantes componentes, que son el Protocolo de Control de Transmisión (“Transmission Control Protocol”, o “TCP”) y el Protocolo de Internet (“Internet Protocol”, o “IP”). En algunos manuales viejos podremos encontrar para esto denominaciones tales como “Conjunto de Protocolos de Internet”, ya que en los documentos oficiales originalmente publicados aparecieron con ese nombre.

El éxito de diseño de TCP/IP consistió en lograr la interconexión de redes de datos, referido en algunos documentos como “internetwork”, o “internet”, y entregar servicios de conexión a redes heterogéneas desde el punto de vista físico. Nótese que hemos escrito esta palabra (“internet”) con una “i” minúscula, volveremos a esto más adelante.

Uno de los beneficios de ese diseño fue el de permitir que sistemas separados geográficamente puedan “conversar” entre sí, aún cuando esa separación sea inmensa. Hoy en día vemos cómo este éxito continúa de la mano de usar Internet (ahora con “I” mayúscula) y conectarnos a los sitios más remotos sin casi darnos cuenta.

Antes comenté que había que notar que estaba usando la palabra “internet” con minúscula. Pues bien, eso es porque esa palabra no es más que una contracción del término “interconnected network”, y no hacen referencia a la red a la que nos conectamos para recibir nuestro correo electrónico, por ejemplo, llamada “Internet”, con una “I” mayúscula.

Internet (con mayúscula) está compuesta por muchos elementos, como ser backbones (redes grandísimas que fueron diseñadas en un principio para interconectar otras redes, por eso la traducción de backbone será la de “hueso de atrás”, que es el que sostiene a los demás huesos. En algunos manuales los veremos nombrados como “Puntos de Acceso a Redes”, o “Network Access Points”, abreviados como “NAPs”, y en otros como “Puntos de Intercambio de Internet”, o Internet Exchange Points”, en este caso abrevados como “IPXs”), redes regionales (éstas interconectan diferentes edificios, como ser empresas, escuelas, universidades, etc.), redes comerciales (aquí vemos redes que se suscriben a uno o más backbones para lograr su salida a otras redes) y redes locales (sólo interconectan las máquinas que se encuentran dentro de una organización).

Como vimos en las entregas anteriores, las redes generalmente estarán limitadas por la cantidad de personas que a ellas pertenecen (cuando decimos “personas”, léase también “máquinas”), por la distancia geográfica máxima que pueden cubrir, o por su grado de aplicación a diferentes ambientes. Entonces, podremos tener dos o más “internets” (con minúscula) que están interconectadas por un ruteador para formar una “internet” más grande. Será el mismo ruteador quien entienda la forma de retransmitir paquetes de red de una a otra parte de la red en forma transparente.

Un aspecto que brinda importancia a la forma en la que está diseñado TCP/IP es su capacidad de crear una abstracción estandarizada de los mecanismos de comunicaciones provistos por cada una de las redes, desde el punto de vista físico. Cada red tiene sus sistemas físicos de interconexión que le son propios, y que han sido adoptados en base a la tecnología disponible, el tipo de máquinas que deben interconectar, o la distancia que deben cubrir. Para cada una de esas interfaces físicas se programan funciones primitivas, específicas, pero que TCP/IP permite utilizar en su trabajo de interconexión de las porciones físicas de la comunicación para con las porciones lógicas.

Como la mayor parte de los programas de comunicaciones, TCP/IP está diseñado pensando en capas que funcionan casi como si se tratara de edificios con ascensores. Así es que tendremos un conjunto de capas ordenadas que regirán la forma en la cual las máquinas logran comunicarse, y que son muy útiles a los programadores para que no tengan que rearmar desde el punto inicial todo cada vez que deban armar un programa de comunicaciones. Divide y vencerás, es el lema, y en TCP/IP se pone de manifiesto de la mejor forma.

Imaginemos este escenario: Vivimos en el séptimo piso de un edificio, y nuestro departamento tiene un ventanal que nos permite ver otros edificios. Un buen día vemos por ese ventanal una persona que por su grado de atracción no nos deja dormir en paz.

Para acercarnos e intentar la conquista tendríamos que abrir nuestra puerta, viajar en ascensor, salir por la puerta de nuestro edificio, caminar hasta el edificio de nuestro punto de atención, abrir la puerta de su edificio, acercarnos a su ascensor, luego tocar el timbre, y si tenemos suerte, habremos recibido una respuesta a nuestra propuesta.

Igual funcionan las capas del modelo OSI, en el que nos adentraremos a continuación.

Haciéndose el OSI

OSI es la sigla correspondiente a “Open Systems Interconnections”, un producto que nació gracias a la entidad “International Organization for Standarization”, o “ISO”, aunque la sigla no siga estrictamente el orden de las palabras. Esta organización nació en 1926 como la “International Federation of the National Standardizing Associations”, o “ISA”, y cuyo principal objetivo era el de normalizar aspectos de ingeniería mecánica. Claro, en esa época, la electrónica no estaba tan difundida, y todo lo que luego vino estaba en un estado germinal absoluto.

Como muchas organizaciones de ese estilo, cuando la segunda guerra mundia, en 1942, fue completamente desbaratada, para luego reorganizarse como la “ISO” en 1946, y recomenzar sus operaciones a principios de 1947.

Uno podría tener una idea bastante romántica de lo que es la “ISO” por pensar en su generación de estándares abiertos, pero lo cierto es que como muchas organizaciones, estuvo sostenida económicamente por empresas, muchas de las cuales estaban bastante deseosas de ver como estándar sus propios diseños, y así imponer en el mundo una u otra patente que les permitiera salir a flote. Hoy en día se establecen “estándares de facto”, y antes la tendencia era a tener un ente que los regule. Las caras han cambiado, las caretas son las mismas.

Pero dejando eso de lado, una de las buenas cosas que salió de la “ISO” fue el modelo “OSI” que divide la comunicación entre las siguientes capas:

• Capa Física: Capa 1. La capa física define las especificaciones físicas y eléctricas de los dispositivos de interconexión. Específicamente, define la relación entre los dispositivos y sus medios de transmisión, como ser la fibra óptica, el cobre, y otros. Entre las cosas que podremos ver en esta capa está la tensión (voltaje) que debe tener cada pata de un conector, cómo se definen las patas de esos conectores, su impedancia máxima, aspectos de tiempo de señales, y demás. Si no fuera por esta capa, oleríamos a quemado cada vez que conectáramos un nuevo dispositivo a nuestra máquina, ya que no es lo mismo conectar un cable de red que tenga unos pocos voltios, a un cable de la pared, con 220 voltios alternos, al menos donde yo vivo.

• Capa de Enlace de Datos: Capa 2. Provee los aspectos funcionales y procedurales para transferir datos entre redes de diferentes entidades, detectando y en lo posible eliminando cualquier tipo de error que se pudiera producir en el proceso de comunicación desde el punto de vista físico. Actualmente, sólo se maneja en esta capa el control de errores, y no el control de flujo eléctrico, como ocurría en un principio. Para entender mejor esta capa, imaginemos que enviamos un mensaje, y le agregamos datos de corroboración para que quien lo reciba pueda saber si lo que obtuvo es el mensaje correcto, o si tiene errores, y en este último caso, que cuente con los elementos para sobrellevar esta corrección de errores en la mayor parte de los casos. Si enviara un mail, por ejemplo, en el que al final de cada palabra le agregara un número que representa la suma de los números de orden de cada caracter, podría pensar en un control de errores. “hola” sería seguido por 8 (posición de la “h” en el alfabeto) + 15 (ídem para la “o”) + 12 + 1 = 36, y el receptor recibiría “hola36”. Si le llega “holo36”, o “halo32”, sabría que algo anduvo mal en esa comunicación. Un punto importante a tener en cuenta es que esta capa sólo interconecta elementos de la misma red, no entiendo cómo armar rutas entre redes. Elementos de red que se encuentran en esta capa son los hubs, o los switches de capa 2, ya que sólo tendremos control, en este caso, de elementos tales como la dirección “MAC”, o “Machine Address Code”.

• Capa de Red: Capa 3. La capa de red provee los elementos funcionales y procedurales para transferir secuencias de datos de longitud variable desde una fuente hacia un destino en diferentes redes, a diferencia de la capa anterior, que sólo lo hacía entre elementos de la misma red. Entonces, esta capa permite que funciones de ruteo tengan lugar, y por ende conocerá la forma de enviar paquetes de información desde una red a otra, así como recibir sus respuesta, y enviarlas a la máquina correspondiente. Los sistemas que operan en este nivel son los ruteadores (routers), que interconectan, por ejemplo, la red de nuestra casa con Internet. La capa de red, a la vez, se puede dividir en otras subcapas, que si bien son importantes, no aportarán mucho más a nuestro conocimiento de redes. Como se estarán imaginando, todo lo que se relacione con IP estará alojado en esta capa, ya que para poder armar rutas, debe haber un esquema de direcciones IP de las máquinas. Por supuesto, lo serán Ipv4, así como Ipv6, ARP, ICMP, IPSec, y otros tantos.

• Capa de Transporte: Capa 4. Esta capa permite la transferencia transparente de datos entre usuarios, entregando servicios de datos confiables a las capas superiores. Esta capa controla el grado de confiabilidad que un determinado enlace tendrá a través de controles de flujo, segmentación y desegmentación de paquetes, y control de errores. Veremos más adelante que algunos de los protocolos de comunicación que utilizaremos serán orientados a la conexión, pues entonces tendremos en esta capa la responsable de guardar un detalle del estado de cada uno de los segmentos recibidos, y de retransmitirlos en caso de errores. Por lo tanto, esta capa debe guardar también un detalle de cuáles son las transmisiones de datos existentes, si fueron o no exitosas, y de transmitir los siguientes datos si los anteriores llegaron a destino. Como se podrán imagina, todo lo que sea TCP será cercano a esta capa. También lo serán UDP, o SPX.

• Capa de Sesión: Capa 5. La capa de sesión controla los diálogos (si hacemos que las máquinas tomen consistencia humana, podremos hablar de este tipo de comunicación) o conexiones existentes entre distintas computadoras. Eso quiere decir que debe tener una tabla en algún lugar donde estén registradas todas las conexiones, y a la que deberá acudir cada vez que necesite conectar o desconectar alguna. Pero como es lógico, si esta tabla existe, tendrá también otros elementos, como ser detalles del tipo de comunicación establecida (si es half-duplex, full-duplex, etc.), metodologías de chequeo de conexiones, etc. Es muy común que esta capa esté implementada en aplicaciones que necesitan de la apertura o cierre de conexiones, como ser el caso de RPC, o “Remote Procedure Call”. Otros casos son NetBIOS, PPTP, o TLS/SSL.

• Capa de Presentación: Capa 6. Esta capa es un claro ejemplo de cómo se puede independizar al programador de aplicaciones orientadas a la red de tener que conocer todo sobre cada una de las anteriores capas, permitiéndole focalizarse sólo en lo que mejor (o peor) hace. La capa de presentación establece el contexto entre entidades a nivel de aplicación, entonces entendiendo su semántica, y mapeándolas para entregar datos en unidades encapsuladas siguiendo una norma estándar. Para que veamos esta capa con un poco más de claridad, veamos cómo una cadena puede ser transformada de un formato particular al ASCII, o cómo se pueden manejar las estructuras de datos existentes en archivos XML para ser generados e interpretados por las máquinas intervinientes en la comunicación. MIME o XDR son ejemplos de elementos que podremos encontrar en esta capa.

• Capa de Aplicaciones: Capa 7. Finalmente hemos llegado a la capa 7, la más cercana al usuario. Esta capa contiene al software de aplicaciones que luego hará uso de todas las demás capas inferiores para lograr una correcta y adecuada comunicación entre diferentes sistemas. Ejemplos de esta capa son el uso de HTTP, FTP, SMTP, IMAP, NNTP, NTP, NFS, o cualquier otro programa que permita la comunicación de cara al usuario.

A continuación, un diagrama que muestra todas estas capas:

Es común que, como broma “nerd”, se hable de “errores de capa 8”. Como podremos imaginarnos, la capa 8 es el mismo usuario, con lo cual se hace referencia a que cuando algo falla, es el usuario quien debe ser reescrito, o puesto de acuerdo a algún estándar. Así nos divertimos los nerds, somos gente jocosa, qué se le va a hacer.

Por otro lado, si bien vemos una división estricta y bastante taxativa en lo que a cada capa refiere, veremos en la vida real que no lo es tanto. Inclusive, es muy común que a nivel de TCP/IP, algunas capas parezcan solaparse con otras, o que varias estén incorporadas en una misma, como pasa con las capas 4, 5 y 6, normalmente implementadas en nuestro stack como un único módulo, denominado “Capa de Transporte”, análoga a la que tenemos en el modelo OSI tradicional.

Paquete para su servidor

Ahora bien, ya sabiendo cómo funciona el modelo OSI, y cómo se mapea con el stack TCP/IP, podremos ver cómo se compone un paquete de red, y cómo se encuentran representadas, en él, cada una de las capas de este modelo.

Un paquete de red es toda aquella unidad de datos transportada por una red de computadoras, sabiendo que los enlaces en sí mismos no transmiten paquetes, sino flujos de bits representados como “0's” y “1's”, y esos valores son conformados por impulsos eléctricos que dependiendo de si presentan o no tensión en sus conductores en un momento determinado así lo definirán.

Un paquete de red consiste de dos tipos de datos bien definidos, y que son los siguientes:

• Información de control: Provee la información que necesita la red para entregar los datos del usuario. Ejemplos son las direcciones de origen y destino, los datos de chequeo de errores y recuperación, información de secuencia de datos, etc. Esta información se encuentra en su cabecera y en su cola (conocidos también como “header” y “trailer”).
  • Cabecera: La cabecera contiene instrucciones sobre los datos transmitidos por el paquete. Estas instrucciones pueden incluir la longitud del paquete (dado que algunas redes pueden transmitir paquetes de dimensión fija, mientras que otros se basan en la información de esta misma cabecera para establecer su tamaño), datos de sincronización, numero de paquete (cuando se reconstruya la información será esencial contar con esta información), información de origen y de destino del paquete.
  • Cola: El trailer también es conocido como el pié del paquete, y normalmente contiene algunos bits que le explican al sistema que recibe la comunicación que ha llegado el final del paquete, así como alguna información de control de errores, como ser un CRC (“Cyclic Redundancy Check”, o chequeo de redundancia cíclica). Si los datos de control de errores no validaran al contenido del paquete, el sistema le pediría al que lo originó que lo reenvíe. Veamos una cabecera típica:

Notemos algunos datos interesantes: La dirección de origen utiliza 32 bits, así como la de destino. Recordemos que una dirección IP del protocolo Ipv4 se puede descomponer en cuatro octetos de bits, entonces nos cierra perfectamente la dimensión.

• Datos de usuario: Esta parte también se conoce como el cuerpo (“body”) o sencillamente como la sección de datos (“payload”). Es ésta la parte que contiene los datos que realmente se deben entregar al destinatario. Si el paquete fuera de dimensión fija, la parte del cuerpo que no contiene datos sería rellenada con ceros hasta cumplir con su tamaño.

Como ejemplo, consideremos un paquete de un mail (un mail de seguro implicará muchísimos más paquetes, pero veamos uno). Encontraremos en él una cabecera de unos 96 bits (32 bits de dirección origen, 32 bits de dirección destino, 8 para el protocolo, 16 para el número de fragmento, y 8 para otros elementos, como ser el TTL), luego un payload de 896 bits, y finalmente un trailer de 32 bits:

Basta de teoría, pongamos las manos en la grasa

Ahora bien, imaginemos lo que pasa cuando ejecuto algo tan sencillo como ser un “ping”. En mi caso, ejecutaré, desde la máquina con dirección IP 10.100.100.2, un “ping 10.100.100.1”, mientras que ejecuto el programa “Wireshark” utilizando “sudo wireshark”, ya que necesitaré de acceso de root a las interfaces de red.

A continuación, la pantalla inicial de Wireshark al momento de ser abierto, cuando presionaré el botón que me permitirá seleccionar una interfaz de red, y comenzar a capturar paquetes:

NOTA: El programa Wireshark es un analizador de protocolos de red formidable. No es la idea de este artículo en particular el explicar cómo funciona, si bien en próximas entregas se hará especial hincapié en él, ya que en caso de problemas será una de nuestras herramientas más espectaculares. Se puede instalar en nuestras máquinas con “apt-get install wireshark”, “yum install wireshark”, o “pacman -S wireshark-gtk”, dependiendo de si la versión de sistema operativo es basada en Debian, en Fedora, o en Arch GNU/Linux.

Entonces, seleccionaré mi interfaz eth0, y la pondré a capturar paquetes:

Ejecutaremos, en una terminal, “ping 10.100.100.1”:

hecsa@dshecsa01:~$ ping 10.100.100.1

PING 10.100.100.1 (10.100.100.1) 56(84) bytes of data.

64 bytes from 10.100.100.1: icmp_req=1 ttl=64 time=1.02 ms

64 bytes from 10.100.100.1: icmp_req=2 ttl=64 time=0.732 ms

64 bytes from 10.100.100.1: icmp_req=3 ttl=64 time=0.736 ms

64 bytes from 10.100.100.1: icmp_req=4 ttl=64 time=0.705 ms

64 bytes from 10.100.100.1: icmp_req=5 ttl=64 time=0.722 ms

^C

--- 10.100.100.1 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4001ms

rtt min/avg/max/mdev = 0.705/0.784/1.027/0.124 ms

Luego de unos segundos de ejecución del ping, presionaremos “Control+C” para finalizar este programa, y veremos en la ventana de nuestro Wireshark cómo han quedado logueada muchísima información, no sólo de nuestro ping, sino de cualquier cosa que haya pasado por la interfaz eth0:

Entonces, seleccionaremos alguna línea que contenga la cadena “ICMP” y “10.100.100.1”, para ver qué es lo que ha ocurrido.

Veremos que en la sección intermedia aparecen varias subsecciones desplegables que nos entregarán información de lo que ocurrió cuando lanzamos el mencionado ping, en cada una de las capas donde intervino:

• Capa 1: En esta capa nos mostrará lo que ha ocurrido a nivel eléctrico en el cable, y la interfaz de red en sí misma. Encontramos que se han enviado 98 bytes (784 bits), y los mismos han sido capturados en la interfaz “0”. El número de “frame” es el 126, lo que me serviría, en caso de problemas de red, para saber si ese mismo número llegó al sistema “10.100.100.1”, que es el destino de mi “ping”. No profundizaremos en lo que es y significa WTAP_ENCAP, u otros elementos de esta sección, ya que eso nos llevaría a meternos en el código de wtap.c, y no es la idea volveros más locos de lo que ya están.

• Capa 2: Si revisamos lo que más arriba vimos, la capa 2 es la que ya comprenderá lo que es una dirección MAC, y si asociamos eso con lo que vimos en el artículo anterior, sabremos que la dirección MAC tiene embebido un código que hace referencia al fabricante de cada una de las tarjetas de red intervinientes en la comunicación.

En nuestro caso, la máquina de donde sale el paquete de red tiene la dirección MAC 00:1f:c6:08:f5:7f, que se corresponde con una del rango asignado a Asustek, y por eso es que el programa Wiresharek así lo reconoce.

Por otro lado, el primer punto que tocó el paquete de red fue un router Cisco Linksys, cuya dirección MAC es la 00:21:29:77:b2:66. Eso también lo podremos ver representado en esta parte de la pantalla.

Nótese que en esta sección no hay más elementos que los dos que se interconectan directamente. ¿Por qué? Si releemos la parte donde explicamos las características de la capa 2, veremos que aún no posee ningún elemento que nos permita ver todas las rutas utilizadas para llegar de nuestro origen a nuestro destino, que es, en sí, el equipo Cisco Linksys.

• Capa 3: En esta capa veremos a nuestro querido protocolo IP abrir sus alas con todo el esplendor, cual pavo real atrayendo a su pareja. A diferencia del pavo, con Wireshark podremos ver sus intenciones y contenido verdaderos, encontrando elementos que nos muestran las direcciones IP de origen, de destino, el tipo de protocolo (Internet Protocol Version 4), y otras tantas. Ya en este caso, nos muestra que el protocolo es el ICMP, que es el que se corresponde al “ping”. Nótese también quese han ejecutado pruebas en la cabecera del paquete de red, y se ha llegado a la conclusión de ser correcta.

• Elementos directamente relacionados con el “ping”: Veremos, en la siguiente parte de la misma sección, que se describe todo lo que ha ocurrido a nivel de ICMP, que es el protocolo que se utiliza cuando ejecutamos “ping”.

Conclusión

Ya tenemos los elementos necesarios para entender claramente cómo funciona una red de datos, así como contamos con algunas incipientes herramientas que nos permiten determinar qué está bien y qué está mal cuando algo falla.

En las siguientes entregas nos adentraremos en comprender un poco más de TCP/IP, motivo por el que tendremos que activar nuestras máquinas virtuales para poder jugar un poco con los diferentes protocolos de red.

Tendremos la oportunidad de entender qué es lo que hacemos cuando configuramos direcciones IP en nuestras máquinas, tanto desde el punto de vista estático como dinámico, veremos qué es un ruteador predeterminado, e infinitas cosas más que nos permitirán, cada día, conocer más de lo que hacemos cuando hacemos, y cómo analizar una red con conceptos bien sólidos.

¡Nos vemos!