Como fazer o encaminhamento de porta de um ip para outro ip na mesma rede?

Eu gostaria fazer algumas NATem iptables. Para que todos os pacotes que chegam 192.168.12.87e port 80sejam encaminhados para 192.168.12.77port 80.

Como fazer isso com o iptables?

Ou

Existem outras maneiras de conseguir o mesmo?

Essas regras devem funcionar, supondo que iptablesesteja em execução no 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

Você precisa DNAT de tráfego de entrada na porta 80, mas também precisará SNAT o tráfego de volta.

Alternativa (e melhor abordagem IMHO):

Dependendo do seu servidor Web (Apache, NGinx), considere um Proxy HTTP no servidor front-end (192.168.12.87):

• mod_proxy (Apache)

• proxy_pass (NGinx)

O motivo pelo qual um aparentemente óbvio iptables -t nat -A PREROUTING -d 192.168.12.87 -p tcp --dport 80 -j DNAT --to-destination 192.168.12.77não funcionará é como os pacotes de retorno serão roteados.

Você pode configurar regras que farão com que os pacotes enviados para 192.168.12.87 sejam simplesmente NATted para 192.168.12.77, mas 192.168.12.77 enviará respostas diretamente de volta ao cliente. Essas respostas não passarão pelo host em que a regra do iptables está executando o NAT; portanto, os pacotes em uma direção são traduzidos, mas os pacotes na outra direção não.

Existem três abordagens para resolver esse problema.

1. No primeiro host, não basta fazer DNAT, mas também SNAT, de modo que o tráfego de retorno seja enviado de volta pelo primeiro host. A regra pode parecer algo comoiptables -t NAT -A POSTROUTING -d 192.168.12.77 -p tcp --dport 80 -j SNAT --to-source 192.168.12.87
2. Inspire-se no balanceamento de carga DSR e DNAT os pacotes na camada Ethernet em vez de na camada IP. Substituindo o MAC de destino dos pacotes pelo MAC de 192.168.12.77 e enviando-o pela Ethernet sem tocar na camada IP, 192.168.12.77 poderia ter 192.168.12.77 configurado em 192.168.12.87 em uma interface fictícia e, assim, poder finalizar a conexão TCP com o IP do servidor conhecido pelo cliente.
3. Use a solução ingênua (mas não está funcionando) no primeiro host. Em seguida, manipule os pacotes de retorno no segundo host, executando um SNAT no tráfego de retorno. Uma regra pode pareceriptables -t nat -A OUTPUT -p tcp --sport 80 -j SNAT --to-source 192.168.12.87

Cada uma dessas três soluções tem desvantagens, portanto, você deve considerar cuidadosamente se realmente precisa fazer esse encaminhamento específico.

1. O uso do SNAT perderá o IP do cliente, portanto, o host número 2 pensará que todas as conexões vieram de 192.168.12.87. Além disso, você usará a largura de banda através do host número 1 para todos os pacotes de resposta, o que levaria uma rota mais direta com as outras abordagens.
2. A abordagem DSR interromperá todas as outras comunicações entre os dois nós. A abordagem DSR é realmente apropriada apenas quando o endereço do servidor não é o IP principal de nenhum dos hosts. Cada host precisa ter um IP primário, que não é o IP DSR.
3. Usar o rastreamento de conexão em um host para traduzir em uma direção e o rastreamento de conexão em outro host para traduzir na outra direção é bastante feio e há várias maneiras de quebrar isso. Por exemplo, se os números de porta forem modificados pelo NAT em qualquer host, não há como reconstruí-los. Também não é certo, que o rastreamento de conexão funcione corretamente, se o primeiro pacote que ele vê é um SYN-ACK em vez de um ACK.

Das três abordagens, acho que a primeira é a que provavelmente funcionará. Portanto, se você não precisar conhecer os endereços IP do cliente, esse é o que eu recomendaria.

Você também pode optar por esquecer completamente o NAT e não tentar resolver o problema na camada MAC ou IP. Você pode ir até a camada HTTP e procurar uma solução lá. Nesse caso, a solução que você encontrará é um proxy HTTP. Se você instalar um proxy HTTP em 192.168.12.87 e configurá-lo adequadamente, poderá encaminhar as solicitações para 192.168.12.77 e encaminhar as respostas novamente. Além disso, ele pode inserir um cabeçalho X-Forwarded-For preservando o IP do cliente original. O servidor em 192.168.12.77 precisa ser configurado para confiar no cabeçalho X-Forwarded-For de 192.168.12.87.