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

Me gustaría hacer algo NATen iptables. De modo que, todos los paquetes que lleguen al 192.168.12.87puerto 80se enviarán al 192.168.12.77puerto 80.

¿Cómo hacer esto con iptables?

O

¿Alguna otra forma de lograr lo mismo?

Estas reglas deberían funcionar, suponiendo que se iptablesesté 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 DNAT el tráfico entrante en el puerto 80, pero también necesitará SNAT el tráfico de regreso.

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)

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

Puede configurar reglas que provoquen que los paquetes enviados a 192.168.12.87 sean simplemente NATizados a 192.168.12.77, pero 192.168.12.77 luego enviará 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 que también haga SNAT de modo que el tráfico de retorno se envíe de vuelta a través del primer host. La regla podría verse algo así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 el MAC de destino de los paquetes con el MAC de 192.168.12.77 y enviarlo a 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. Use la solución ingenua (pero 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 verse así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 detenidamente si realmente necesita hacer este reenvío particular.

1. El uso de 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 interrumpirá todas las demás comunicaciones entre los dos nodos. El enfoque DSR en realidad solo es apropiado cuando la dirección del servidor no es la IP principal de ninguno de los hosts. Cada host necesita tener una IP primaria, que no es la IP DSR.
3. Usar el seguimiento de conexión en un host para traducir en una dirección y el seguimiento de conexión en otro host para traducir en la otra dirección es simplemente feo, y hay varias formas en que podría romperse. 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 funcionará 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 es más probable que funcione. 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á 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-Fordered-For conservando la IP del cliente original. El servidor en 192.168.12.77 debe configurarse para confiar en el encabezado X-Fordered-For de 192.168.12.87.