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!
No hay comentarios:
Publicar un comentario