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

Question

Eu gostaria de fazer um pouco de NAT em iptables . Assim, todos os pacotes que chegam a 192.168.12.87 e port 80 serão encaminhados para 192.168.12.77 port 80 .

Como fazer isso com o iptables?

Ou

Quaisquer outras maneiras de conseguir o mesmo?

    

Answer 1

Essas regras devem funcionar, supondo que iptables esteja 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ê tem que DNAT tráfego de entrada na porta 80, mas você também precisará SNAT o tráfego de volta.

Alternativa (e melhor abordagem IMHO):

Dependendo do seu Servidor Web (Apache, NGinx), você deve considerar um Proxy HTTP no seu servidor front-end (192.168.12.87):

• mod_proxy (Apache)

• proxy_pass (NGinx)

Answer 2

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

Você pode configurar regras que farão com que os pacotes enviem para 192.168.12.87 para simplesmente serem NATed para 192.168.12.77, mas 192.168.12.77 enviarão as respostas diretamente para o cliente. Essas respostas não passarão pelo host onde sua regra iptables está fazendo NAT, portanto os pacotes em uma direção são traduzidos, mas os pacotes na outra direção não são.

Existem três abordagens para resolver este problema.

1. No primeiro host, não apenas faça o DNAT, mas também faça o SNAT para que o tráfego de retorno seja enviado de volta pelo primeiro host. A regra pode ser algo como iptables -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 nos pacotes na camada Ethernet e não na camada IP. Substituindo o MAC de destino dos pacotes pelo MAC de 192.168.12.77 e enviando-o na Ethernet sem tocar na camada IP, 192.168.12.77 poderia ter 192.168.12.87 configurado em uma interface fictícia e, assim, ser capaz de terminar a conexão TCP com o IP do servidor conhecido pelo cliente.
3. Use a solução ingênua (mas não funciona) no primeiro host. Em seguida, manipule os pacotes de retorno no segundo host fazendo um SNAT no tráfego de retorno. Uma regra pode parecer com iptables -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ê precisa considerar cuidadosamente se realmente precisa fazer esse encaminhamento específico.

1. O uso do SNAT perderá o IP do cliente, então o host número 2 achará que todas as conexões vieram de 192.168.12.87. Além disso, você utilizará a largura de banda do host número 1 para todos os pacotes de resposta, o que levaria um caminho mais direto com as outras abordagens.
2. A abordagem de DSR interromperá todas as outras comunicações entre os dois nós. A abordagem de 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 principal, que não é o IP do 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 é simples e há várias maneiras de quebrar. Por exemplo, se os números das portas forem modificados pelo NAT em qualquer um dos hosts, não há como reconstruí-los. Também não é um dado, que rastreamento de conexão funcionará corretamente, se o primeiro pacote que ele vê for um SYN-ACK em vez de um ACK.

Das três abordagens, acho que a primeira é a que mais provavelmente funcionará. Então, se você não precisa saber 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 apropriadamente, você poderá encaminhar as solicitações para 192.168.12.77 e encaminhar as respostas de volta. 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.