Reenviar tráfico a la red VPN


3

Tengo un servidor en la nube ejecutándose en Ubuntu 14.04 que está conectado con un túnel IPsec.

El servidor tiene una interfaz real con una IP pública xxxx y una interfaz virtual 172.16.100.1. Todo el tráfico a la red remota debe enrutarse a través de la interfaz virtual con IP 172.16.100.1. Por lo tanto, he configurado una ruta de entrada. Esto funciona correctamente para todo el tráfico que se genera en ese servidor.

route add -net 172.17.1.2/21 gw 172.16.100.1 dev eth0:1

Pero otro requisito es que si el servidor de la nube recibe tráfico en su IP pública con un puerto específico, ese tráfico también debe reenviarse a la red remota. Lo intenté agregando una entrada de tabla IP:

iptables -t nat -A PREROUTING -p tcp --dport 45678 -j DNAT --to-destination 172.17.1.2:29871

pero el problema es que de alguna manera ignora la configuración de enrutamiento y solo reenvía la solicitud con su IP de origen en lugar de usar 172.16.xx

¿Es esa configuración incluso el enfoque correcto o estoy completamente equivocado? ¿Qué más tengo que configurar para reenviar el tráfico correctamente?


Esta pregunta carece de las configuraciones de interfaz reales. "Túnel IPSec" tiene muchos significados y por sí solo no dice nada acerca de su configuración.
drookie

¿Qué información te falta? toda la configuración de VPN se basa en Strongswan, pero no estoy seguro de si es un problema con esa VPN en sí. Como se dijo al generar algo de tráfico en el servidor mismo, se enruta correctamente a través de 172.16.100.1 a la máquina remota.
Patrick L

No estoy seguro de si es un problema en absoluto. Hasta ahora no puedes explicar uno.
drookie

el problema es que cuando el servidor recibe una solicitud en su IP pública, esa solicitud solo se reenvía con su IP de origen original, pero lo que quiero es que la solicitud se reenvíe con la IP privada 172.16.100.1 como fuente
Patrick L

Eso sería una total ignorancia de cómo funciona el protocolo IP. La pila siempre responde desde una dirección en la que se recibió la solicitud. De lo contrario, no hay forma posible de determinar qué paquetes pertenecen a qué sesión.
drookie

Respuestas:


0

agregar la siguiente entrada POSTROUTING ha resuelto el problema:

iptables -t nat -A POSTROUTING -p tcp --dport 29871 -j SNAT --to-source 172.16.100.1
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.