Hairpin NAT vs DNS Split Horizon

Que pasa cuando tenemos algún servicio publicado en internet, como por ejemplo un servidor web, accesible por DNS para la gente del exterior de la red y un usuario de dentro de la red quiere acceder al mismo.

El Usuario exterior obtendrá una ip pública y podrá acceder, pero el usuario de red local al obtener la misma ip pública, no podrá acceder al mismo ya que es su ip de salida a internet.

Existen dos maneras de abordar esta situación. DNS Split Horizon y Hairpin NAT. Realicé laboratorios con Linux(Debian 12), Cisco y Mikrotik. Veamos como funciona cada una y cuál es la mejor manera de solucionarlo.

Harpin NAT

Hairpin NAT, también conocido como, NAT Loopback o NAT Reflection es una técnica utilizada para permitir que los dispositivos dentro de una red interna accedan a un servicio publicado desde la misma red interna pero a través de su dirección pública. Útil en los escenarios que hablamos más arriba.

Se basa en traducir la dirección ip pública de destino a una ip interna y viceversa para redirigir el tráfico con un NAT. De esta forma el destino es alcanzado correctamente modificando la ip de destino.

Pasamos al lab en Cisco

#Configuramos IP y como va el NAT
interface Gig0/0
ip address 172.16.16.1 255.255.255.0
ip nat outside
#La Interfaz LAN
interface Gig0/1
ip address 10.0.0.1 255.255.255.0
ip nat inside

#Habilitamos el Forward al puerto 80 de nuestro webserver
ip nat inside source static tcp 10.0.0.3 80 172.16.16.1 80

# Para hairpin, necesitamos una ACL y un NAT rule para el tráfico interno
ip access-list extended HAIRPIN
 permit ip 192.168.88.0 0.0.0.255 host 192.168.88.100

ip nat inside source list HAIRPIN interface Gig0/1 overload

Ahora vamos a probar si funciona. Desde la pc dentro de la red (10.0.0.2) vamos a hacer un curl.

curl http://172.16.16.1

Si todo salió correctamente nos responderá con el archivo «index.html» o lo que tenga ese server como default page.

Vamos a resolverlo de la misma forma pero en Mikrotik RouterOS 7

En este caso, en RouterOS, establecemos primero el NAT hacia el webserver desde el exterior:

/ip firewall nat add chain=dstnat action=dst-nat dst-address=172.16.16.1 dst-port=443 to-addresses=10.0.0.3 to-ports=443 protocol=tcp

Y ahora la regla de Hairpin NAT para el tráfico interior.

# SRC-NAT para que el servidor vea como origen la IP del router
/ip firewall nat add chain=srcnat src-address=10.0.0.0/24 dst-address=10.0.0.3 out-interface=LAN protocol=tcp action=masquerade

De esta manera todo el tráfico en el puerto 80 con destino 172.16.16.1 será redireccionado a la ip 10.0.0.3 pero enmascarado como si viniera desde la wan.

DNS Split Horizon

La solución ideal, en estos casos, es ser dueño de un dns (o alquilarlo como CloudFlare o AWS Route 53) que nos permiten aplicar esta técnica. En este caso el servidor de DNS tendrá 2 zonas y al recibir una solicitud de DNS dará una ip u otra dependiendo de dónde viene la solicitud.

Ejemplo:

Zona Interna: midominio.com –> 10.0.0.3

Zona Externa: midominio.com –>172.16.16.1

En Windows Server también es posible con las zonas de búsquedas directas internas.

En Linux podes instalar bind9 para intentar emular DNS Split Horizon en tu laboratorio local.

Editá el named.conf con algo como esto.

view "internal" {
    match-clients { 10.0.0.0/24; };
    zone "empresa.com" {
        type master;
        file "/etc/bind/zones/db.empresa.com.internal";
    };
};

view "external" {
    match-clients { any; };
    zone "empresa.com" {
        type master;
        file "/etc/bind/zones/db.empresa.com.external";
    };
};