Loopback a la dirección IP pública reenviada desde la red local - Hairpin NAT

Esta es una pregunta canónica sobre Hairpin NAT (Loopback NAT).

La forma genérica de esta pregunta es:

Tenemos una red con clientes, un servidor y un enrutador NAT. Hay un reenvío de puertos en el enrutador al servidor, por lo que algunos de sus servicios están disponibles externamente. Tenemos DNS apuntando a la IP externa. Los clientes de la red local no se pueden conectar, pero el trabajo externo.

• ¿Por qué falla esto?
• ¿Cómo puedo crear un esquema de nombres unificado (nombres DNS que funcionan tanto local como externamente)?

Esta pregunta tiene respuestas combinadas de varias otras preguntas. Originalmente hacían referencia a FreeBSD, D-Link, Microtik y otros equipos. Sin embargo, todos intentan resolver el mismo problema.

Lo que estás buscando se llama "horquilla NAT". Las solicitudes de la interfaz interna para una dirección IP asignada a la interfaz externa deben ser NAT'como si vinieran de la interfaz del lado externo.

No tengo ninguna familiaridad con FreeBSD en absoluto, pero leyendo el manual "pf" para OpenBSD ( http://www.openbsd.org/faq/pf/rdr.html ) las soluciones propuestas de DNS de horizonte dividido, utilizando un La red DMZ o el proxy TCP me llevan a creer que "pf" no es compatible con la horquilla NAT.

Miraría ir por la ruta del DNS de horizonte dividido y no usar las direcciones IP en las URL internamente, sino usar nombres.

Dado que esta ha sido elevada para ser la pregunta canónica sobre la horquilla NAT , pensé que probablemente debería tener una respuesta que fuera más válida en general que la actualmente aceptada, que (aunque excelente) se relaciona específicamente con FreeBSD.

Esta pregunta se aplica a los servicios prestados por servidores en redes IPv4 con dirección RFC1918, que se ponen a disposición de usuarios externos mediante la introducción de NAT de destino (DNAT) en la puerta de enlace. Los usuarios internos intentan acceder a esos servicios a través de la dirección externa. Su paquete sale del cliente al dispositivo de puerta de enlace, que reescribe la dirección de destino e inmediatamente la inyecta nuevamente en la red interna. Es este giro brusco que hace el paquete en la puerta de enlace lo que da origen al nombre de horquilla NAT , por analogía con el giro de horquilla .

El problema surge cuando el dispositivo de puerta de enlace reescribe la dirección de destino, pero no la dirección de origen. El servidor luego recibe un paquete con una dirección de destino interna (propia) y una dirección de origen interna (la del cliente); sabe que puede responder directamente a dicha dirección, por lo que lo hace. Como esa respuesta es directa, no pasa por la puerta de enlace, por lo que nunca tiene la oportunidad de equilibrar el efecto del NAT de destino entrante en el paquete inicial al reescribir la dirección de origen del paquete de retorno.

Por lo tanto, el cliente envía un paquete a una dirección IP externa , pero recibe una respuesta de una dirección IP interna . No tiene idea de que los dos paquetes son parte de la misma conversación, por lo que no ocurre ninguna conversación.

La solución es que para los paquetes que requieren dicho NAT de destino y que llegan a la puerta de enlace desde la red interna , también realicen NAT de origen (SNAT) en el paquete entrante, generalmente reescribiendo la dirección de origen para que sea la de la puerta de enlace. Luego, el servidor piensa que el cliente es la puerta de enlace y responde directamente a ella. Eso a su vez le da a la puerta de enlace la oportunidad de equilibrar los efectos de DNAT y SNAT en el paquete entrante al reescribir las direcciones de origen y de destino en el paquete de retorno.

El cliente piensa que está hablando con un servidor externo. El servidor cree que está hablando con el dispositivo de puerta de enlace. Todas las fiestas son felices. Un diagrama puede ser útil en este punto:

Algunos dispositivos de puerta de enlace de consumo son lo suficientemente brillantes como para reconocer aquellos paquetes para los que se necesita el segundo paso NAT, y esos probablemente funcionarán de inmediato en un escenario NAT de horquilla. Otros no lo son, y tampoco lo harán, y es poco probable que se les haga trabajar. Una discusión sobre qué dispositivos de nivel de consumidor son fuera de tema para Server Fault.

Por lo general, se puede decir que los dispositivos de red adecuados funcionen, pero, debido a que no están en el negocio de cuestionar a sus administradores, se les debe decir que lo hagan. Linux usa iptablespara hacer el DNAT así:

iptables -t nat -A PREROUTING  -p tcp --dport 80 -j DNAT --to-destination 192.168.3.11

que habilitará DNAT simple para el puerto HTTP, en un servidor interno encendido 192.168.3.11. Pero para habilitar la horquilla NAT, también se necesitaría una regla como:

iptables -t nat -A POSTROUTING -d 192.168.3.11 -p tcp --dport 80 -j MASQUERADE

Tenga en cuenta que dichas reglas deben estar en el lugar correcto en las cadenas relevantes para que funcionen correctamente, y dependiendo de la configuración de la filtercadena, pueden ser necesarias reglas adicionales para permitir que fluya el tráfico NATted. Todas esas discusiones están fuera del alcance de esta respuesta.

Pero como otros han dicho, habilitar la horquilla NAT de forma adecuada no es la mejor manera de manejar el problema. Lo mejor es el DNS de horizonte dividido , donde su organización sirve diferentes respuestas para la búsqueda original dependiendo de dónde esté el cliente solicitante, ya sea al tener diferentes servidores físicos para usuarios internos versus externos, o al configurar el servidor DNS para responder de manera diferente de acuerdo con La dirección del cliente solicitante.

El problema aquí es que su enrutador no NAT la dirección de su cliente interno. Por lo tanto, el protocolo de enlace TCP falla.

Asumamos las siguientes IP

• Cliente: 192.168.1.3
• Servidor: 192.168.1.2
• Router interno: 192.168.1
• Router externo: 123.123.123.1

Esto es lo que está pasando:

1. El cliente (192.168.1.3) envía TCP-SYN a su IP externa, puerto 80 (123.123.123.1:80)
2. El enrutador ve la regla de reenvío de puertos y reenvía el paquete al servidor (192.168.1.2:80) sin cambiar la IP de origen (192.168.1.3)
3. El cliente espera un SYN-ACK desde la IP externa
4. El servidor envía su respuesta al cliente directamente, porque está en la misma subred. No envía el paquete al enrutador, lo que revertiría el NAT.
5. El cliente recibe un SYN-ACK de 192.168.1.2 en lugar de 123.123.123.1. Y lo descarta.
6. El cliente todavía espera un SYN-ACK desde 123.123.123.1 y agota el tiempo de espera.

¿Por qué no usar dns de horizonte dividido en lugar de codificar direcciones IP en todas partes? Tendría ext.yourdomain apuntando a 217.xxx en el exterior, y luego 192.xxx en el interior.

Si se trata de un enrutador D-Link original (es decir, no Rev. D / Versión de firmware 1.00VG de Virgin Media), debería poder ajustar la configuración para evitar esto. (Sin embargo, ¡estoy de acuerdo con la sugerencia del póster anterior de DD-WRT por muchas otras razones!)

1. Inicie sesión en la interfaz web del enrutador
2. Haga clic en la pestaña Avanzado en la parte superior
3. Haga clic en la pestaña Configuración de firewall a la izquierda
4. Haga clic en el botón de opción Endpoint Independent debajo de TCP Endpoint Filtering , como se muestra en la captura de pantalla a continuación (o vea el emulador de enrutador en el sitio web de D-Link)
5. Guardar cambios; ya terminaste

Esta captura de pantalla es del modelo Rev. C; el tuyo puede ser un poco diferente.

Recientemente respondí una pregunta similar: la NAT estática de Cisco no funciona en el lado LAN y se dio cuenta de que esta es una pregunta canónica. Permítanme resumir la solución aquí.

Primero que nada: olvídate de NAT (si puedes): la pregunta no es sobre la configuración de NAT. Se trata de acceder a un servidor ubicado detrás de NAT desde Internet y LAN. El empleo de dos zonas DNS es una alternativa viable, pero no siempre es la solución. Pero la solución existe y es increíblemente simple (aunque probablemente no sea perfecta):

(1) en el servidor: agregue la dirección IP pública como una dirección IP secundaria en la interfaz de red del servidor con la máscara 255.255.255.255 (el servicio web o lo que desee en el servidor también debería escuchar en esta dirección IP); todos los sistemas operativos modernos le permitirán hacer esto (o se puede usar una interfaz de bucle invertido con la dirección IP pública asignada en lugar de agregar una IP secundaria a la interfaz primaria).

(2) en los hosts LAN: agregue una ruta de host para la dirección IP pública, por ejemplo, para los hosts de Windows use el siguiente comando: route -p add 203.0.113.130 mask 255.255.255.255 192.168.1.11 (también puede usar DHCP " ruta estática "opción para distribuir la ruta). O bien, si hay (a) conmutadores / enrutadores L3 entre los clientes y el enrutador con conexión a Internet, configure esa ruta de host en este (estos) conmutadores / enrutadores intermedios, no en los clientes

Para aquellos relacionados con el protocolo de enlace de tres vías TCP: funcionará bien en la configuración propuesta.

Proporcione comentarios (al menos, vote).

Responderé a mis preguntas solo para ampliar los horizontes para aquellos con problemas similares.

Me contacté con mi ISP y les pedí que intentaran resolver mis problemas. Lo que me habían ofrecido es otra dirección IP pública solo para el servidor, ahora tengo tráfico local en el lado WAN de FreeBSD e hicimos canalizaciones específicas para un rendimiento más rápido del tráfico local a la IP pública del servidor

Desde un punto de vista técnico, la mejor solución para este problema es habilitar IPv6 en su red. Cuando IPv6 está habilitado, debe crear un registro AAAA para su dominio. Mantenga el registro A existente apuntando al IPv4 externo del enrutador . Cree un registro AAAA que apunte a la dirección IPv6 del servidor .

IPv6 tiene suficientes direcciones para evitar NAT, por lo que no necesitará una horquilla NAT para IPv6. Y una vez que haya habilitado IPv6 y creado registros AAAA, cualquier cliente que admita RFC 8305 probará IPv6 antes que IPv4. Esto significa que tampoco necesita la horquilla NAT para IPv4, porque los clientes no la usarán.

Aún necesitará su NAT IPv4 existente para las conexiones salientes y el reenvío de puertos para las conexiones entrantes hasta que la mayor parte del mundo también haya habilitado IPv6.

También es más rápido.

El uso de IPv6 le brindará un mejor rendimiento que la horquilla NAT.

Con la horquilla NAT, su cliente enviará un paquete a través de un conmutador al enrutador, el enrutador realizará dos rondas de traducción y finalmente enviará el paquete a través del conmutador al servidor. Los paquetes del servidor al cliente pasarán por esa ruta completa a la inversa.

Con IPv6, evitas NAT, en cambio, los paquetes se envían directamente a través del conmutador entre cliente y servidor. Esto significa que en un viaje de ida y vuelta reduce la cantidad de pasadas a través del conmutador de 4 a 2, y evita 2 viajes a través del enrutador y las 4 traducciones que el enrutador habría realizado. Esto se traduce en un mejor rendimiento.

Esto es cierto incluso si utiliza un interruptor integrado en la misma caja que el enrutador.

¿Qué pasa si el ISP no tiene IPv6?

Si está utilizando un ISP que no es compatible con IPv6, le preguntaré si debería alojar servidores en esa red. Estas son mis sugerencias sobre qué hacer si el ISP actualmente no es compatible con IPv6.

Primero dígale al ISP que necesita IPv6. Y tal vez les recuerde que el protocolo IPv6 ha existido durante 20 años, por lo que llevan mucho tiempo retrasados ​​en su soporte. Si eso no es suficiente para que el ISP lo tome en serio, comience a buscar otros ISP.

Si encuentra un ISP con soporte para IPv6, puede ejecutar con ambos ISP durante un período de transición. En el enrutador conectado al nuevo ISP, puede desactivar IPv4 en el lado LAN y luego conectar los lados LAN de ambos enrutadores al mismo conmutador. IPv4 e IPv6 son dos protocolos independientes y, como tal, no hay ningún problema si esas conexiones pasan por diferentes enrutadores. Como beneficio adicional, le brinda cierta cantidad de redundancia si una de las conexiones tiene una interrupción.

Si no puede encontrar un ISP con soporte para IPv6, debería considerar mover su servidor a una instalación de alojamiento. Con un servidor en una instalación de alojamiento, usted depende menos de la ubicación geográfica y, por esa razón, existe una mayor competencia entre los proveedores, lo que ayudará a garantizar que haya uno que satisfaga sus necesidades.

Mover el servidor a una instalación de alojamiento no le dará a sus clientes IPv6, pero mover el servidor significa que ya no necesitará una horquilla NAT para alcanzarlo.

Lo que no debes hacer

No encienda IPv6 y cree registros AAAA si no tiene una forma de enrutar el tráfico IPv6. Si su ISP no admite IPv6, pero elige habilitar IPv6 en su LAN de todos modos (tal vez usando direcciones RFC 4193) y crear registros AAAA, funcionará para clientes en su LAN que lleguen al servidor en su LAN. Pero la comunicación entre su LAN y el mundo exterior primero probaría IPv6 (que no funcionaría), y dependería de recurrir a IPv4, que en el mejor de los casos es un poco más lento o, en el peor, no sucede.

Dado que también hice esta pregunta (consulte ¿Cómo accedo a un servicio de red NATed detrás de un firewall desde adentro usando su IP externa? ) Y fui redirigido aquí, pero las respuestas aquí no proporcionaron una solución (en contraste con las explicaciones genéricas ) permitieron que mi Proporciono mi iptablessolución Linux ( específica) aquí para ahorrar a todos unas horas de experimentación. Este archivo está en iptables-restoreformato y se puede leer en iptables directamente (después de editar las direcciones IP, por supuesto). Esto es para un servidor web (puerto 80) y solo para IPv4: las reglas para IPv6 y para SSL (puerto 443) son análogas.

# Port forwarding for VM / Container access with „hairpin NAT“.
*nat
:PREROUTING ACCEPT [3:205]
:INPUT ACCEPT [59:670]
:OUTPUT ACCEPT [16:172]
:POSTROUTING ACCEPT [20:257]

# This was simple port forwarding - access works from outside but not from inside
#-A PREROUTING  -4 -p tcp -i eth0 --dport 80 -j DNAT --to web.local:80

# This is real hairpin NAT which allows „web.local“ to access itself via the VM hosts external IP.
# First we need to masquerade any traffic going out the external interface:
-A POSTROUTING -o eth0 -j MASQUERADE

# Then we need to reroute incoming traffic on the public IP to the local IP:
-A PREROUTING  -4 -p tcp -d web.public.com --dport  80 -j DNAT --to web.local:80

# And finally we need to tell the router that the source IP of any traffic
# coming from the LAN must be source-rewritten when going to the web server:
-A POSTROUTING -4 -p tcp -s lan.local/24 -d web.local --dport  80 -j SNAT --to-source web.public.com:80

COMMIT

Reemplace lan.local, web.localy web.public.comcon su red local (por ejemplo, 10.0.x.0 / 24), la IP local de su servidor web (por ejemplo, 10.0.1.2) y la IP pública de su enrutador (por ejemplo, 4.5.6.7). Esto -4es solo para permitir las reglas IPv6 e IPv4 en el mismo archivo (tales líneas son ignoradas por ip6tables). Además, recuerde poner las direcciones IPv6 entre [corchetes] cuando incluyan declaraciones de puerto, por ejemplo [fe0a:bd52::2]:80.

Esas fueron todas las cosas que me hicieron arrancarme el pelo al intentar implementar realmente las explicaciones de esta pregunta. Espero no haber dejado nada afuera.

Agregaré una respuesta aquí ya que los comentarios aquí no abordaron mi problema particular. Sospecho que es porque me topé con un desagradable error del kernel de Linux. La configuración es:

internet <--> modem 1.1.1.1/30 <--> switch <---> LAN 10.1.1.0/24
                                      ^
        +----------------------+      |
        |              /--eth0 o <----/
        |              |       |           
        | 10.1.1.1/24 br0      |           v (antenna)
        |  1.1.1.2/30  |       |           |
        |              \-wlan0 o ----------/
        +----------------------+ 

A pesar de la imagen compleja, el único cambio relevante a las situaciones cubiertas en otros comentarios es la adición del puente de software, br0. Está allí porque la caja de la puerta de enlace también es un punto de acceso inalámbrico para la LAN.

Nuestra caja de puerta de enlace todavía está realizando tareas de NAT para las máquinas en la LAN. Debido a que solo tiene 1 puerto ethernet, se ve obligado a hacer una horquilla NAT. Sospecho que debería funcionar con las reglas de iptables dadas en otros comentarios aquí, pero en el kernel de Linux 4.9 al menos no lo hace. Bajo 4.9 nuestro, mientras que nuestra caja de acceso puede acceder a Internet, las máquinas en la LAN que intentan acceder a través de NAT no pueden.

tcpdumpmuestra las respuestas a los paquetes entrantes que llegan a eth0, pero no salen de br0. Ejecutar este comando corrige que:

ebtables -t brouter -A BROUTING -d 01:00:00:00:00:00/01:00:00:00:00:00 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-dst 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 --ip-src 10.1.1.0/24 -j ACCEPT
ebtables -t brouter -A BROUTING -p IPv4 -j DROP

Antes de ejecutar ese comando, los paquetes entrantes se procesan de acuerdo con el comportamiento predeterminado del núcleo, que es entregarlos al puente y luego pasarles los módulos de enrutamiento del núcleo. El comando obliga a los paquetes que no son de la LAN a pasar por alto el puente e ir directamente al enrutamiento, lo que significa que el puente no tiene la oportunidad de soltarlos. Las direcciones de difusión y multidifusión deben estar conectadas, de lo contrario, cosas como DHCP y mDNS no funcionarán. si está utilizando IPv6, también debe agregarle reglas.

Es posible que sienta la tentación de solucionar el problema con esto:

brctl hairpin br0 eth0 on
brctl hairpin br0 wlan0 on

Ciertamente estaba tan tentado, fue mi primer intento. Tan pronto como lo hice, las máquinas en la LAN obtuvieron acceso a Internet, por lo que funciona por un tiempo. Entonces ocurrió lo siguiente (y no me importó repetir el experimento):

1. Los tiempos de ping a través de la LAN hasta la puerta de enlace se duplicaron a intervalos de aproximadamente 10 segundos, pasando de 0.1ms a 0.2ms, 0.4ms, 0.8ms, 2ms y así sucesivamente hasta que la LAN no pudo acceder a la caja de la puerta de enlace. Olía a tormenta de paquetes, pero STP estaba encendido en todas partes.
2. No mucho después de que todos los puntos de acceso inalámbrico murieran.
3. Al intentar diagnosticar lo que estaba sucediendo con la conexión inalámbrica, todos los teléfonos IP se reiniciaron.
4. Poco tiempo después, las máquinas cableadas perdieron todo contacto con la LAN.

La única salida era reiniciar todas las máquinas del edificio. La única excepción fueron los interruptores de hardware, que no se pudieron reiniciar. Tenían que ser reiniciados.

Como es una pregunta canónica. Le responderé si tiene un enrutador Sonicwall.

La expresión para saber es la política NAT de bucle invertido

Este documento describe cómo un host en una LAN de SonicWall puede acceder a un servidor en la LAN de SonicWall utilizando la dirección IP pública del servidor para FQDN. Imagine una red NSA 4500 (SonicOS Enhanced) en la que la subred LAN primaria es 10.100.0.0 / 24 y la IP WAN primaria es 3.3.2.1. Supongamos que tiene un sitio web para sus clientes y su nombre de host es. Ya ha escrito las políticas y reglas necesarias para que los extraños puedan acceder al sitio web, pero realmente se está ejecutando en un servidor privado 10.100.0.2. Ahora imagine que es una persona que usa una computadora portátil en el lado privado, con IP de 10.100.0.200. Desea comunicarse con el servidor usando su nombre público, porque hace lo mismo cuando su computadora portátil está con usted en el camino. Si se sienta en el lado privado y solicita http://www.example.com>, el bucle invertido es lo que hace posible que eso funcione, a pesar de que el servidor está realmente junto a usted en una dirección IP local.

Para permitir esta funcionalidad, necesitaría crear una política de bucle de retorno NAT, también conocida como reflexión NAT o horquilla.

Política de bucle invertido utilizando la dirección IP de la interfaz WAN

Login to the SonicWall Management GUI.
Navigate to Manage | Rules | NAT Policies submenu.
Click on the Add button.
Create the following NAT Policy.
Original Source: LAN Subnets (or Firewalled Subnets if you want hosts in other zones to be included)
Translated Source: WAN Interface IP
Original Destination: WAN Interface IP
Translated Destination: (LAN server object)
Original Service: Any
Translated Service: Original
Inbound Interface: Any
Outbound Interface: Any

El sonicwall reconocerá el servicio externo con el que intentas contactar y reescribirá la dirección de destino para que se ajuste a la dirección interna del servidor, por lo que será transparente para la computadora.

En FreeBSD usando PF es fácil como (en su archivo pf.conf):

extif = "tun0"
intif = "em0"
{other rules}...
nat on $intif from any to 192.168.20.8 port 80 -> ($extif)

192.168.20.8 sería el servidor web interno.