DNS maestro y esclavo con BIND

Voy a tratar de explicar como montar un DNS maestro usando BIND en Debian 7 y, después, como hacer las modificaciones pertinentes para montar un DNS esclavo del mismo. Lo primero que tenemos que hacer es disponer de una máquina limpia, yo me he decantado por la última versión de Debian sin entorno gráfico porque estoy un poco cansado de Ubuntu Server y su gestión de interfaces. Una vez actualizados los respositorios e instalado el paquete correspondiente (apt-get install bind9) me dispongo a explicar la configuración:

1. Vamos a definir las zonas de búsqueda tanto directas como inversas. Para ello vamos a modificar el fichero /etc/bind/named.conf.local. En mi caso voy a crear una zona llamada "casa.local". En este fichero se indica cual va a ser el tipo del servidor (maestro, esclavo,...) y las rutas de los ficheros de zona.
   
2. Ahora vamos a crear el fichero de búsqueda directa (casa.db). Podemos usar de base uno de los que trae BIND con la instalación para no tener que escribir todo desde cero. Por ejemplo: db.local. Hay que incluir aquellos equipos cuyos nombres queramos que sean resueltos. Ojo con la sintaxis, procurad ser estrictos porque no tolera fallos de caracteres (puntos, puntos y comas,...).
   
3. Hacemos lo mismo con la búsqueda inversa: creamos un fichero (puede usarse uno de ejemplo) y añadimos los datos pertinentes.
   
4. Tenemos que indicar en el fichero de interfaces que el servidor DNS que vamos a utilizar es el servidor que acabamos de montar, es decir: 127.0.0.1.
   
5. En este caso vamos a activar los forwarders para que el equipo solicite externamente aquello que no puede resolver por si mismo, por ejemplo: www.google.com.
   
6. Ya estaría el servidor montado y configurado. Reiniciamos los interfaces de red, reiniciamos el servicio y hacemos pruebas de resolución con varios clientes e, incluso, pruebas de resolución externa.

A partir de esta configuración vamos a montar ahora un nuevo servidor DNS en otra máquina que funcione como esclavo. Los primeros pasos son los mismos: una máquina nueva, actualización de repositorios e instalación del paquete con el servidor. Lo que cambiaría son los siguientes pasos:

1. En el fichero de resolución directa del DNS Maestro hay que añadir dos líneas: una en la que indiquemos el servidor dns2 y otra en la que indiquemos la IP que va a tener (192.168.1.60 en este caso).
   
2. También hay que añadir una línea en el fichero de resolución inversa, para indicar el servidor DNS esclavo.
   
3. Ahora tenemos que comunicar la existencia del nuevo servidor esclavo al servidor maestro. Esto lo haremos modificando el fichero de configuración: named.conf.local.
   
4. Y a la inversa, es decir, indicar en el servidor esclavo quien es el maestro. También tenemos que decirle que va a ser del tipo esclavo (slave).
   
5. Es importante indicar en el fichero de interfaces de red del servidor esclavo que la línea dns-nameservers tiene que apuntar a 127.0.0.1, es decir, que él mismo (el servidor esclavo) será el encargado de resolver los nombres. Reiniciamos interfaces de red (en ambos casos) y servicios (en ambos casos) y debería funcionar la resolución de nombres tanto en servidores como en clientes.

Realizando esta tarea me he encontrado problemas relacionados sobre todo con la sintaxis de los ficheros (desaparece algún punto o punto y coma), con la configuración de los interfaces (es importante no olvidarse que la línea correspondiente del fichero de interfaces tiene que apuntar al servidor correcto) y, uno de los más latosos, con el fichero /etc/resov.conf. Este fichero puede darnos verdareros problemas si nos empeñamos en indicar una configuración en un lado (/etc/network/interfaces) y otra configuración en otro (/etc/resolv.conf), ya que casi con total seguridad puede coger la de este último mientras nosotros estamos plenamente convencidos de que no lo hace.

NAT estático en Packet Tracer

Antes de nada deberemos saber que es NAT. NAT (network Address Translation) es un servicio que traduce IPs privadas en IPs públicas. Hay varios tipos: estático y dinámico. Hoy nos vamos a centrar en el estático porque es el más sencillo para empezar. También es conveniente saber que en NAT estático tiene que haber como mínimo tantas IPs públicas como IPs privadas. Lo que haremos será configurar una red privada con un equipo y una red pública con un equipo unidas mediante un router.

Configuramos cada uno de los interfaces para que haya conexión (que los enlaces se pongan en verde) entre los diferentes dispositivos de la siguiente manera:

• Interfaz PC-PT: 192.168.1.100/24 con gateway 192.168.1.1/24
• Interfaz Server-PT: 200.168.1.100/24 con gateway 200.168.1.1/24
• Router1: 192.168.1.1/24 (fa0/0) 200.168.1.1/24 (fa0/1)

Cuando tengamos conexión, si probamos a enviar un paquete ICMP del PC-PT al Server-PT, funcionará y sin hacer NAT. ¿Por qué? Pues es tan sencillo como que el router tiene, respectivamente, sus interfaces en la misma red que cada uno de los equipos. Es el mismo router el que se encarga de hacer esta gestión automáticamente. De hecho, si nos fijamos en el paquete ICMP cuando llega al Server-PT tiene el siguiente aspecto:

Si nos fijamos, le acaba de llegar un paquete con el origen 192.168.1.100. Esto plantea un serio problema y es que, en Internet los routers están configurados según la RFC , es decir, están configurados para eliminar aquel tráfico que provenga o que vaya a redes privadas. ¿Cómo solucionamos esto? Con NAT. Lo que podemos hacer es convertir la IP privada en una IP pública. En un caso real, esta IP pública será proporcionada por nuestro ISP. En nuestro caso utilizaremos la IP pública de nuestro router, es decir, la 200.168.1.1. De este modo, cuando le llegue un paquete al Server-PT le llegará con el siguiente formato:

Si nos fijamos ahora la IP de origen ya no es una IP privada, sino que es la IP pública de nuestro router, se ha enmascarado, se ha hecho NAT. Para conseguir ésto hay que introducir en la consola del router los siguientes comandos:

• ip nat inside source static 192.168.1.100 200.168.1.1 (IP privada e interna por la IP pública del router)
• interface fa0/0
• ip nat inside
• interface fa0/1
• ip nat outside

Vemos como quedaría en la consola (CLI) del router:

Configuración de direccionamiento y enrutamiento

Hay varias maneras de configurar un interfaz en Linux (vamos a ver distribuciones basadas en Debian). Una de ellas sería modificar el fichero /et/network/interfaces y levantando y tirando cada interfaz con los comandos ifdown e ifup. Otra podría ser directamente con el comando ifconfig. Y la última sería utilizando el conjunto de comandos proporcionados por el paquete iproute2. Una de las ventajas de utilizar este paquete es que también nos permite realizar enrutamiento con los comandos que proporciona. Aunque se pueden ejecutar los comandos ip addr help y man ip para conocer las opciones con más detalle, vamos a verlo:

Direccionamiento

• ip addr flush dev eth0: elimina las direcciones IP de la interfaz eth0.
• ip addr del 192.168.1.100/24 dev eth0: elimina las direcciones IP de la interfaz eth0. 
• ip addr add 192.168.1.100/24 dev eth0: asigna la dirección IP 192.168.1.100 con la máscara de red 255.255.255.0 en la interfaz eth0.
• ip addr: visualiza el direccionamiento de todas las interfaces de nuestro equipo.

Activación/Desactivación

• ip link set dev eth0 up: activa/levanta el interfaz eth0.
• ip link set dev eth0 down: desactiva/tira el interfaz eth0. 

Enrutamiento

• ip route add 192.168.1.0/24 via 192.168.2.1 dev eth0: añade la ruta a la red 192.168.1.0/24, enviándolo por el router con la IP 192.168.2.1 y por el interfaz del equipo eth0.
• ip route add default via 192.168.2.1 dev eth0: añade la ruta por defecto (0.0.0.0), enviándolo por el router con la IP 192.168.2.1 y por el interfaz del equipo eth0.
• ip route: visualiza la tabla de rutas del equipo.

NAT con IPTABLES (II) - Implementación

Vamos a ver su implementación en Ubuntu Server. Lo primero que tenemos que hacer es activar el enrutamiento:

• nano /proc/sys/net/ipv4/ip_forward

Y modificamos el valor del parámetro a 1. O también lo podemos hacer directamente:

• echo "1" > /proc/sys/net/ipv4/ip_forward

Si no queremos realizar esta operación cada vez que se arranque el equipo deberemos incluir la siguiente línea en el fichero /et/network/options:

• ip_forward=yes

Para ver las reglas que están en vigor:

• Iptables -t nat -L
• -t: indica la tabla (nat, filter,...)
• -L: Listar.

Si queremos borrar todas las reglas de la tabla:

• Iptables -t nat -F
• -F: indica flush, borrar.

Para establecer las políticas por defecto:

• Iptables -t nat -P PREROUTING ACCEPT
• Iptables -t nat -P OUTPUT ACCEPT
• Iptables -t nat -P POSTROUTING ACCEPT

Hacer un NAT POSTROUTING:

• Iptables -t nat -A POSTROUTING -s <red_interna>/<máscara> -o <interfaz> -j SNAT -to-source <ip_externa>
• -A: agrega, -D elimina.
• -s: red origen, por ejemplo 192.168.1.0/24
• -o: interfaz por donde entran los paquetes, por ejemplo eth1.
• -j: tipo de enmascaramiento, SNAT, MASQUERADE,...
• -to-source: Ip de la interfaz de salida del encaminador 10.0.52.100. En el caso de hacer MASQUERADE esta opción no sería necesaria.

NAT con IPTABLES - Introducción

Cuando un equipo recibe un paquete el destino puede ser el propio equipo (será enviado a los protocolos superiores) o puede ser otro equipo. Es en este caso cuando decimos que está funcionando como un encaminador o Forwarder. Por eso, si queremos comunicar una red privada con una red pública, los clientes de la red privada envían paquetes con la dirección de origen perteneciente a la red privada así que, cuando vienen de vuelta, o hacemos NAT o no podrían recibir las respuestas. Así que vamos a ver como configurar un equipo para que realice NAT (Network Address Translation).

Cuando hacemos NAT tenemos:

• SNAT: cambiar la dirección IP:puerto de origen.
• DNAT: cambiar la dirección IP:puerto de destino.

También tenemos varios tipos de enmascaramiento:

• SNAT: cuando un cliente de la red privada solicita información externa - de la red pública -. El encaminador, cuando recibe el paquete, cambia la IP y el puerto de origen con su IP externa y un puerto no usado. Almacena en una tabla - de traducciones - el valor de la IP y el puerto original frente al valor de la IP y el puerto de salida, es decir, una vez modificados. Cuando reciba la respuesta restaurará los valores originales (UN-NAT automático) antes de proceder a su envío.
• DNAT: se usa normalmente cuando se requiere un servicio de la red privada, por ejemplo: un servidor WEB. El encaminador cambia la IP y el puerto de destino y no existirán UN-DNAT, ya que ese paquete no tendrá retorno.
• MASQUERADE: es idéntico al SNAT, la diferencia redica en que en las reglas de SNAT debes especificar cual es la IP (y puertos) a la que la debe traducir mientras que MASQUERADE averigua cual es la IP de tu interfaz de salida de modo automático. Esto es más cómodo pero menos eficiente, ya que se incrementa el tiempo de proceso. Es recomendable utilizar MASQUERADE si la IP de salida es dinámica.

VLANs en Packet Tracer

Hay varias maneras de crear VLANs en el simulador Packet Tracer

1. VLANs en modo gráfico: hacemos clic en el switch -> config y luego en la pestiñita de base de datos. Desde ahí podemos crear una nueva VLAN.
2. VLANs desde la consola: hacemos clic en el switch -> CLI y tenemos que escribir los siguientes comandos: 
   • enable
   • configure terminal
   • vlan <numero_de_vlan>
   • name <nombre_de_vlan>
   • exit

De todos modos, cuando creamos una en modo gráfico podemos obtener los comandos de la consola que va generando él automáticamente.

Comandos FTP

A raíz de dar el módulo de Servicios en Red del Ciclo Formativo de Grado Medio SMR (Sistemas Microinformáticos y Redes) y de una serie de prácticas que les mandé realizar a mis alumnos me di cuenta de que existe infinidad de documentación en Internet sobre comandos FTP pero casi toda, o la gran mayoría peca de lo mismo:

• Hay mucha información de los comandos básicos como put, get, open, bye,... de los que casi no hace falta comentar nada pero, cuando quieres más información o más ejemplos sobre comandos como macdef, proxy,... te encuentras con que o bien es demasiado ambigua y no dice nada, o bien no existen, o bien es demasiado teórica,...

Así que, aprovechando que un alumno tenía sólo esa parte suspensa y para no mandarlo al examen de recuperación le mandé hacer un trabajo de investigación más en profundidad sobre los mismos. El resultado es este blog que, para más inri, tiene el valor añadido de estar en galego.

Filtros en Wireshark

Wireshark es un scanner o un sniffer de red muy interesante. Muy sencillo de instalar y de utilizar y enormemente potente. Ahora no me voy a meter en profundidad en hablar de él, simplemente me centraré en uno de los problemas que tiene, sobre todo al principio: la cantidad de tráfico que se genera en una red y la cantidad por tanto de información que se nos muestra por pantalla. Así que se hace más que necesario utilizar filtros para poder visualizar con claridad aquello que queremos buscar.

Voy a ir añadiendo diferentes filtros de interés para usar con Wireshark:. Los filtros se suelen introducir en el campo de texto Filter que aparece una vez iniciamos una captura de tráfico por alguno de los interfaces de red de nuestra máquina.

• Filtrar por IP (tanto de origen como de destino):
• ip.addr == <IP_que_queremos_filtrar>

• Filtrar por protocolo DHCP: