martes, 11 de junio de 2013

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.

jueves, 6 de junio de 2013

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: