DHCP y NAT

   Todos conocemos de cierta forma el funcionamiento de DHCP y de las traducciones de dirección de red (NAT). NAT es ampliamente utilizado hoy día para tratar de reducir el ritmo en el cual se agotan las direcciones IP enrutables públicamente (en la versión 4 del protocolo IP), es decir, las direcciones IP utilizadas en Internet, aunque NAT no solo se utiliza para lo anterior, también puede ser aplicado en estos casos:

1. Migración de servidores, dado que es mas fácil y rápido realizar un NAT a los paquetes cuando se migra un servidor de un segmento de red a otro que tener que decirle manualmente a cada estación de trabajo la nueva dirección IP de este, y aun si utilizamos DNS, dependemos enteramente del TTL, lo cual evita que la transición sea transparente y rápida si no se sincroniza este parámetro, por ello se suele hacer uso de NAT para estos casos.
2. Seguridad, a veces sencillamente no se desea que se conozca el o los segmento(s) de red detrás del router que realiza NAT. 

   DHCP por otro lado, evita que tengamos que configurar manualmente cada estación de trabajo, automatiza enormemente la asignación de direcciones de red y parámetros asociadas a estas, también habilita la autoconfiguración de servicios (como es el caso de los teléfonos IP). Normalmente nos encontramos con 2 casos de implementacion de servicio DHCP.

Caso nº 1

 El servidor DHCP, que puede ser tanto un servidor como un router, se encuentra dentro del mismo segmento de red que los equipos a los que va a servir, como se muestra a continuación: 

  En el caso anterior, no hay problemas, todo funciona correctamente con una configuración mínima. 

Caso nº 2

   El servidor DHCP no se encuentra dentro del mismo segmento de red que la red a la que sirve: 

   En este caso se soluciona haciendo uso de un DHCP-Relay Agent, el cual es un intermediario, que se comunica de parte del cliente que hace la solicitud con el servidor DHCP por medio de mensajes UNICAST, recordemos que DHCP funciona normalmente es con mensajes Broadcast. Esto tampoco tiene mayor inconveniente mas allá de configurar el relay que puede ser el mismo router que sirve de gateway a la LAN que solicita el servicio. 

Caso nº 3

   Básicamente casi igual al anterior, pero, antes del enlace con el DHCP Server se realiza un NAT. En este caso, notaremos que por mas que configuremos el Relay, los dispositivos que solicitan el servicio DHCP no obtienen respuesta, todo parece estar bien, se tiene conectividad con el DHCP Server, verificado mediante ICMP con algún dispositivo de la LAN que solicita el servicio configurado manualmente. Entonces, ¿cual es el problema?

   Recordemos lo siguiente, NAT traduce direcciones en el caso de un Source-NAT que suele ser lo habitual, se traduce la IP de origen a otra, tenemos entonces el siguiente caso:

1. 192.168.0.1 se quiere comunicar con 10.10.10.1.
2. El host A, quien es el que posee la dirección 192.168.0.1, esta detrás de un NAT, esto implica que cuando quiere comunicarse con 10.10.10.1, lo que el host B (el propietario de 10.10.10.1) "ve" como dirección de origen no es la IP del host A, sino la IP que fue asignada producto de la traducción. 
3. Hasta aquí todo bien, de no ser por como funciona DHCP por medio de un Relay tendríamos conectividad.

   Cuando se hace uso de un DHCP-Relay, este, dentro del mensaje DHCP envía un parámetro llamado GIADDR, este parámetro es la dirección IP de la interfaz que intercepto el paquete DHCP, el proceso es el siguiente:

1. Host A, quiere configurarse con DHCP, el segmento de red es 192.168.0.0/24, para esto, envía un mensaje DHCP-Discover en forma de broadcast, tal cual el protocolo lo estipula. 
2. Dentro de ese segmento, se encuentra el relay, cuya dirección IP es 192.168.0.1, este intercepta el broadcast y envía el mensaje como unicast a la dirección del servidor DHCP, incluyendo adicionalmente en el campo GIADDR la dirección IP 192.168.0.1/24 la cual es la dirección de la interfaz que intercepto el primer broadcast, luego en la cabecera IP incluye como dirección de origen, la dirección 192.168.0.1. 
3. Durante el trayecto hasta el servidor DHCP, ocurre un NAT, ahora la dirección IP de origen del mensaje anterior no es 192.168.0.1, sino la asignada por el NAT (diremos que es 201.202.203.1 en este caso). 
4. Cuando el servidor DHCP recibe el mensaje, se fija en los parámetros internos de este, en especifico el GIADDR dado que este parámetro es el que se toma como referencia para elegir el pool de direcciones IP de donde se asignara la dirección al host, recordemos que en este caso es 192.168.0.1/24.
5. Y aquí es donde viene el problema, el servidor DHCP no se va a fijar en la dirección IP de origen de la cabecera IP para responder el mensaje, sino que directamente utiliza la dirección IP incluida en GIADDR para responder, si, el o los routers que intervienen en el camino desde el server DHCP al relay, no conocen la forma de llegar a la red que se estipula en GIADDR, lo cual suele ser lo habitual si se utiliza NAT, el paquete jamas llegara de vuelta y por lo tanto los equipos jamas se podrán autoconfigurar. 

  Para solucionar esto se pueden hacer unas cuantas cosas:

• Aplicar enrutamiento basado en políticas y túneles IP/IP (GRE), de esta forma cuando detectemos el trafico generado por DHCP-Relay, que se maneja por protocolo UDP puertos 67 y 68, obligamos al router a utilizar como next-hop el tunel IP/IP, este encapsulara el paquete original en otro paquete IP y no realizara NAT, se debe realizar esto por norma general en el router que realiza el NAT.
• Utilizar túneles IPSec
• Utilizar una combinación de lo anterior, ejemplo, GREoIPSec.
• Crear rutas especificas a las redes que solicitan el DHCP, algo inútil en el caso de que la red intermediaria sea Internet y que adicionalmente elimina el propósito de NAT si se utiliza como mecanismo de seguridad.