lunes, 11 de noviembre de 2013

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!



Publicar un comentario en la entrada