lunes, 11 de noviembre de 2013

Redes - Quinta Parte

Quinto artículo sobre redes de datos, publicado en la revista Tuxinfo #60.



Redes para las masas – Parte V



Ya contamos con los conocimientos teóricos para comprender el funcionamiento de las redes de datos que encontremos delante nuestro. En las entregas anteriores pudimos interiorizarnos en cuestiones de base, fundamentales y no siempre conocidas por los administradores de sistemas que configuran entre otras cosas las redes que usamos para hacer funcionar nuestras aplicaciones.

En esta entrega pondremos las manos en la grasa, y configuraremos los elementos necesarios para probar nuestros conocimientos. A no asustarnos, comienza aquí una nueva etapa, excitante y movida, que si seguimos al pie de la letra nos aportará fuertes conceptos, ahora tanto teóricos como prácticos. Y como debe ser, no perderemos oportunidad para abordar nuevos conocimientos ahora ya más avanzados. Súbanse al tren, no paramos.

Preparando la escena

Las prácticas que veremos estarán basadas en determinados parámetros de nuestra red. Sabemos que, como pasa con las familias, no hay dos redes iguales. Pero tomaremos como punto de partida algunos parámetros que podrán ajustarse a cada caso, según corresponda. Los parámetros iniciales serán los siguientes:

  • Conexión a Internet: Consideramos tener una conexión a Internet medianamente decente, nada ambiciosa, pero sí que esté funcionando. La usaremos para bajar imágenes de sistemas operativos, si aún no los tenemos. En mi caso, me conecto a Internet a través de un pequeño router WiFi conectado a un cablemódem configurado con la dirección IP interna 10.100.100.1/24. Eso quiere decir que siempre que configure un router predeterminado y esté utilizando una conexión que carezca de la configuración “NAT” (paciencia, ya revisaremos este concepto) lo haré con esa dirección. Este punto se podrá ajustar a los parámetros de la red que tengamos. Si no tuviéramos un router, y sí una conexión directa a Internet, podremos ver los parámetros de ruteo ejecutando el comando “netstat -nr” desde una terminal GNU/Linux, y revisando la columna “Gateway” en la línea que tenga el valor “UG” en la columna “Flags”. Para las prácticas iniciales, utilizaremos facilidades que nos provee el mismo virtualizador, y que no desemerecen ninguno de los puntos que estudiaremos. Todo lo contrario, cuanto más complicado, mejor. Más adelante, jugaremos con estos parámetros.

  • Direcciones IP disponibles: Si contamos en nuestra red con un servidor DHCP (más adelante veremos qué es eso) utilizaremos las direcciones IP que él nos entregue. En mi caso tengo uno que entrega direcciones IP desde la 10.100.100.100 a la 10.100.100.150, siempre con máscara 24. Si no usamos esa tecnología, no hay problema, veremos opciones para estos casos. E inclusive, para nuestra práctica jugaremos con el servidor DHCP que tiene el software hipervisor.

  • Espacio en disco: Si bien no es concluyente, ya que no lo utilizaremos en forma completa, el contar con unos 30~60 GB de espacio en disco será conveniente para la generación de las máquinas virtuales que utilizaremos en nuestras prácticas. Para la totalidad de este artículo, 30 GB son más que suficientes, y hasta me animaría a decir que demasiado.

  • Memoria RAM: Convendrá tener por lo menos 1,5 GB de memoria RAM disponible. Si tenemos muchas aplicaciones abiertas mientras ejecutamos las prácticas, tendremos que cerrar algunas hasta que podamos contar con máquinas virtuales funcionales. No es tan terrible, en mi caso estoy ejecutando todo en una pequeña notebook.

  • Sistema operativo: Cualquier sistema operativo que nos permita la ejecución de un programa de virtualización como lo es VirtualBox nos servirá. Eso incluye GNU/Linux en casi todos sus sabores, OpenIndiana, *BSD, y “los que ya no son primeros en ventas”, también.

  • Software de virtualización: Como software de virtualización utilizaremos VirtualBox. Dependiendo de la versión de GNU/Linux de que dispongamos podremos utilizar el set de comandos “apt-get”, “yum”, “pacman”, o bajarlo desde el sitio http://www.virtualbox.org para nuestro sistema operativo y arquitectura de procesador. Recordemos también bajar la “VM VirtualBox Extension Pack” para usar funciones avanzadas de este software.


El motivo por el cual estamos bajando dos versiones diferentes de GNU/Linux es el poder experimentar por una lado con una basada en “.deb”, como lo es Debian, Ubuntu, Linux Mint, etc., y por el otro con una basada en “.rpm”, como lo son Red Hat, CentOS, Scientific Linux, Fedora, etc.

No dejaré de lado la configuración de otras distribuciones, como lo son las *BSD, como lo son FreeBSD, NetBSD o PC-BSD; y las basadas en IllumOS, como lo son OpenIndiana, por ejemplo. Ellas quedarán, por no ser las más populares (no saben lo que se pierden) para el final de esta sección.

Debian Virtual

Lo primero que haremos es implementar una máquina virtual basada en Debian GNU/Linux 7, y para ello haremos uso de la primer imagen que hemos bajado. Para realizar esta instalación, abriremos el programa VirtualBox y en la ventana principal seleccionaremos el botón superior “New” o “Nueva”.

En la primer ventana, donde se nos pide “Name and Operating System”, colocaremos, como nombre (“Name”), “firewall1”, como tipo de sistema operativo (“Type”), “Linux”, y como versión (“Version”), “Debian”.

En la siguiente pantalla, donde se define el tamaño de la memoria, asignaremos no más de 512 MB. En la siguiente, donde se debe configurar el disco virtual a generar, seleccionaremos “Crear un disco virtual ahora” (“Create a virtual hard drive now”), y presionaremos el botón “Crear” (“Create”). Debemos seleccionar el tipo de archivo a utilizar para el disco virtual, que en nuestro caso será “VDI”.

El almacenamiento de este disco será “Dinámicamente alojado” (“Dynamically allocated”), y su tamaño será no menor a los 15 GB. Con eso prácticamente quedará creado el entorno que necesitamos para hacer nuestra práctica. Sólo nos queda cambiar algo de la configuración.

Para ello, presionaremos el botón derecho sobre el nombre de la máquina virtual, y en el menú que se desplegará seleccionamos “Configuración” (“Settings”). El primer cambio que introduciremos será dejar el tipo de red como “NAT” (veremos en breve qué es eso). Luego, seleccionaremos en el menú de la sección izquierda de la pantalla la parte de “Almacenamiento” (“Storage”), y en el disco óptico simulado, seleccionaremos la imagen que bajamos, “debian-7.0.0-i386-netinst.iso”, o la que hayamos bajado.

Ahora, con los cambios introducidos, podremos presionar el botón “OK”. La máquina virtual quedará configurada como lo vemos en la figura, y estaremos listos para encenderla presionando el botón “Iniciar” (“Start”).



Como el orden de inicio lo determina, comenzaremos a ver el booteo desde el CD-ROM, que en nuestro caso, es la imagen del CD de sistema operativo Debian 7.

En la primer pantalla, seleccionaremos como idioma de instalación “English”. En “Select your location”, elegiremos “other”, luego “South America”, luego “Argentina”.

En “Select your locales”, elegiremos “United States”. En “Configure the Keyboard”, a menos que tengamos un teclado algo distinto, “Latin American” será adecuado. Así llegaremos a la sección “Configure the network”.

Como hostname escribiremos “firewall”. Domain name lo dejaremos en blanco. Colocaremos la clave de root dos veces. Crearemos un nuevo usuario colocando su nombre, username, e ingresando la contraseña dos veces.

En la sección de particionamiento de discos seleccionaremos la opción “Manual”, luego elegiremos el disco virtual que hemos configurado antes, y como “Partitioning scheme”, para simplificar este paso, elegiremos “All files in one partition (recommended for new users”. Seleccionaremos “Finish partitioning and write changes to disk”, y lo confirmaremos.

Luego de unos segundos se nos solicitará que configuremos el gestor de paquetes (“Package Manager”), para lo cual, en mi caso selecciono “Argentina”, y luego “ftp.ccc.uba.ar”, pero que podrá ser cualquier otro valor según la zona donde estén viviendo.

Si no uso un proxy para salir a internet, dejaré este campo en blanco. Selecciono “No” a participar del concurso de popularidad de paquetes (“popularity contest”). En la sección “Software selection” sólo dejo seleccionado “SSH Server” y “Standard System Utilities”.

En la sección de instalación de GRUB, digo “Yes” a instalarlo en el MBR (“Master Boot Record”). Cuando termine la instalación podré ingresar a mi nuevo sistema operativo, ya que me encontraré ante una ventana típica de login en modo caracter.



NAT King Cole y el enmascarado misterioso

Bueno, venimos hablando de NAT hace un par de párrafos, llegó el momento de definir qué es eso.



NAT es una sigla que significa “Network Address Translation”, o “Traducción de Direcciones de Red”. Éste es un sistema de cambio de direcciones IP utilizado para interconectar dos o más redes que tienen rangos de direcciones incompatibles. Imaginemos una empresa donde haya un telefonista que dedica sus días a recibir llamadas desde dentro de esa entidad, escuchar a alguien decir “comuníqueme con el teléfono xxx”. Esa persona lo que hará será utilizar alguna de sus líneas disponibles, y comunicará al empleado INTERNO, a través de un número de teléfono que es público, a otro número de teléfono que también es público. Si del otro lado de la comunicación tuviéramos también un conmutador telefónico, estaríamos entrando a esa red de teléfonos a través de un número público, y luego nuestra llamada sería enrutada hacia el número interno que corresponda.



Entonces, las redes de datos tendrán la forma de hacer algo similar. Como ya sabemos, las direcciones IP rápidamente se están agotando, y si tuviérmos que colocar una dirección IP pública (es decir, alguna que pueda ser directamente contactada en Internet) a cada dispositivo que en este momento utilizamos, estaríamos en serios problemas. En una empresa de cinco mil empleados, utilizaríamos esa cantidad de direcciones IP públicas. Por lo tanto, el proceso de NAT, en este caso, permitirá tener un ruteador en el borde de la red (esto es, el punto donde se interconecta la red privada y la pública, internet), que haría una traducción de las direcciones internas para que todas contacten sus destinos a través de una única, o únicas direcciones IP públicas.

Supongamos que tenemos una red que internamente tiene el rango de direcciones IP 10.100.100.0/24 (sí, máscara 255.255.255.0), es decir, que soporta unos doscientos cincuenta y tres direcciones internas. En lugar de contratar con nuestro proveedor ese número de direcciones IP públicas, contratamos una sola, supongamos la 200.12.13.14, y colocamos en el punto de interconexión el ya tan famoso ruteador.

Cada vez que algún usuario interno quiera contactar un sitio de internet, podrá hacerlo, y ese sitio leerá que la dirección que lo contactó fue la 200.12.13.14, no la dirección interna. Y cuando ese servidor envíe información de vuelta hacia la red que lo contactó, esa información le llegará al puesto de trabajo interno que originalmente la solicitó.

La primer pregunta que nos haríamos es “¿cómo sabe el servidor a qué dirección interna enviar la información, si todos los pedidos salieron por la misma dirección IP pública, que es la 200.12.13.14?”. El servidor enviará un paquete de red de respuesta, que de seguro tendrá “algo” para saber que debe llegar a ese puesto de trabajo. Caso contrario, sería muy cómico que yo pida una página de internet, y que el resultado le llegue a cualquier persona, sea mi jefe, o mi empleado.

¿Qué es ese “algo”? Es un mecanismo. Por un lado, TCP/IP en tiempo real edita las cabeceras de los paquetes de red, y agrega información destinada a esta traducción. Si la conexión fuera del tipo “uno a uno” (“one to one”), estaríamos ante lo que se denomina “basic NAT”. Pero cuando tenemos una red entera escondida detrás de una única dirección IP pública, aparte de llamarlo “uno a muchos” (“one to many”) lo que se hace es armar en el ruteador una tabla de puertos de salida para que, cuando el servidor contactado devuelve su respuesta, se verifique por qué puerto está llegando, y entonces dicha respuesta sea enviada al sistema que la solicitó. Sencillo, ¿no? A veces, este tipo de NAT es llamado NAPT, por la sigla de “Network Address and Port Translation”, ya que se están traduciendo tanto las direcciones IP como los puertos.

Ahora bien, supongamos que en nuestra red interna tengo un servidor web en una máquina que tiene la dirección IP 10.100.100.10, luego un servidor FTP en otra máquina que tiene la dirección IP 10.100.100.20, y un servidor SSH en una tercera máquina, con la dirección IP 10.100.100.30. ¿Cómo puedo hacer para que desde afuera de mi red un cliente externo pueda, por un lado, ver páginas alojadas en mi sitio interno, por el otro transferir archivos utilizando el protocolo FTP, y por el otro conectarse con un servidor mediante SSH?

Para eso tenemos una de las variantes del NAT, llamado DNAT por su significado, “Destination Network Address Translation”, o “Traducción de direcciones de red de destino”. Esto también se encontrará en el ruteador que está conectado a la dirección IP pública, y tendrá una tabla con reglas de este estilo: “si el paquete de red tiene como destino el puerto 80, debe ir al servidor web, que está en la dirección IP 10.100.100.10; si el destino es el puerto 21 para comenzar una transferencia FTP, se debe redirigir a la dirección 10.100.100.20; finalmente, si el destino es el puerto 22, se redirigirá a la dirección IP interna 10.100.100.30”.

De esta forma, tendremos inclusive la oportunidad de tener en nuestra red interna más de un servidor web. Supongamos que el sistema que muestra fotos está en la dirección IP 10.100.100.50; luego el que muestra la interfaz gráfica de un webmail está en la dirección IP 10.100.100.60; y finalmente el portal web está en la dirección 10.100.100.70. Podré definir, en el ruteador, que todo lo que ingrese por el puerto 8080 sea redirigido al puerto 80 del primer servidor, luego lo que ingrese con un destino de puerto 8090 sea redirigido al puerto 80 del seguundo servidor, y lo que ingrese con puerto 8100 como destino sea redirigido al tercer servidor. Sencillo, pero se complica un poco, ¿no? No tanto, sería peor si el DNAT no existiera. DNAT en algunos casos es denominado también “port forwarding”, dado que se toma un puerto determinado, y se reenvía a otro puerto, de otra dirección IP.

Si en cambio, necesito que una serie de direcciones internas de una red sean “NATeadas” para cambiar su dirección IP por la pública, estaré ejecutando “SNAT”, o “Source Network Address Translation”, que es similar al caso que vimos al principio.

Ahora bien, ya sabiendo todo esto, ¿qué es “IP Masquerade”, o “Enmascaramiento de IP”? Es casi lo mismo que NAT, tal como lo vimos en un primer momento, pero que puede funcionar inclusive con interfaces de red que no tengan una dirección IP estática asignada. Eso quiere decir que funciona inclusive con las conexiones de internet que tenemos en nuestra casa, así sea un cablemodem, una conexión ADSL, por módem 3G, etc.

Ah, ¿no saben qué es una dirección IP estática, y una dinámica? No hay problema, ya vamos, ya vamos.

Dinámicas y estáticas

Habrán notado que en la instalación de nuestra máquina virtual como único parámetro de red hemos configurado su hostname. No le hemos agregado, aún, ninguna dirección IP, máscara de subred, ruteador predeterminado, ni nada que se le parezca. ¿Qué valores obtendrá cuando este sistema virtualizado inicie su procesamiento?

Ejecutemos un “ifconfig eth0” y veamos su salida:

root@firewall:~# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 08:00:27:31:01:50
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe31:150/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:125 errors:0 dropped:0 overruns:0 frame:0
TX packets:123 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:15005 (14.6 KiB) TX bytes:12720 (12.4 KiB)

Esto quiere decir que nuestra máquina virtual obtuvo de “algún lado” la dirección IP 10.0.2.15. Esa dirección es claramente interna, ya que al menos en mi caso no se corresponde con ninguna de las redes que tengo disponible, y no la hemos configurado nosotros, entonces ¿quién la configuró? Sencillamente la configuró nuestro hipervisor, VirtualBox, a través de un servidor de direcciones dinámicas que posee embebido.

Ahora bien, como teníamos configurada nuestra tarjeta de red con el protocolo NAT, de seguro vamos a poder llegar a cualquier dirección IP pública a través de ésta, privada, y haremos la prueba con la 8.8.8.8, perteneciente a Google:

root@firewall:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=63 time=43.9 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=63 time=42.2 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=63 time=51.2 ms
^C
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2006ms
rtt min/avg/max/mdev = 42.260/45.805/51.240/3.902 ms

Qué bueno, tenemos salida a internet, y no hemos sacrificado ninguna dirección IP pública más. Ésta es una muestra de cómo NAT puede ayudarnos a solucionar parte de la problemática de consumo de direcciones IP públicas.

Pero volviendo al tema de este apartado, decimos que VirtualBox nos ha entregado una dirección IP “dinámica”, dado que la misma cambiará cada vez que la máquina virtual se encienda. Si fuera estática, la misma se mantendría constante y estaría asignada en forma manual a nuestra máquina.

Pero ¿es el único parámetro que nuestro servidor de direcciones IP entregó? Claro que no.

Ejecutemos este comando para entender cuál es el juego de servidores DNS que hemos recibido:

root@firewall:~# more /etc/resolv.conf
domain fibertel.com.ar
search fibertel.com.ar
nameserver 200.42.4.207
nameserver 200.49.130.44

Estas direcciones IP son las correspondientes a los servidores que transformarán nombres del tipo “DNS”, como lo es http://www.google.com a direcciones IP, ya que en Internet, si bien uno escribe en su navegador esa dirección, denominada URL (por “Uniform Resource Locator”, o “Localizador de recursos uniforme”), cuando se accede a un sitio web, se accede a una dirección IP provista por esos servidores de DNS, o “Domain Name Service”, “Servicios de nombres de dominios”.

Por lo tanto, un servidor de direcciones dinámicas podrá entregarnos una serie de parámetros para que nuestra máquina posea una dirección IP, parámetros de servidores de nombres, ruteador predeterminado, y un sinfín de otros. El protocolo que permite este tipo de configuración dinámica se denomina “DHCP”, o “Dynamic Host Configuration Protocol”, “Protoclo de configuración de hosts dinámico”.

¿Pero qué pasaría si necesitara que sí o sí un sistema cuente con una dirección IP que no cambie cada vez que se reinicie? En ese caso lo que debiera hacer es configurar una dirección IP estática para esta máquina, y por ende también configurar otros parámetros, como ser sus servidores DNS, y su ruteador predeterminado, por lo menos, para permitir que nuestra máquina virtual tenga conexión con el mundo exterior.

Esto también se puede hacer utilizando el protocolo DHCP, ya que podría, como se hace en muchos casos, fijar del lado del servidor DHCP una determinada dirección IP a una dirección MAC, y aprovechar todos los demás servicios que este protocolo supone.

Una de las primeras conclusiones ya está saliendo a la luz, y es que claramente DHCP trabaja en un nivel, en la capa OSI, más abajo que “IP”, ya que cuando una máquina envía paquetes para buscar un servidor DHCP, lógicamente aún no posee esa dirección IP, y espera que el servidor se la entregue.

Profundamente dinámico

En esta sección veremos el protocolo DHCP en profundidad, para comprender bien cómo es que funciona, ya que el que asigne direcciones IP bajo pedido puede ser algo confuso de comprender.



Cuando un cliente configurado con DHCP se conecta a una red, envía paquetes de broadcast (para todos lados, para ser simplista) pidiendo por un servidor DHCP. El DHCP server, que tiene bajo su gestión un conjunto de direcciones IP (“IP address pool”), casi como si fuera un almacén, y esas direcciones se trataran de su stock, asigna a esa computadora una dirección, enrutador predeterminado, servidores DNS, servidor de zona horaria predeterminado, tiempo de alquiler (“lease time”, o el tiempo que dichos parámetros serán válidos en el cliente antes que el mismo deba enviar un nuevo pedido a la red, y renovar o conservar dichos valores) y otros tantos parámetros posibles. Cuando el cliente DHCP se desconecta de la red, por ejemplo al apagar la máquina, la dirección IP es devuelta al servidor DHCP para que luego pueda ser utilizada por otro cliente que así lo necesite.

DHCP utiliza dos puertos para su funcionamiento, que son lógicamente UDP (¿podrían ser de otro tipo, considerando que aún no hay direcciones IP en el cliente?), y que se corresponden con los puertos 67 y 68. DHCP, entonces, hace uso de cuatro fases para poder entregar las direcciones a sus clientes, a saber:

  • DHCP discovery: El cliente envía mensajes en la subred física de forma tal de descubrir un servidor DHCP que pueda atenderlo. Si la subred estuviera separada de la que posee el servidor DHCP, se podría jugar con los ruteadores para que reenvíen los pedidos de los clientes, y les lleguen. Y claro está, si el cliente antes estuvo configurado con DHCP, puede solicitar un DHCP server que le entregue la misma dirección IP.
  • DHCP offer: Cuando el servidor DHCP recibe un pedido de un cliente, reserva una dirección IP de su pool, y le extiende un “contrato de alquiler” de ese tipo de direcciones, o un “lease offer”. Esto no es más que un mensaje que contiene la MAC address del cliente, la dirección IP que se ofrece, su máscara de red, etc.
  • DHCP request: Como respuesta a la oferta de alquiler enviada por el servidor DHCP, el cliente envía un pedido de parámetros DHCP para recibir formalmente esos parámetros ofrecidos, y definir que la dirección IP en cuestión ya será asignada a esa máquina, quitándose del pool del servidor.
  • DHCP aknowledgement: En esta fase final, el servidor DHCP le envía un paquete al cliente con el tiempo de alquiler, y otros tantos parámetros de red.

Dependiendo de la implementación que se efectúe, un servidor DHCP puede tener tres posibles métodos de asignación de direcciones IP, a saber:

  • Alojamiento dinámico (“dynamic allocation”): Las direcciones IP disponibles se encuentran en un conjunto previamente configurado por el administrador del servidor DHCP. Las mismas son entregadas a los clientes que así las soliciten, y cuando el tiempo de alquiler termina, el servidor las reclama, y las vuelve a colocar en el conjunto o pool para ser entregadas a otro cliente. El esquema típico de los ISP (“Internet Service Providers”) es éste, ya que necesitan poder entregar direcciones IP a más clientes que direcciones IP tengan asignadas en sus rangos.
  • Alojamiento automático (“automatic allocation”): El servidor DHCP entrega direcciones IP en forma dinámica, pero guarda una tabla de correspondencias MAC – IP, de forma tal de entregar, de ser posible, la misma IP a la misma MAC, si estuviera aún disponible. Los ISP más serios tienen este esquema, y generalmente también los servidores DHCP de las empresas, también serias.
  • Alojamiento estático (“static allocation”): Las direcciones IP están fijadas y asignadas a las MAC de cada equipo. Es útil para cambiar direcciones IP de clientes sin que éstos siqquiera tengan que tocar un parámetro, o para asegurar que no habrán en nuestra red máquinas que no hayan sido expresamente declaradas.

Archívese

Vimos que los puestos de trabajo cliente podrán tener dos tipos de configuraciones de direcciones IP, estática o dinámica.

Ha llegado el momento de ver cuáles son los parámetros que se deben tocar en los diferentes puestos de trabajo *NIX para responder a una u otra configuración.

Estos parámetros se configuran, dependiendo del sabor de GNU/Linux, en diferentes archivos. Para el caso de Debian y sus derivados (Ubuntu, Mint, etc.), se debe configurar el archivo “/etc/network/interfaces”, colocando, por ejemplo, las siguientes entradas si quisiéramos que reciba direcciones IP dinámicas en una tarjeta de red “eth0”:

root@firewall:~# more /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet dhcp

Nótese que en este archivo se ha resaltado la entrada que indica que la interfaz de red eth0 utilizará “DHCP” para funcionar. Cuando el sistema operativo esté arrancando, y configure esta tarjeta de red, sabrá que debe salir a buscar un servidor DHCP para recibir sus parámetros de red.

Si quisiéramos asignarle, por ejemplo, la dirección IP 10.0.2.25/24, conservando su routeador predeterminado (10.0.2.2), tendríamos que modificar este archivo para que tenga las siguientes entradas:

root@firewall:~# more /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eth0
iface eth0 inet static
address 10.0.2.25
netmask 255.255.255.0
gateway 10.0.2.2

Nótese la palabra “static”, resaltada en la sección que configura la tarjeta eth0, así como también la dirección IP asignada, su máscara de subred, y el ruteador predeterminado.

Si tuviéramos un programa como el “resolvconf” instalado en nuestro sistema, podríamos también agregar un par de entradas correspondientes a los DNS servers a utilizar, del estilo:

dns-nameservers 200.42.4.207, 200.49.130.44

Claro está, esto se agrega en la sección de la tarjeta eth0...eso quiere decir entonces que ¿se podrían tener parámetros de DNS diferentes para tarjetas diferentes?

Ahora bien, ¿qué pasa cuando lo que tenemos que implementar es esto mismo, pero en un sistema que posee Fedora GNU/Linux, o sus derivados (Red Hat, CentOS, etc.)? En este caso el archivo a modificar no será uno solo, ya que existirá uno por cada tarjeta de red a configurar, y estará ligado en forma biunívoca a esa interfaz, sea la misma tanto física como virtual; única como conjunto de otras interfaces:

Por ejemplo, si se quiere configurar la tarjeta de red eth0, nos encontraremos con el archivo /etc/sysconfig/network-scripts/ifcfg-eth0, que para el caso dinámico tendrá un contenido como el siguiente:

[root@server1 ~]# more /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
ONBOOT="yes"
HWADDR=52:54:00:37:4B:A5
TYPE=Ethernet
BOOTPROTO=dhcp

Nuevamente, nótese la palabra “dhcp”, resaltada.

Y para el caso estático, tendrá un contenido como el siguiente, considerando que la dirección IP que deseo es la 10.0.2.35/24, con el mismo ruteador predeterminado:

[root@server1 ~]# more /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE="eth0"
ONBOOT="yes"
HWADDR=52:54:00:37:4B:A5
TYPE=Ethernet
BOOTPROTO=static
IPADDR=10.0.2.35
PREFIX=24
GATEWAY=10.0.2.2
DEFROUTE=yes

Virtualmente, jugando un poco

Ahora bien, supongamos que decidimos verificar cuál es la dirección de la que salen paquetes de red correspondientes a un ping efectuado desde nuestra máquina virtual, basada en una dirección IP entregada por un DHCP server, y que tiene configurado un NAT. Para ello, utilizaremos, desde nuestra máquina física (no la virtual) el comando “tcpdump”. Supongamos que estamos conectados a internet a través de la interfaz de red “eth0”.

Entonces ejecutaremos el comando “tcpdump -i eth0”, en nuestra máquina física, y mientras tanto, “ping 8.8.8.8” en nuestra máquina virtual. La salida del comando en cuestión será la siguiente (algo recortado, ya que los mensajes son larguísimos):

[root@zentraedy-l ~]# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
00:48:07.407951 IP 10.100.100.105.59955 > scl03s06-in-f22.1e100.net.https: Flags [FP.], seq

(...)

00:48:27.238728 IP 10.100.100.105 > google-public-dns-a.google.com: ICMP echo request, id 2555, seq 6, length 64

(...)

00:48:35.309868 IP google-public-dns-a.google.com > 10.100.100.105: ICMP echo reply, id 2555, seq 14, length 64
^C
73 packets captured
73 packets received by filter
0 packets dropped by kernel
[root@zentraedy-l ~]#

Esto quiere decir que, para el sistema que contacte, la dirección que lo estará contactando será la 10.100.100.105, que en mi caso es la dirección IP que tengo asignada en la interfaz física de mi máquina, valga la redundancia, física, y diferente de la 10.0.2.15, configurada en mi máquina virtual.

Hemos tenido, entonces, la oportunidad de verificar cómo funciona NAT en carne propia, y hasta hemos contactado máquinas en Internet desde una máquina virtual cuya interfaz de red eth0 ha recibido una dirección IP gracias a un servidor DHCP.

Ahora, subiremos la apuesta, generando una máquina virtual que se conecte a internet a través de esta máquina con la que hemos practicado hasta ahora. Bajemos nuestra máquina virtual, para poder modificar un poco su configuración. Ejecutemos con mucho cuidado el comando “poweroff”.

Primero, seleccionemos la configuración de nuestra máquina virtual, específicamente la sección de “Red” (“Network”), y seleccionaremos la solapa que se refiere al segundo adaptador (“Adapter 2”). En ella clickearemos el cuado que habilita dicha tarjeta de red. En la sección “Adjunta a” (“Attached to”) seleccionaremos “Internal Network”, y como nombre de red pondremos “interna1”, por ejemplo. Luego de esto, presionaremos “OK” para aceptar todos los cambios.

¿Qué hemos hecho? Hemos agregado una tarjeta de red a nuestra máquina virtual, y la hemos apuntado a una red interna que hemos generado, llamada “interna1”, a la cual luego conectaremos otra máquina virtual.

Ahora, crearemos otra máquina virtual, pero basada en RPM, es decir, una VM CentOS, para la cual utilizaremos la imagen CentOS-6.0-i386-bin-DVD.iso.

Seguiremos los mismos pasos que antes seguimos, pero como nombre de máquina seleccionaremos “centos1”, luego como tipo seleccionaremos “Linux” y como versión “Red Hat”. También asignaremos 512 MB de memoria RAM, y crearemos un nuevo disco del tipo de archivo “VDI”, dinámicamente alojado, de 15 GB de tamaño total.

Seleccionaremos como lo hemos hecho antes la opción “Configuración” con el botón derecho del mouse sobre la máquina virtual, asignando al CD la imagen CentOS-6.0-i386-bin-DVD.iso, y a la red la configuración “Internal Network”, y como nombre de la red interna “interna1”, la misma que agregamos a la segunda tarjeta de red de nuestra máquina virtual Debian.

Seleccionaremos “OK” para confirmar los cambios, e iniciaremos la instalación de la máquina virtual. Seleccionaremos, luego del booteo, “Install or upgrade an existing system”, saltarmos la comprobación del disco de instalación (“Disk Found” -> “Skip”), con lo que el instalador gráfico dará inicio. Seleccionaremos las siguientes opciones, a saber:

  • En la primera pantalla, sólo seleccionaremos “Next”.
  • Como idioma de la instalación, seleccionaremos “English”, y presionaremos el botón “Next”.
  • Como teclado seleccionaremos “Latin American”, y presionaremos “Next”.
  • Como tipo de almacenamiento, seleccionaremos “Basic Storage Device”, y presionaremos “Next”.
  • Si apareciera un error de inicialización de disco, presionar el botón “Re-initialize all”, siempre verificando antes que se haga referencia al “VBOX DISK”.
  • Como hostname coloquémosle “centos1”, y presionemos el botón “Configure Network”.
  • En la ventana de “Network Connections” seleccionemos la solapa “Wired”, y dentro de ella la interfaz “System eth0”.
  • Presionemos el botón “Edit”.
  • En la nueva ventana, “Editing system eth0”, seleccionemos el checkbox “Connect automatically”.
  • Seleccionemos la solapa “IPv4 Settings”.
  • En la lista que aparece en “Method” cambiemos de “Automatic (DHCP)” a “Manual”.
  • En la sección de “Addresses” presionemos el botón “Add”.
  • Configuremos la nueva dirección con “10.200.200.2” como “Address”, “255.255.255.0” como “Netmask”, y “10.200.200.1” como “Gateway”.
  • En la sección de DNS Servers coloquemos “10.200.200.1”, y presionemos el botón “Apply”.
  • En la ventana de “Network Connections” presionemos el botón “Close”.
  • Presionemos el botón “Next”.
  • Configurar la zona horaria según el lugar donde estemos. En mi caso, es “America/Argentina/Buenos_Aires”, y presiono el botón “Next”.
  • Configuremos la clave de root dos veces, y presionemos “Next”.
  • En la sección de particionamiento, seleccionemos “Use all space”, y seleccionemos “Next”.
  • Aceptemos el particionamiento propuesto por el instalador presionando “Next”.
  • Si se nos pregunta por la opción de formatear, presionar el botón “Format”.
  • Confirmar con “Write changes to disk”.
  • Dejar la opción “Install boot loader on /dev/sda”, y presionar “Next”.
  • En la selección de software, seleccionemos “Minimal”, y presionemos “Next”.
  • Cuando termine la instalación, presionar el botón “Reboot”.
  • Al final esta instalación, relativamente chica, tendremos un sistema CentOS 6 implementado, con el cual jugaremos para ver cómo se comporta detrás de una máquina Debian, y conectándose a internet a través de ella.

Cuando la máquina virtual reinicie, levantemos también firewall1, para ver qué ocurre al intentar ejecutar un ping como antes lo hicimos. ¿Sorpresa? Los paquetes de red de la máquina centos1 no salen a la red. ¿Motivo? Sencillo, su ruteador predeterminado, 10.200.200.1, no existe aún. Esa será la dirección IP que configuraremos en la segunda tarjeta de red que hemos definido para la máquina firewall1.



Para eso, ingresaremos a la máquina virtual “firewall1”, que tiene hostname “firewall”, y configuraremos su segunda tarjeta de red. Primero veremos cuáles son ahora sus tarjetas de red disponibles:

root@firewall:~# ifconfig -a
eth0 Link encap:Ethernet HWaddr 08:00:27:31:01:50
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe31:150/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:75 errors:0 dropped:0 overruns:0 frame:0
TX packets:68 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9344 (9.1 KiB) TX bytes:8579 (8.3 KiB)

eth1 Link encap:Ethernet HWaddr 08:00:27:20:21:ba
BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

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:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Editemos el archivo /etc/network/interfaces, para que quede parecido a lo siguiente (nótense los agregados de las líneas que comienzan con “auto”):

root@firewall:~# vi /etc/network/interfaces

auto eth0
allow-hotplug eth0
iface eth0 inet dhcp

auto eth1
allow-hotplug eth1
iface eth1 inet static
address 10.200.200.1
netmask 255.255.255.0

Ahora relancemos los servicios de red en el sistema Debian, y veamos lo que ocurre al verificar nuevamente las direcciones IP existentes en él:

root@firewall:~# service networking restart
[....] Running /etc/init.d/networking restart is deprecated because it may not r[warnble some interfaces ... (warning).
[....] Reconfiguring network interfaces...Internet Systems Consortium DHCP Client 4.2.2
Copyright 2004-2011 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eth0/08:00:27:31:01:50
Sending on LPF/eth0/08:00:27:31:01:50
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPOFFER from 10.0.2.2
DHCPACK from 10.0.2.2
RTNETLINK answers: File exists
bound to 10.0.2.15 -- renewal in 38093 seconds.
ifup: interface eth1 already configured
done.

En este último comando tenemos varios elementos interesantes. Veamos algunos de los marcados en negrita. DHCPDISCOVER, DHCPREQUEST, DHCPOFFER, y DHCPACK nos deben sonar bastante conocidos, para lo que estuvimos viendo en apartados anteriores, ¿verdad?

Por otro lado, vemos un mensaje que anuncia una renovación de dirección en una cantidad de tiempo determinado. Claro, ¿verdad?

Verificaremos con ifconfig nuevamente:

root@firewall:~# ifconfig -a
eth0 Link encap:Ethernet HWaddr 08:00:27:31:01:50
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe31:150/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1052 errors:0 dropped:0 overruns:0 frame:0
TX packets:690 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:89314 (87.2 KiB) TX bytes:83407 (81.4 KiB)

eth1 Link encap:Ethernet HWaddr 08:00:27:20:21:ba
inet addr:10.200.200.1 Bcast:10.200.200.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe20:21ba/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:30 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:2340 (2.2 KiB)

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:16436 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

Ahora, intentaremos llegar desde “firewall” hasta “centos”, con el siguiente comando:

root@firewall:~# ping 10.200.200.2
PING 10.200.200.2 (10.200.200.2) 56(84) bytes of data.
64 bytes from 10.200.200.2: icmp_req=1 ttl=64 time=33.1 ms
^C
--- 10.200.200.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 33.162/33.162/33.162/0.000 ms

Efectivamente, ya la máquina “centos” forma parte de nuestra red, y podemos alcanzarla. Ese será el puntapié para las prácticas que haremos en próximos artículos. A no borrar las máquinas virtuales.

Conclusión

En este artículo hemos aprendido algo sobre NAT, DNAT, SNAT, IP Masquerade, DHCP, configuración de direcciones estáticas y dinámicas, y armamos una red interna que utilizaremos para las prácticas que vendrán. En el artículo próximo jugaremos con protocolos como DHCP, DNS, comprenderemos qué es y armaremos nuestro firewall, permitiremos y denegaremos puertos, colocaremos servidores internos y los accederemos (o no), traeremos vía TCP/IP a Snowden, seremos testigos de su casamiento en Venezuela con la hermosa espía rusa que se lo propuso, y mucho más.

¡Hasta la próxima!


Publicado por en
Etiquetas: , , , ,

No hay comentarios:

Publicar un comentario

Suscribirse a: Enviar comentarios (Atom)