Como redirecionar as solicitações para o meu endereço IP externo / porta para um endereço / porta IP externo diferente no Linux sem alterar o endereço IP de origem?

Question

Eu posso usar os seguintes comandos, mas eles mudam o endereço IP de origem:

iptables -t nat -A PREROUTING -p tcp --dport port -j DNAT --to-destination dest_ip:port
iptables -t nat -A POSTROUTING -j MASQUERADE

Então eu recebo o endereço IP de origem no computador de dest_ip equivalente ao endereço IP deste computador, mas eu quero obter o endereço IP real.

Se eu remover iptables -t nat -A POSTROUTING -j MASQUERADE , não receberei resposta. Como posso resolver este problema?

Todos os endereços IP são endereços IP externos.

    

Answer 1

Usar a regra PREROUTING sem a regra MASQUERADE fará o que você estava pedindo. Ainda não vai funcionar, mas isso é por um motivo diferente.

Se você tiver um cliente em 192.0.2.1 que envia um pacote SYN para seu servidor em 198.51.100.2 , sua primeira regra poderá alterar o endereço de destino desse pacote para seu outro servidor em 203.0.113.3 e encaminhá-lo como tal .

O primeiro problema que você poderia encontrar com essa abordagem seria que a conexão entre 198.51.100.2 e 203.0.113.3 poderia ter filtragem de IP de origem. Isso faria com que o pacote fosse descartado porque o endereço de origem ainda seria 192.0.2.1 , mas o roteador esperava 198.51.100.2 . Se este for o caso em sua rede particular, pode ser contornado usando um túnel.

No entanto, você encontrará outro problema. Quando o pacote chegar em 203.0.113.3 , um SYN-ACK será enviado de volta para 192.0.2.1 . Isso será roteado diretamente para o cliente sem passar pela primeira máquina que aplicou a regra DNAT .

O cliente que enviar um SYN de 192.0.2.1 para 198.51.100.2 verá um SYN-ACK de 203.0.113.3 a 192.0.2.1 . Isso não corresponderá a nenhuma conexão TCP no cliente e o cliente responderá com um pacote RST. Quando o pacote RST atingir 203.0.113.3 , a conexão TCP será fechada no lado do servidor.

No total, quatro pacotes foram transmitidos e a conexão foi fechada no lado do servidor antes de ser totalmente estabelecida. Esses quatro pacotes serão repetidos quantas vezes o cliente retransmitir o SYN até que ele expire.

Existem algumas maneiras de contornar este problema:

• Encaminha todo o tráfego de 203.0.113.3 a 198.51.100.2 para garantir que seja traduzido no caminho de volta. Infelizmente isso tornará o IP público 203.0.113.3 inútil para quaisquer outras finalidades.
• Atribuir um IP secundário a 203.0.113.3 , você poderia, por exemplo, atribuir 10.0.113.3 como o endereço IP secundário. Em 198.51.100.2 você DNAT para 10.0.113.3 e use um túnel para 203.0.113.3 para obter os pacotes para o host de destino adequado. No 203.0.113.3 , você usa uma política de roteamento para garantir que os pacotes com o IP% de origem 10.0.113.3 sejam roteados de volta pelo encapsulamento e outros pacotes sejam roteados pelo seu gateway padrão.
• Pare de usar o NAT e, em vez disso, use uma abordagem de balanceamento de carga do DSR para enviar pacotes de 198.51.100.2 para 203.0.113.3 . Se esses dois não estiverem conectados diretamente a nenhum roteador, isso exigirá novamente um túnel. Mas, desta vez, os pacotes dentro do túnel preservam o endereço de destino original, e 203.0.113.3 não precisará de uma política de roteamento, em vez disso, enviará as respostas corretas diretamente ao cliente. A desvantagem disso é que 203.0.113.3 precisará ser atribuído 198.51.100.2 como um IP secundário e, portanto, 198.51.100.2 e 203.0.113.3 não poderão se comunicar uns com os outros, mas ainda assim se comunicarão bem com todos mais.
• Se você precisar apenas de suporte HTTP, poderá usar um proxy em vez de NAT. Em seguida, você pode usar X-Forwarded-For para permitir que 203.0.113.3 conheça o IP do cliente original. O servidor web em 203.0.113.3 precisará então confiar em X-Forwarded-For em quaisquer conexões originadas de 198.51.100.2 e ignorá-lo em conexões de outros IPs de clientes.