¿Cómo hacer el reenvío de puertos de una ip a otra ip en la misma red?

Solución 1:

Estas reglas deberían funcionar, asumiendo que iptables se está ejecutando en el servidor 192.168.12.87 :

#!/bin/sh

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -F
iptables -t nat -F
iptables -X

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination 192.168.12.77:80
iptables -t nat -A POSTROUTING -p tcp -d 192.168.12.77 --dport 80 -j SNAT --to-source 192.168.12.87

Tiene que hacer DNAT del tráfico entrante en el puerto 80, pero también necesitará SNAT para devolver el tráfico.

Alternativa (y mejor enfoque en mi humilde opinión):

Dependiendo de cuál sea su servidor web (Apache, NGinx), debe considerar un proxy HTTP en su servidor front-end (192.168.12.87):

• mod_proxy (Apache)

• proxy_pass (NGinx)

Solución 2:

La razón por la que un iptables -t nat -A PREROUTING -d 192.168.12.87 -p tcp --dport 80 -j DNAT --to-destination 192.168.12.77 aparentemente obvio no funcionará es cómo se enrutarán los paquetes de retorno.

Puede configurar reglas que harán que los paquetes enviados a 192.168.12.87 simplemente se conecten mediante NAT a 192.168.12.77, pero 192.168.12.77 enviará las respuestas directamente al cliente. Esas respuestas no pasarán por el host donde su regla de iptables está haciendo NAT, por lo tanto, los paquetes en una dirección se traducen, pero los paquetes en la otra dirección no.

Hay tres enfoques para resolver este problema.

1. En el primer host, no solo haga DNAT, sino también SNAT, de modo que el tráfico de retorno se envíe a través del primer host. La regla podría parecerse a iptables -t NAT -A POSTROUTING -d 192.168.12.77 -p tcp --dport 80 -j SNAT --to-source 192.168.12.87
2. Inspírese en el equilibrio de carga DSR y DNAT los paquetes en la capa Ethernet en lugar de en la capa IP. Al reemplazar la MAC de destino de los paquetes con la MAC de 192.168.12.77 y enviarla por Ethernet sin tocar la capa IP, entonces 192.168.12.77 podría tener 192.168.12.87 configurado en una interfaz ficticia y así poder terminar la conexión TCP con la IP del servidor conocida por el cliente.
3. Utilice la solución ingenua (pero que no funciona) en el primer host. Luego maneje los paquetes de retorno en el segundo host haciendo un SNAT en el tráfico de retorno. Una regla podría parecerse a iptables -t nat -A OUTPUT -p tcp --sport 80 -j SNAT --to-source 192.168.12.87

Cada una de esas tres soluciones tiene inconvenientes, por lo que debe considerar cuidadosamente si realmente necesita hacer este reenvío en particular.

1. Usar SNAT perderá la IP del cliente, por lo que el host número 2 pensará que todas las conexiones provienen de 192.168.12.87. Además, utilizará el ancho de banda a través del host número 1 para todos los paquetes de respuesta, lo que tomaría una ruta más directa con los otros enfoques.
2. El enfoque DSR romperá todas las demás comunicaciones entre los dos nodos. El enfoque DSR realmente solo es apropiado cuando la dirección del servidor no es la IP principal de ninguno de los hosts. Cada host debe tener una IP principal, que no es la IP de DSR.
3. Usar el seguimiento de la conexión en un host para traducir en una dirección y el seguimiento de la conexión en otro host para traducir en la otra dirección es simplemente feo, y hay varias formas en que podría fallar. Por ejemplo, si NAT modifica los números de puerto en cualquiera de los hosts, no hay forma de reconstruirlos. Tampoco es un hecho que el seguimiento de la conexión funcione correctamente si el primer paquete que ve es un SYN-ACK en lugar de un ACK.

De los tres enfoques, creo que el primero es el que tiene más probabilidades de funcionar. Entonces, si no necesita conocer las direcciones IP del cliente, esa es la que recomendaría.

También puede optar por olvidarse de NAT por completo y no intentar resolver el problema en la capa MAC o IP. Puede ir hasta la capa HTTP y buscar una solución allí. En ese caso la solución que encontrarás es un proxy HTTP. Si instala un proxy HTTP en 192.168.12.87 y lo configura adecuadamente, puede hacer que reenvíe las solicitudes a 192.168.12.77 y reenvíe las respuestas. Además, puede insertar un encabezado X-Forwarded-For conservando la IP del cliente original. El servidor en 192.168.12.77 debe configurarse para confiar en el encabezado X-Forwarded-For de 192.168.12.87.