NAT Loopback

From MikroTik Wiki
Jump to: navigation, search

Configuración de NAT Loopback en Mikrotik RouterOS.

Esta es la versión en Castellano del artículo Hairpin_NAT

En la siguiente topología de red, un servidor web está localizado tras el router el espacio de direccionamiento privado, el router esta haciendo re-dirección NAT de la IP pública del router a la IP privada del servidor WEB

Hairpin nat 1.png

La configuración NAT se vería más o menos así:

/ip firewall nat
add chain=dstnat dst-address=1.1.1.1 protocol=tcp dst-port=80 \
  action=dst-nat to-address=192.168.1.2
add chain=srcnat out-interface=WAN action=masquerade

Cuando un cliente en Internet con IP 2.2.2.2 establece una conexión al servidor web, el router ejecuta NAT tal como se configuró.

Hairpin nat 2 new.png

  1. El cliente envía un paquete con IP de origen 2.2.2.2 a IP destino 1.1.1.1 en el puerto tcp/80 solicitando algún recurso web.
  2. El router realiza destination NAT a 192.168.1.2 y cambia la IP de destino en el paquete. La IP origen permanece igual 2.2.2.2.
  3. El servidor responde a la petición del cliente y el paquete respuesta contiene la IP origen 192.168.1.2 e IP destino 2.2.2.2.
  4. El router determina que el paquete hace parte de una conexión previa y deshace el destination NAT previo y pone la IP destino original en el campo IP origen del paquete. La IP destino es 2.2.2.2 y la IP origen es 1.1.1.1.

El cliente recibe el paquete respuesta que esperaba y se establece la conexión..

Cuando un cliente en la misma red interna del servidor web quiere establecer una conexión a la IP pública del servidor web, la conexión se rompe.

Hairpin nat 3.png

  1. El cliente envia un paquete con IP origen 192.168.1.10 a la IP destino 1.1.1.1 en el puerto tcp/80 solicitando algún recurso web.
  2. El reouter realiza destination NAT del paquete a 192.168.1.2 y cambia la IP detsino en el apquete. La IP origen del paquete permanece como 192.168.1.10.
  3. El servidor responde la petición del cliente. Sin embargo, la IP origen de la petición está en la misma subred que el servidor web. El servidor web no envia la respuesta de vuelta al router, sino que la envia directamente a 192.168.1.10 con la IP origen 192.168.1.2.

El cliente recibe el paquete respuesta, pero lo descarta porque este, está esperando recibir un paquete desde 1.1.1.1, no desde 192.168.1.2. Desde el punto de bista del cliente el paquete es inválido y no esta relacionado con ninguna conexión previamente establecida por el cliente.

Para solucionar esto, una regla tipo NAT adicional debe introducirse en el router para forzar que todo el tráfico respuesta flya atraves del router, sin importar si el servidor o el cliente están en la misma subred. La siguiente regla es muy específica y aplica solo al tráfico con el que el anterior inconveniente pudiera presentarser - De existir más servidores con los cuales se pudiera presentar la situación, la misma regla puede extrapolarse para ecitar crar una regla por servicio.

/ip firewall nat
add chain=srcnat src-address=192.168.1.0/24 \
  dst-address=192.168.1.2 protocol=tcp dst-port=80 \
  out-interface=LAN action=masquerade

Hairpin nat 4.png

Con esta regla adicional, el flujo ahora cambia así:

  1. El cliente envia un paquete con una IP origen 192.168.1.10 a una IP destino 1.1.1.1 en el puerto tcp/80 solicitando algún recurso web.
  2. El router realiza destination NAT del paquete a 192.168.1.2 y cambia la IP destino en el paquete. Tambien realiza source NAT en el paquete y cambia la IP origen del mismo con la dirección IP de su interfaz LAN. La direciión IP destino es 192.168.1.2 y la IP origen es 192.168.1.1.
  3. El servidor web responde la solicitud y envia la respuesta con una IP origen 192.168.1.2 de vuelta a la dirección IP de la interfaz LAN del router 192.168.1.1.
  4. El router determina que el paquete hace parte de una conexión previa; deshace ambos procesos: source y destination NAT, luego pone la dirección IP original de destno 1.1.1.1 en el campo de IP origen del paquete, pone la dirección IP original origen 192.168.1.10 en el campo IP destino del paquete.

El cliente recibe el paquete respuesta que esperaba y se establece la conexión.

Sin embargo, el servidor web siempre verá una dirección IP origen 192.168.1.1 para todas las peticiones de clientes internos sin importar la dirección IP real del cliente. No existe un modo alguno de evitar este comportamiento a menos que se use un router capaz de realizar iinspección DNS de los paquetes a nivel de aplicación y que pueda re-escribir los regitros A como corresponde, o dividir el servidor DNS (split-horizon) que sirve a los clientes internos con la IP interna del servidor y a los clientes externos con la IP externa del servidor.

Esto se llama -- entre otros -- hairpin NAT (NAT horquilla) porque el flujo tráfico de los clientes entra y sale del router usando la misma interfaz, este concepto en un dibujo, se ve como horquilla.

Por David González TikAcademy