Luego de de nuestra larga recopilación de datos dimos con la solución este dilema que suelen tener muchos de nuestros usuarios. Te compartimos la respuesta y nuestro objetivo es resultarte de gran ayuda.
Solución:
Solución 1:
Dado que esto ha sido elevado a ser el pregunta canónica sobre horquilla NAT, Pensé que probablemente debería tener una respuesta que fuera más válida en general que la aceptada actualmente, que (aunque excelente) se relaciona específicamente con FreeBSD.
Esta pregunta se aplica a los servicios proporcionados 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 luego 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 de nuevo en la red interna. Es este giro brusco que hace el paquete en la puerta de enlace lo que da lugar al nombre 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. A continuación, el servidor 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. Dado que esa respuesta es directa, no pasa a través de la puerta de enlace, que por lo tanto nunca tiene la oportunidad de equilibrar el efecto de la NAT de destino entrante en el paquete inicial reescribiendo la dirección de origen del paquete de retorno.
Por tanto, el cliente envía un paquete a un externo Dirección IP, pero recibe una respuesta de un interno Dirección IP. No tiene idea de que los dos paquetes son parte de la misma conversación, por lo que no ocurre ninguna conversación.
La solucion es que para paquetes que requieren tal NAT de destino y que llegan a la puerta de enlace desde la red interna, para realizar también NAT de origen (SNAT) en el paquete entrante, normalmente reescribiendo la dirección de origen para que sea la de la puerta de enlace. Entonces, el servidor piensa que el cliente es la puerta de enlace en sí 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 reescribiendo las direcciones de origen y destino en el paquete de retorno.
El cliente cree que está hablando con un servidor externo. El servidor cree que está hablando con el dispositivo de puerta de enlace. Todas las partes son felices. Un diagrama puede resultar útil en este punto:
Algunos dispositivos de puerta de enlace del consumidor son lo suficientemente brillantes como para reconocer aquellos paquetes para los que se necesita el segundo paso de NAT, y estos probablemente funcionarán de inmediato en un escenario de NAT de horquilla. Otros no lo son, y por lo tanto no lo harán, y es poco probable que se pueda hacer que funcionen. Una discusión sobre qué dispositivos de nivel de consumidor están fuera del tema de Server Fault.
Por lo general, se puede indicar a los dispositivos de red adecuados que funcionen, pero, dado que no están en el negocio de cuestionar a sus administradores, hay que decirles que lo hagan. Usos de Linux iptables para 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, a un servidor interno en 192.168.3.11. Pero para habilitar la NAT de horquilla, 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 en el filter cadena, es posible que se necesiten reglas adicionales para permitir que fluya el tráfico NAT. Todas estas discusiones están fuera del alcance de esta respuesta.
Pero como han dicho otros, habilitar correctamente la horquilla NAT no es la mejor manera de manejar el problema. El mejor es DNS de horizonte dividido, donde su organización ofrece diferentes respuestas para la búsqueda original dependiendo de dónde se encuentre el cliente solicitante, ya sea al tener diferentes servidores físicos para los usuarios internos y externos, o al configurar el servidor DNS para que responda de manera diferente según la dirección del cliente solicitante.
Solucion 2:
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, pero leyendo el manual “pf” para OpenBSD (http://www.openbsd.org/faq/pf/rdr.html) las soluciones propuestas de DNS de horizonte dividido, usando un La red DMZ o el proxy TCP me llevan a creer que “pf” no es compatible con NAT de horquilla.
Me gustaría seguir la ruta del DNS de horizonte dividido y no usar direcciones IP en URL internamente, sino usar nombres.
Solución 3:
El problema aquí es que su enrutador no hace NAT a la dirección de su cliente interno. Por tanto, el protocolo de enlace de TCP falla.
Asumamos las siguientes direcciones IP
- Cliente: 192.168.1.3
- Servidor: 192.168.1.2
- Enrutador interno: 192.168.1
- Enrutador externo: 123.123.123.1
Esto es lo que está pasando:
- El cliente (192.168.1.3) envía TCP-SYN a su IP externa, puerto 80 (123.123.123.1:80)
- 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)
- El cliente espera un SYN-ACK de la IP externa
- 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.
- El cliente recibe un SYN-ACK de 192.168.1.2 en lugar de 123.123.123.1. Y lo descarta.
- El cliente aún espera un SYN-ACK de 123.123.123.1 y se agota el tiempo de espera.
Solución 4:
¿Por qué no utilizar 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 a 192.xxx en el interior.
Solución 5:
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 solucionar este problema. (¡Sin embargo, estoy de acuerdo con la sugerencia de DD-WRT del póster anterior por muchas otras razones!)
- Inicie sesión en la interfaz web del enrutador
- Haga clic en la pestaña Avanzado en la parte superior
- Haga clic en la pestaña Configuración del cortafuegos a la izquierda
- Haga clic en el punto final independiente botón de radio debajo Filtrado de puntos finales TCP, como se muestra en la captura de pantalla a continuación (o vea el emulador de enrutador en el sitio web de D-Link)
- Guardar cambios; ya terminaste
Esta captura de pantalla es del modelo Rev. C; el tuyo puede ser ligeramente diferente.
Tienes la posibilidad compartir este tutorial si te fue útil.