Redes - Cuarta Parte

Artículo publicado en la revista Tuxinfo sobre redes. Corresponde al número #59 de dicha revista.

Redes para las masas – Cuarta Parte

Introducción

En los articulos anteriores nos iniciamos en el sagrado arte de comprender qué es una red de datos, cuáles son las características que definen cada tipo, sus aspectos físicos, velocidades, alcances geográficos, y las capas que componen el estándar OSI, entre otras cosas.

En éste estudiaremos nomenclaturas de interfaces de red, numeración de redes y subredes, ruteo IP, y demás delicias de la vida conyugal hombre-red.

El nombre de la rosa

En entregas anteriores tuvimos el gusto de descubrir que cuando hablamos de interfaces de red no lo hacemos pensando en un único tipo, sino que existen tantas como nuestra memoria pueda soportar. Inclusive, no hay un único fabricante para cada tipo de interfaz, lo que nos asegurará, por ende, que cada uno de ellos intentará, si bien siguiendo un estándar, manufacturarlas con los circuitos integrados que le resulten más convenientes, léase más baratos o accesibles.

Sabemos que cada pieza de hardware de nuestra máquina requiere, para funcionar, de un manejador (el famoso y siempre odiado “driver” del que tanto se escucha en las plegarias demoníacas de los administradores de sistemas). Pero si cada pieza de hardware tiene un driver diferente, y cada uno de esos drivers debe hablar directamente con el kernel de nuestro sistema operativo, tendremos entonces tantos nombres de dispositivos de red como posibles drivers existan. Al menos eso marca la tan desdichada lógica.

Pues bien, dado que el lagrimeo de los administradores de red es bastante desagradable, TCP/IP ha definido, para ocultar la increíblemente grande diversidad de equipamiento, una interfaz abstracta que sólo cambie su nombre ante cambios rotundos de tecnología. Por ejemplo, todas las interfaces ethernet en GNU/Linux se llamarán ethX, donde “X” será el número de interfaz de que se trate. Si tenemos dos interfaces de red ethernet, encontraremos que ellas se llaman “eth0” y “eth1”. Si su velocidad es de 10 Mbps, 100 Mbps, ó 1000 Mbps, se seguirán llamando “ethX”. Bueno, algo debía ser sencillo, después de todo.

Para ver las interfaces de red existentes en nuestro sistema operativo podremos utilizar bien los (antiguos) comandos “ifconfig”, bien los (nuevos) comandos “ip”. Veamos un ejemplo de cada uno, para la misma máquina. Primero el nuevo, “ip”, y luego el antiguo, “ifconfig”:

root@dshecsa01:~# ip link show

1: lo: mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

2: eth0: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000

link/ether 00:1f:c6:08:f5:7f brd ff:ff:ff:ff:ff:ff

root@dshecsa01:~# ifconfig -a

eth0 Link encap:Ethernet HWaddr 00:1f:c6:08:f5:7f

inet addr:10.100.100.2 Bcast:10.100.100.255 Mask:255.255.255.0

inet6 addr: fe80::21f:c6ff:fe08:f57f/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:59732677 errors:2 dropped:0 overruns:0 frame:0

TX packets:55481698 errors:0 dropped:0 overruns:0 carrier:8

collisions:0 txqueuelen:1000

RX bytes:50329751 (50.3 MB) TX bytes:2432319193 (2.4 GB)

Memory:dffc0000-e0000000

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0

inet6 addr: ::1/128 Scope:Host

UP LOOPBACK RUNNING MTU:65536 Metric:1

RX packets:8982327 errors:0 dropped:0 overruns:0 frame:0

TX packets:8982327 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:1043820519 (1.0 GB) TX bytes:1043820519 (1.0 GB)

Vemos en el ejemplo que nuestro sistema operativo reconoce dos interfaces de red: “lo” y “eth0”. Pero si tengo una única tarjeta de red, ¿por qué me aparecen dos? La primer interfaz de red listada, “lo”, es lo que se conoce como “loopback”, y la segunda es la ethernet propiamente dicha.

Como alguna vez alguien descubrió que muchas de las funciones de un sistema operativo dependen de la existencia de una interfaz de red en funcionamiento, y que puede ocurrir que una máquina no posea ninguna reconocida (por ejemplo, si aún no se ha cargado su driver), se decidió que una buena práctica sería la de generar en forma predeterminada esta interfaz para simular un conector que en algunas máquinas, hace muchos años atrás, se colocaba en su parte posterior, y funcionaba extrayendo las señales de salida y reinsertándolas como entradas en la misma máquina para hacer pruebas, llamado “loopback”. Más adelante veremos que no importa el sistema operativo ante el que nos encontremos, esta interfaz siempre tendrá la misma dirección IP, que es la 127.0.0.1. Claro está, eso cuando veamos cómo se conforman las direcciones IP.

Volviendo a la tierra, ¿cómo sabemos qué driver es el que está usando nuestra tarjeta de red? Para resolver tan enigmatico misterio, nada como los comandos “ls*” de GNU/Linux, que en nuestro caso se podrían resumir en “lspci” y “lsusb”, según nuestra tarjeta esté conectada mediante un método o el otro (léase, directamente conectada a nuestra máquina, o conectada mediante un puerto USB, como pasa con algunas interfaces WiFi externas, por citar sólo un ejemplo). La salida de un comando “lspci” puede ser bastante extensa, en nuestro caso nos focalizaremos sólo en la sección que hace referencia a la interfaz de red ethernet:

root@dshecsa01:~# lspci

...

02:00.0 Ethernet controller: Qualcomm Atheros Attansic L2 Fast Ethernet (rev a0)

…

Bien, vemos que nuestra interfaz de red es marca Qualcomm Atheros Attansic L2 Fast Ethernet. Pero vemos también unos curiosos números al frente de su descripción, “02:00.0”. Esos números que para decepción de los más religiosos nada tienen que ver con algún aspecto bíblico, nos servirán para identificar el driver que el sistema operativo tiene cargado para poder controlar la tarjeta de red. Podremos ver cuál es el driver buscándolo en el directorio /sys de nuestro GNU/Linux con el siguiente comando:

root@dshecsa01:~# find /sys | grep drivers.*02:00

/sys/bus/pci/drivers/atl2/0000:02:00.0

¡Bravo! Nuestro driver de seguro será descripto en nuestro sistema operativo como “atl2”. Estamos a muy poco de descifrar el rompecabezas. Veamos si efectivamente nuestro driver está cargado en nuestro sistema operativo usando “lsmod” (abreviatura de “list modules”, o “listar módulos”, ya que desde hace un buen tiempo, para alegría de todos, estos drivers se implementan en nuestro sistema operativo como módulos dinámicos de kernel):

root@dshecsa01:~# lsmod | grep atl2

atl2 27628 0

Bien, ya sabemos que el driver está cargado. Ahora, si necesitáramos saber dónde se encuentra el archivo que lo hace funcionar, dentro del kernel, así como otros datos, ¿cómo podríamos hacer? GNU/Linux tiene un comando para todo, y “modinfo” nos entregará tan valiosa información:

root@dshecsa01:~# modinfo atl2

filename: /lib/modules/3.8.0-19-generic/kernel/drivers/net/ethernet/atheros/atlx/atl2.ko

version: 2.2.3

license: GPL

description: Atheros Fast Ethernet Network Driver

author: Atheros Corporation , Chris Snook

srcversion: 489B206AFB57B59A896E561

alias: pci:v00001969d00002048sv*sd*bc*sc*i*

depends:

intree: Y

vermagic: 3.8.0-19-generic SMP mod_unload modversions 686

parm: TxMemSize:Bytes of Transmit Memory (array of int)

parm: RxMemBlock:Number of receive memory block (array of int)

parm: MediaType:MediaType Select (array of int)

parm: IntModTimer:Interrupt Moderator Timer (array of int)

parm: FlashVendor:SPI Flash Vendor (array of int)

Prestemos especial atención a la línea que nos muestra el nombre de archivo que debe estar cargado como librería de nuestro kernel para que la tarjeta de red pueda funcionar. Y si queremos molestar a alguien cuando nuestra tarjeta no funcione como es debido, tenemos la dirección de correo electrónico del autor del driver, que de seguro recibirá nuestro comentario con gran alegría, y alguna que otra referencia a nuestros familiares cercanos, en este caso calculo que en idioma chino simplificado.

Si para este momento no tenemos una línea de sangre que sale de nuestros oídos, quiere decir que nuestro cerebro no se ha licuado aún, y que podemos seguir adelante con este artículo. Nuevamente...¡bravo!

Farmacia “IP” erfumería

Como vimos en entregas anteriores, nuestras máquinas se comunicarán, en una red de datos TCP/IP, utilizando números únicos llamados “direcciones IP”. Estas direcciones no son más que alias para las direcciones MAC, por lo tanto mucho más sencillos de recordar que estas últimas. Estas direcciones IP serán números de 32 bits de longitud divididos en cuatro campos (para el estándar IPv4, aunque ya tenemos entre nosotros el IPv6, que más adelante analizaremos con un feliz grado de profundidad).

Al estar divididos en cuatro campos, podremos hablar de cuatro octetos (32 / 4 = 8), representados, a nivel de bits, como lo siguiente:

xxxxxxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx

Cada uno de esos bits podrán, como cualquier bit, tomar el valor “0” ó “1”, según sea necesario. Por ejemplo, al reconocer en el listado anterior la dirección IP de nuestra tarjeta de red “eth0”, que es “10.100.100.2”, podremos decir, sin miedo a equivocarnos, que se trata de los siguientes conjuntos de bits (recordemos ahora a nuestra bonita maestra de matemáticas cuando nos explicaba con toda su sensualidad la forma de convertir números decimales a binarios, en medio de sorprendentes ronquidos del alumnado):

00001010.01100100.01100100.00000010

El primer octeto, “00001010”, convertido a decimal es “10”; el segundo octeto, “01100100”, tal como el tercero, convertido a decimal es “100”; y el cuarto octeto, “00000010”, convertido a decimal, es “2”. No fue tan terrible, lo peor está por venir.

Ahora bien, las direcciones IP si bien compuestas por cuatro octetos, se pueden dividir en dos partes bien diferenciadas: el número de red, y el numero de máquina en dicha red. Suena complicado, pero no lo es tanto. Esta división se hace para poder planificar el tamaño de nuestra red, y asignar tantas direcciones como las que realmente utilizaremos, a la vez que permitiendo o restringiendo la comunicación entre las máquinas interconectadas.

La forma de dividir las redes es a través de definiciones sobre sus bits (sí, otra vez sobre los 32 famosos bits que antes vimos), de forma tal de tener los siguientes tipos de red:

• Clase “A”: Las redes clase “A” tendrán direcciones IP que estarán entre la 1.0.0.0 y la 127.0.0.0. Lógicamente, no llegarán a la 127.0.0.1 por ser ésta una dirección de “loopback”, y como buenos expertos en redes que nos estamos volviendo, sabemos que de haber dos direcciones con la misma IP un paquete de red no sabría a qué lugar ir. A nivel de octetos, esto quiere decir que para identificar una red tipo “A” veremos los siguientes rangos de bits encendidos:

00000001.00000000.00000000.00000000 al 01111111.00000000.00000000.00000000

Siguiendo con nuestra investigación detectivesca, el número que identificará a nuestra red estará contenido en el primer octeto, y los otros tres nos permitirán identificar máquinas dentro de nuestra red. Para ver un ejemplo, los siguientes equipos pertenecerán a la misma red clase “A” (nótese que tienen el primer octeto igual, y los otros tres diferentes):

01101100.00000000.00010000.00110100 = 108.0.16.52

01101100.01110101.10101110.10101010 = 108.117.174.170

¿Por qué serán de la misma red? Porque sus primeros ocho bits coinciden, y convertidos a decimal están entre 1.0.0.0 y 127.0.0.0. Si tuviera un equipo cuya dirección fuera 110.0.1.2, no pertenecería a la misma red, y por ende no podría comunicarse directamente con ninguno de los otros dos. Se quedaría solito, el muy pobre... En este caso, los más expertos dirán que se trata de “la red clase A 108”. Suerte que ellos saben...

Ahora bien, si tenemos el primer octeto con esas posibles direcciones, y son TRES los octetos que permiten identificar máquinas dentro de una red, ¿cuántas redes clase “A” podré tener? La respuesta es sencilla, y ya la recitaba la famosa filósofa griega Xipolitakis, en algunos de sus tantos concursos de tragedia: “Entre 1.0.0.0 y 127.0.0.0 tendré 2^7 – 1 (127) posibles redes, y cada una de ellas podrá tener 2^24 máquinas conectadas, es decir, 16777216 (sí, más de dieciseis millones de máquinas)”. Entonces, si quisiéramos una red con muchísimas máquinas, pensaría en una de este tipo. La principal desventaja de este tipo de redes radica en que el enviar un paquete a todas las máquinas es capaz de saturar al elemento de red más aguantador, ya tendrá que replicarse en más de dieciseis millones de interfaces de red.

• Clase “B”: Las redes clase “B” parten de la dirección 128.0.0.0 y llegan hasta la 191.255.0.0, considerando que la parte de la dirección que identificará a la red será no ya el primero, sino los dos primeros octetos. En notación binaria sería:

10000000.00000000.00000000.00000000 a la 10111111.11111111.00000000.00000000

Y ahora, a diferencia del caso anterior, una máquina cuyo segundo octeto difiera del segundo octeto de otra máquina no podrá comunicarse con ella.

Pero si tuvieran sus dos primeros octetos iguales, estas dos máquinas serán de clase “B” y se podrán comunicar en forma directa (es decir, sin ningún sistema ruteador en el medio de ellas):

10011010.01100101.00101100.00001100 = 154.101.44.12

10011010.01100101.10011110.10001010 = 154.101.158.138

Nuevamente, la afamada filósofa nos dirá que “entre las direcciones IP 128.0.0.0 y la 191.255.0.0 existen 2^14 (16384) redes posibles, cada una de las cuales podrá tener hasta 2^16 (por ser dos octetos, es decir, 16 bits, serán 65536) máquinas en cada una de ellas”.

• Clase “C”: Las redes de esta clase partirán de la dirección 192.0.0.0 y llegarán a la 223.255.255.0, entonces definiendo los primeros tres octetos para redes, y el último para máquinas. En notación binaria, quiere decir que estas redes tendrán el siguiente rango:

11000000.00000000.00000000.00000000 al 11011111.11111111.11111111.00000000

Entonces, las siguientes máquinas pertenecerán a la misma red:

11000000.00001001.11001000.00000011 = 192.9.200.3

11000000.00001001.11001000.00000101 = 192.9.200.5

Aquí nuevamente nuestra filósofa nos dice que “en una red clase C tendremos la posibilidad de definir 2^21 (2097152) redes diferentes, contando cada una con 2^8 (256, aunque luego veremos que son menos, porque algunas direcciones estarán reservadas para usos particulares) máquinas”.

• Otras clases: Las redes “D”, “E” y “F” son las que se definen entre las direcciones 224.0.0.0 y la 254.0.0.0, pero bien son experimentales, bien están reservadas para determinados usos ya normalizados, bien lo están para futuros usos, por lo que no nos detendremos a analizarlas demasiado.

Maravilloso, ya podremos diseñar nuestra red y darle una dirección a cada máquina, logrando que se comuniquen y todo.

Divide y vencerás

¿Qué pasaría si deseáramos tener una única red, pero dividida de forma tal de no invadir a todas las máquinas cada vez que lance un paquete del tipo “broadcast”, por ejemplo? Como los muchachos que diseñaron TCP/IP estaban en todo, pensaron en la posibilidad de partir en diferentes secciones cada red, aún cuando pertenezcan al mismo “set de octetos” que definen una red como antes lo vimos.Crearon algo llamado “subredes”, y para poder definirlas, crearon la “máscara de subred”. No es verde, ni sirve para los bailes de disfraces.

Esta máscara de subred funciona como si fuera un tamiz, el cual permitirá el paso de determinados granos, pero no permitirá que pase ninguno que sea más grande que el tamaño de sus agujeros. Si alguna vez vimos a nuestras abuelas colar la harina antes de amasar pasta, recordaremos que los grumos eran automáticamente desechados. Transportado a los conceptos de red, es sencillamente lo mismo.

Como era de esperarse, la máscara de subred también estará constituida por cuatro octetos de bits, los cuales tendrán una forma determinada para cada tipo de red (“A”, “B”, o “C”). Entonces, si no modificamos la cantidad de redes y máquinas por red (es decir, manejamos las cifras que antes vimos para cada clase) tendremos las siguientes máscaras:

• Clase “A”: 255.0.0.0. En este caso, los bits que definirán la red de que se trata serán los del primer octeto, o:

11111111.00000000.00000000.00000000

Entonces TODOS los primeros ocho bits definirán la red, y TODOS los siguientes treinta y dos definirán la número de máquina.

Pero qué pasaría si, a diferencia del caso anterior, la máscara de red fuera 255.255.255.0. Podríamos pensar en una red clase “A” que se comporta como una clase “C”, pero utilizando números de red que abarcarían los primeros tres octetos, ya que esta máscara de red sería, en binario:

11111111.11111111.11111111.00000000

Entonces, podriamos pensar en que dos máquinas con direcciones IP como las que vimos en el ejemplo anterior de este tipo de red no podrían comunicarse (108.0.16.52 y 108.117.174.170), ya que sus tres primeros octetos no son EXACTAMENTE los mismos. Pero dos máquinas, por ejemplo, con direcciones IP “10.100.100.2” y “10.100.100.100”, sí.

Los que más saben de este tipo de tecnologías de subredes suelen nombrar las máscaras por los bits que tienen encendidos. Entonces, por ejemplo, cuando la máscara de subred es “255.0.0.0”, dicen que la máscara es “8”, por tener los primeros ocho bits encendidos.

• Clase “B”: 255.255.0.0. Lo mismo que en el caso anterior, si ampliamos la cantidad de bits encendidos, la cantidad de redes posibles aumentará, pero disminuirá la cantidad de máquina posibles por cada una de dichas redes. En este caso, por los bits encendidos, se puede decir que la máscara será “16” si fuera “255.255.0.0”.

• Clase “C”: 255.255.255.0. Ídem todos los casos anteriores. Es muy común ver que cuando alguien solicita un rango de direcciones IP para ser visibles desde internet, los proveedores no hacen entrega de una red clase “C” entera, sino una porción, por lo que es normal ver máscaras de red del estilo “255.255.255.248” por tener, en binario, esta forma:

11111111.11111111.11111111.11111000

Sólo permitirá colocar, en dicha red, siete máquinas (en realidad serán menos, luego veremos por qué), ya que sólo permite, el tamiz, que pasen los últimos tres bits. Si queremos tener una regla mnemotécnica, pensemos en los “0” como si fueran los agujeros por donde pasa la harina. En este caso, por los bits encendidos, se puede decir que la máscara será “24” si fuera “255.255.255.0”, y “29” para el caso recién analizado.

Esa dirección no se toca, nene

En algunos apartados anteriores dijimos que la cantidad de máquinas que podían estar en una red, aún cuando por vía matemática nos daba un determinado número, serían menos por ciertas cuestiones.

Pues bien, cada vez que definamos una red, vamos también a considerar ciertas direcciones, como ser la de la red en sí misma, y la de “broadcast” (aquella por medio de la cual TCP/IP le envía un mensaje a todas las máquinas que hay en la red).

Entonces, por ejemplo, cuando definimos la dirección IP 192.9.200.5/24, podemos decir sin miedo a equivocarnos que se encuentra en la red 192.9.200.0, y que su dirección de broadcast será la 192.9.200.255, ya que la primera nos muestra los bits encendidos para definir la red entera, y los apagados destinados a ubicar máquinas.

La segunda nos muestra todos los bits correspondientes a todas las máquinas posibles dentro de dicha red, encendidos.

Por ende, para que lamentemos la falta de direcciones IP, a las que podríamos calcular en una red como la anterior (2^8 = 256 direcciones IP) habrá que restarle una para la red y otra para broadcast.

Como generalmente tendremos un sistema que permita que nos comuniquemos con el mundo exterior, veremos que la cantidad final de direcciones IP que podremos utilizar en una red como la anterior se restringe en una más. Entonces, en lugar de 256, podré usar (solamente) 253. La tristeza no tiene principio ni fin.

Postales del más allá

Cuando escribimos una carta (¿se acuerdan de la época en la que se usaba el papel y la lapicera para escribir, y utilizábamos esos lugares llamados correos para enviar mensajes?), colocamos el mensaje en un sobre, y escribimos los datos del destinatario, o quien queremos que la reciba. Entonces anotamos su dirección, ciudad, país, y código postal. La depositamos en un buzón, por donde pasa el recolector del correo, quien luego de ser corrido por todos los perros de nuestro barrio la lleva a la oficina de correos de la zona, la cataloga, y la manda a la oficina de correos más cercana a donde vive ese destinatario.

Podemos pensar, entonces, que el correo es algo así como el lugar donde se concentra nuestra correspondencia, y que si la misma debe ser enviada a la casa de al lado hay grandes posibilidades de ser entregada por mí mismo, tirándola en el busón, pero que si la mando a la otra punta del mundo deba pasar por varias oficinas hasta llegar a destino.

Entonces, nuestra oficina de correos será la que en forma predeterminada consideremos la ruta para nuestra correspondencia, y en ella tendrán una lista de diferentes rutas a utilizar cuando deban enviarla a un lugar lejano, hasta que llegue a la oficina postal que tenga la última de las rutas.

Pues bien, mis queridos carteros reprimidos por la sobredosis de datos, el protocolo TCP/IP funciona de la misma forma. Si un paquete de red debe cruzar el Atlántico en busca de un destinatario, lo hará pasando a través de varios ruteadores, hasta llegar al que considere, es el último antes de la máquina destino. Para eso es que en nuestra máquina estaremos configurando un parámetro llamado “pasarela predeterminada”, o lo que es lo mismo, “default gateway”.

Cuando mande un paquete de red a una máquina situada en la misma red en la que me encuentro, de seguro el paquete irá en forma directa. Si no lo está, el paquete de red irá a visitar al “default gateway”, el que tendrá una tabla donde verificar si la red a la que pertenece la máquina de destino es conocida, o si él también debe mandarla a su propio “default gateway” para que llegue a destino.

Podremos ver la configuración de gateways de nuestra máquina ejecutando el comando “netstat -nr”, tal como en el siguiente ejemplo:

hecsa@firewall01:~$ netstat -nr

Kernel IP routing table

Destination Gateway Genmask Flags MSS Window irtt Iface

201.216.255.168 0.0.0.0 255.255.255.248 U 0 0 0 eth0

10.100.110.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1

0.0.0.0 201.216.255.174 0.0.0.0 UG 0 0 0 eth0

Este sistema, como se puede ver, cuenta con dos interfaces de red: eth0, y eth1. Vemos en la salida del comando las columnas “Destination” (o “Destino”), “Gateway” (o “Pasarela”), “Genmask” (o “Máscara”), e “Iface” (o “interfaz”), entre otros. Veamos las direcciones IP de las diferentes interfaces con que contamos en este sistema (diferente del sistema que utilizamos como ejemplo en las anteriores secciones de este articulo) para entender esto un poco mejor:

hecsa@firewall:~$ ip address show

1: lo: mtu 16436 qdisc noqueue state UNKNOWN

link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

inet 127.0.0.1/8 scope host lo

inet6 ::1/128 scope host

valid_lft forever preferred_lft forever

2: eth0: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000

link/ether 52:54:00:3b:bf:dc brd ff:ff:ff:ff:ff:ff

inet 201.216.255.169/29 brd 201.216.255.175 scope global eth0

inet6 fe80::5054:ff:fe3b:bfdc/64 scope link

valid_lft forever preferred_lft forever

3: eth1: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000

link/ether 52:54:00:ac:a6:d9 brd ff:ff:ff:ff:ff:ff

inet 10.100.110.1/24 brd 10.100.110.255 scope global eth1

inet6 fe80::5054:ff:feac:a6d9/64 scope link

valid_lft forever preferred_lft forever

Se resaltaron en esta última salida las direcciones IP y sus máscaras de subred (29 y 24, respectivamente).

Entonces, sabemos que cada vez que se quiera alcanzar una máquina que se encuentra en la red 10.100.110.0/24 (veamos la línea que en “Destination” tiene “10.100.110.0”, y cuya “Genmask” es “255.255.255.0”), lo haremos saliendo por la interfaz de red “eth1”; luego, cuando necesitemos llegar a una máquina que se encuentre en la red 201.216.255.168/29, lo haremos por la interfaz “eth0”, y si la máquina no está en ninguna de esas dos redes, lo haremos a través del “default gateway”, especificado en la tabla salida del comando “netstat -nr” como “0.0.0.0” con máscara “0.0.0.0”, es decir, la dirección IP 201.216.255.174, usando la interfaz de red “eth0”.

Parece complicado, pero no lo es tanto. Para ver un ejemplo de los lugares por los que pasa un paquete de red cuando debe alcanzar una máquina, podremos ejecutar el comando “traceroute” de la siguiente forma:

hecsa@firewall01:~$ traceroute 10.100.110.3

traceroute to 10.100.110.3 (10.100.110.3), 30 hops max, 60 byte packets

1 10.100.110.3 (10.100.110.3) 0.363 ms 0.341 ms 0.272 ms

En este caso, intentamos llegar a una máquina que se encuentra en la misma red, por lo que no vemos ninguna dirección que haga referencia a nada que no se encuentre en la red 10.100.110.0/24.

hecsa@firewall01:~$ traceroute 8.8.8.8

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets

1 customer-static-2-45-42.iplannetworks.net (190.2.45.42) 2.771 ms 2.863 ms 3.048 ms

2 190.210.124.246 (190.210.124.246) 0.377 ms 0.382 ms 0.327 ms

3 customer-static-210-110-70.iplannetworks.net (190.210.110.70) 0.757 ms 0.729 ms *

4 customer-static-2-32-18.iplannetworks.net (190.2.32.18) 0.701 ms 0.872 ms 0.823 ms

5 209.85.251.84 (209.85.251.84) 0.844 ms 209.85.251.86 (209.85.251.86) 1.236 ms 209.85.251.84 (209.85.251.84) 0.824 ms

6 209.85.252.42 (209.85.252.42) 29.547 ms 29.317 ms 29.461 ms

7 72.14.233.89 (72.14.233.89) 28.612 ms 28.648 ms 72.14.233.93 (72.14.233.93) 29.230 ms

8 64.233.175.58 (64.233.175.58) 29.117 ms 64.233.175.18 (64.233.175.18) 39.303 ms 64.233.175.58 (64.233.175.58) 28.916 ms

9 google-public-dns-a.google.com (8.8.8.8) 29.377 ms 28.654 ms 29.028 ms

En este caso vemos que para llegar a la dirección 8.8.8.8, se debió pasar por la dirección 190.2.45.42, luego por la 190.210.124.246, luego por la 190.210.110.70, luego por la 190.2.32.18, luego por la 209.85.251.86, luego por la 209.85.252.42, luego por la 72.14.233.89, luego por la 64.233.175.58, y recién allí se llegó a la dirección de destino.

¿Qué quiere decir esto en términos de rutas? Que el sistema en el cual me encuentro no sabe cómo llegar a la dirección de destino, pero sí sabe de alguien que sabe. Pero como ese tampoco sabe, le pregunta al siguiente sistema, y así sucesivamente hasta llegar al destino.

Conclusión

En este número hemos terminado con la teoría intensa que cubre los conocimientos básicos necesarios para poder comprender cómo es que funciona la gestión de direcciones IP. Sé que no es lo más sencillo del mundo, pero tampoco es imposible.

En el próximo número hablaremos de DNS, DHCP e IP estática, instalaremos máquinas virtuales, y comenzaremos a jugar con los protocolos de red. Así que ya saben, a no comerse los codos, porque un mes pasa muy rápido. Y no duden en contactarme si algo no les quedó claro.

¡Hasta la próxima!

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!