Como faço para encaminhar / NAT todo o tráfego para uma interface / IP para um IP remoto?

Question

Eu tenho um "servidor A" que tem vários IPs anexados a ele, assim:

eth0:0 1.1.1.1
eth0:1 1.1.1.2
eth0:2 1.1.1.3

Eu tenho outro "servidor B" que também tem vários IPs anexados, assim:

eth0:0 2.2.2.1
eth0:1 2.2.2.2
eth0:2 2.2.2.3

Agora, quero configurar o iptables no "Servidor A" para encaminhar / NAT todo o tráfego de entrada em "eth0: 2" para o IP 2.2.2.3 no "Servidor B".

Eu verifiquei que o "Servidor A" é capaz de "conversar" com o "Servidor B" no IP 2.2.2.3. Ping e telnet para abrir portas funciona muito bem e eu tenho o sinalizador para a frente ativado (net.ipv4.ip_forward = 1)

Eu tentei várias maneiras diferentes, DNAT, SNAT, MASQUERADE, etc, mas não consigo fazer nada funcionar.

Esta linha funciona bem se eu tentar encaminhar o tráfego entre os IPs no MESMO servidor:

iptables -t nat -A PREROUTING -d 1.1.1.3 -j DNAT --to-destination 1.1.1.2

Mas se eu desligar o "1.1.1.2" para "2.2.2.3", ele não funciona.

Suponho que preciso de uma segunda regra de iptable para resolvê-lo. Eu tentei com as seguintes regras POSTROUTING sem qualquer sorte (não ao mesmo tempo):

iptables -t nat -A POSTROUTING -d 2.2.2.3 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 2.2.2.3 -j SNAT --to 1.1.1.3
iptables -t nat -A POSTROUTING -j MASQUERADE

O que estou perdendo?

EDIT 1:

Eu finalmente consegui que funcionasse usando o seguinte:

net.bridge.bridge-nf-call-iptables=0

iptables -t nat -A PREROUTING -d 1.1.1.3 -j DNAT --to-destination 2.2.2.3
iptables -t nat -A POSTROUTING -d 2.2.2.3 -j SNAT --to 1.1.1.3

No entanto, agora outro problema apareceu. Todos os logs etc no servidor 2.2.2.3 mostram que todo o tráfego agora vem de 1.1.1.3, como logs do apache, logs de mensagens, etc. Assumo que esta é a natureza do NAT.

No entanto, quando eu faço o encaminhamento de porta padrão no meu roteador doméstico para o meu laptop que está executando o apache, vejo o "IP solicitante" original nos logs. Então, como o roteador faz isso? E como posso fazer o mesmo na configuração do meu servidor?

Resumindo, quero encaminhar todo o tráfego do Servidor A (1.1.1.3) para o Servidor B (2.2.2.3), MAS também quero poder ver de onde veio o tráfego no Servidor B (2.2.2.3 ), ou seja, os logs do apache devem mostrar o IP original do solicitante.

Eu suponho que eu deveria usar algum outro caminho além do NAT para fazer isso acontecer, e isso deve ser possível, já que até meu simples roteador doméstico é capaz de fazer isso.

Uma coisa extra, os IPs anexados ao Servidor A e ao Servidor B são BLOQUEADOS para cada servidor respectivo. Assim, o servidor A NÃO é capaz de enviar tráfego do IP 2.2.2.3. Está bloqueado pelo meu provedor no roteador.

    

Answer 1

Resposta curta à sua pergunta revisada é que existem duas maneiras de fazer isso; ambos exigem que você remova a segunda etapa do NAT (que destrói as informações que você está procurando). Suas opções depois de fazer isso são:

1) Torne o Servidor A o próximo salto para o Servidor B para o tráfego em questão, e é por isso que ele funciona para o seu roteador como mencionado. Isso pode ser feito, em ordem de cludagem, tornando o servidor A a rota padrão para o Servidor B ou usando roteamento de políticas , ou usando alguns iptables sofisticados , ou usando um túnel de algum tipo.

2) "Manualmente" invertendo NAT do servidor A no servidor B, resultando em fluxo de tráfego assimétrico (geralmente desencorajado). Algo como iptables -t nat -I POSTROUTING -j SNAT -s 2.2.2.3 --to 1.1.1.3

Estou 100% confiante na opção (1). Tenho cerca de 90% de confiança em (2).

Para entender isso, você precisa entender o fluxo de tráfego.

1. O cliente X envia um pacote para o 1.1.1.3.
2. Servidor A NATs o destino desse pacote para 2.2.2.3 pré-roteamento, em seguida, roteia o tráfego para 2.2.2.3, então NATs a origem desse pacote para 1.1.1.3 pós-roteamento, então envia o pacote para o Servidor B .
3. O servidor B recebe o pacote no 2.2.2.3 e vê um endereço de origem de 1.1.1.3, conforme a segunda etapa do NAT. Ele processa o pacote e envia a resposta de volta à sua origem (1.1.1.3).
4. O servidor A recebe o pacote no 1.1.1.3, inverte o NAT de origem, encaminha o pacote, inverte o NAT de destino e envia o pacote de volta ao cliente X.
5. O cliente X recebe a resposta de 1.1.1.3

Agora vamos imaginar o que aconteceria se você não tivesse o segundo NAT:

1. O cliente X envia um pacote para o 1.1.1.3.
2. Servidor A NATs o destino desse pacote para 2.2.2.3 pré-roteamento, em seguida, encaminha o tráfego para 2.2.2.3, mas deixa o endereço de origem como X quando envia o pacote para o Servidor B.
3. O servidor B recebe o pacote no 2.2.2.3 e vê um endereço de origem do X. Ele processa o pacote e envia a resposta de volta à sua origem X.
4. O cliente X recebe a resposta do 2.2.2.3 e descarta porque não sabe 2.2.2.3 de Adam!

Para que o Cliente X entenda o pacote, ele precisa chegar ao Cliente X com o mesmo endereço de origem que o destino do pacote original.

A maneira normal de isso acontecer é que o Servidor B tenha a oportunidade de reverter o NAT de pré-roteamento. Para que isso aconteça, você precisa que o pacote retorne posteriormente. Atualmente, você faz isso alterando o endereço de origem do pacote, mas isso destrói as informações que você está solicitando na sua pergunta revisada.

Portanto, o primeiro passo de sua resposta é: você não pode fazer o segundo passo NAT (pós-roteamento SNAT): no servidor A run iptables -t nat -D POSTROUTING -j SNAT --to 1.1.1.3 .

Agora você tem o desafio de reverter o primeiro passo do NAT.

Se o Servidor B vai fazer isso, você precisa do Servidor B para receber os pacotes.

• Isso é relativamente fácil se o servidor A tiver um endereço C na mesma LAN que o servidor B. No servidor B: ip route replace default via C , OR ip route add default via C table a; ip rule add from 2.2.2.3 table a .
• Caso contrário, você tem que fazer algo extravagante com túneis.

Se, no entanto, o roteador na localização do Servidor B não for particularmente sofisticado (inspecionar os pacotes com antecedência e rejeitar aqueles que não estão na seqüência correta para um fluxo de tráfego conhecido), você terá uma opção um pouco mais simples, se super-feia: inverter o NAT no servidor B com base no seu conhecimento do que foi feito no servidor A: no servidor B iptables -t nat -I POSTROUTING -j SNAT -s 2.2.2.3 --to 1.1.1.3 deve fazer o exemplo proposto. Isso deixará o sistema de rastreamento de conexão Linux em A e B um pouco confuso (os servidores não poderão associar o tráfego de retorno ao tráfego de entrada para que o rastreamento de conexão deixe conexões no estado UNREPLIED), mas deve funcionar bem para a maioria do tráfego nas centenas de megabits.

Andando pelo fluxo de tráfego uma última vez neste caso:

1. O cliente X envia um pacote para o 1.1.1.3.
2. Servidor A NATs o destino desse pacote para 2.2.2.3 pré-roteamento, em seguida, encaminha o tráfego para 2.2.2.3, mas deixa o endereço de origem como X quando envia o pacote para o Servidor B.
3. O servidor B recebe o pacote no 2.2.2.3 e vê um endereço de origem do X. Ele processa o pacote e encaminha a resposta de volta para a sua origem X, mas antes de enviá-lo faz o NAT de pós-roteamento do source source 1.1.1.3.
4. O cliente X recebe a resposta que afirma ser da versão 1.1.1.3 e está feliz.

Answer 2

Como você deseja que seu servidor se comporte como um roteador, é necessário verificar algumas coisas:

Primeiro, o encaminhamento de pacotes deve estar habilitado no kernel (por padrão, não é):

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

Você também precisa ter certeza de que o iptables permite o tráfego para a frente (veja sua cadeia FORWARD).

Esta e a regra DNAT devem ser suficientes para fazer o pacote fluir em uma direção. No entanto, se você precisar de um fluxo TCP, você também precisa ter certeza de que você também tem as regras SNAT mencionadas (caso contrário, o host remoto pensará que existe um problema, pois um servidor em 2.2.2.3 está respondendo ao pacote que ele enviou). como 1.1.1.3).

Btw, por motivos de desempenho, é melhor usar o SNAT no lugar do MASQUERADE se você tiver IP estático.