Início / server / Perguntas / 743304
Accepted
cdauth
Asked: 2015-12-16 17:42:03 +0800 CST

Como posso DNAT um pacote vindo de uma ponte de volta para sua fonte com iptables? [duplicado]

  • 772

Tenho um host1que possui uma interface WAN eth0( 1.2.3.4) e uma interface LAN eth1( 10.41.82.1). Dentro da LAN está um host2com o endereço IP 10.41.82.2.

As conexões de entrada 1.2.3.4:22são encaminhadas para host2usar as seguintes regras do iptables em host1:

root@host1:~# iptables -t nat -A OUTPUT     -d 1.2.3.4 -p tcp --dport 22 -j DNAT --to 10.41.82.2:22
root@host1:~# iptables -t nat -A PREROUTING -d 1.2.3.4 -p tcp --dport 22 -j DNAT --to 10.41.82.2:22

Isso funciona bem, exceto quando host2está tentando acessar 1.2.3.4:22:

root@host2:~# telnet 1.2.3.4 22
Trying 1.2.3.4...

root@host2:~# ping 1.2.3.4
PING 1.2.3.4 56(84) bytes of data.
64 bytes from 1.2.3.4: icmp_seq=1 ttl=64 time=0.125 ms
64 bytes from 1.2.3.4: icmp_seq=2 ttl=64 time=0.279 ms

root@host2:~# tcptraceroute 1.2.3.4 22
traceroute to 1.2.3.4, 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
(and so on)

Parece que os pacotes estão sendo encaminhados em um círculo. Como você pode ver, o ping funciona, então as rotas e o encaminhamento de IP estão configurados corretamente.

O que fiz de errado e como posso corrigir o problema?

ATUALIZAR:

Conforme mencionado na resposta de BillThor e conforme descrito no tutorial frozentux no DNAT , preciso adicionar uma SNATregra. Fiz isso agora (observe que adicionei o endereço LAN de host2for -d, pois essa regra é aplicada POSTROUTINGonde o destino do pacote já foi alterado):

root@host1:~# iptables -t nat -A POSTROUTING -d 10.41.82.2 -p tcp --dport 22 -j SNAT --to 10.41.82.1

Infelizmente, isso não resolve o problema e tudo continua igual ao descrito acima. Curiosamente, a SNATregra nunca parece ser correspondida, de acordo com os contadores mostrados ao executar iptables -t nat -nvL.

ATUALIZAÇÃO 2:

Descobri que quando executo tcpdump -i eth1, mesmo quando executo com parâmetros irrelevantes para este caso, como tcpdump -i eth1 port 34238, de repente funciona. Mas apenas enquanto tcpdumpestá em execução.

O que não mencionei até agora porque achei irrelevante é que eth1na verdade é uma ponte e host2é um domínio Xen. Estou começando a suspeitar que meu problema pode estar relacionado a isso.

iptables

2 respostas

  1. Best Answer

    A razão pela qual falhou está ligada ao fato de que eth1é na verdade uma interface de ponte. Na verdade, host2é uma máquina virtual Xen em execução host1e eth1é uma ponte usada para a comunicação entre o host e o convidado.

    Resolvi o problema ligando bridge link set dev vif2.0 hairpin on(ou alternativamente brctl hairpin eth1 vif2.0 on). vif2.0é uma interface de rede virtual criada pelo Xen e faz parte da eth1ponte.

    Portanto, para fazer com que o NAT hairpin funcione em uma interface de ponte, certifique-se de ativar o hairpinning da ponte para a interface (que é uma parte da ponte) na qual os pacotes estão chegando.

    Adicionar uma SNATregra não foi necessário no final.

    systemd-networkdtambém tem uma diretiva para ativar hairpinning em um arquivo *.network:

    [Bridge]
HairPin=true

    Eu não tinha certeza se deveria adicioná-lo eth1.networkou vif2.0.network(que normalmente não existe) no meu caso, mas no final nenhum deles funcionou.

    • 2

  2. O que você está tentando fazer é chamado de hairpin NAT. Seria melhor para o host2 apenas se conectar ao host1.

    Se você quiser que isso funcione, use SNAT e DNAT para o tráfego originado na rede local indo para o IP externo.

    Outra solução que pode funcionar é adicionar uma rota para o host2 ao host1, que direciona o tráfego para o roteador em vez da rede local.

    • 1

relate perguntas