IPTables do Linux Destination NAT com Roteamento Assimétrico?

3

Qual é a maneira correta de lidar com o DNAT quando o tráfego deixa uma interface diferente daquela em que ele chegou? Quando isso acontece, parece que a resposta não tem o endereço de origem substituído automaticamente como se estivesse saindo da mesma interface em que ele chegou.

Editar - o SNAT não funciona para mim:

Chain PREROUTING (policy ACCEPT 386 packets, 23372 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DNAT       all  --  *      *       0.0.0.0/0            12.12.12.5         to:10.7.0.5 

Chain POSTROUTING (policy ACCEPT 288 packets, 18672 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 SNAT       all  --  *      eth0    10.7.0.5             0.0.0.0/0           to:12.12.12.5 
    0     0 SNAT       all  --  *      eth3    10.7.0.5             0.0.0.0/0           to:12.12.12.5 
    8   550 MASQUERADE  all  --  *      eth0    172.16.14.0/30       0.0.0.0/0           
    0     0 MASQUERADE  all  --  *      eth0    10.7.0.0/24          0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 23 packets, 1572 bytes)
 pkts bytes target     prot opt in     out     source               destination

Portanto, nos dois roteadores acima, as mesmas tabelas e o mesmo layout de interface. eth0 em ambos os roteadores são conexões de Internet e eth1 em cada roteador conecta-se à mesma LAN (10.7.0 / 24). O eth3 conecta os dois roteadores entre si.

O que está acontecendo é o ping do endereço 12.12.12.5 de um local na Internet. As respostas vão no roteador B via eth0 e sai eth1 com o destino nat funcionando bem. As respostas estão inserindo eth1 no roteador A e saindo da Internet via eth0 no roteador A. No entanto, o endereço de origem não está sendo sobrescrito e as respostas voltam ao dispositivo enviando os pings com o endereço 10.7.0.5 *.

* Sim, eles chegam a 20 saltos com IP de fonte privada e não são esmagados em qualquer lugar - algo incrível).

Ainda mais Editar:
Ok, aparentemente o SNAT (pelo menos parece do manual do iptables) só combina se é stateful. Então eu preciso de nat sem estado. Isso pode ser feito com o iproute2, mas de acordo com o link ele também pode ser simulado usando - para - destino com SNAT no iptables. No entanto, o meu Ubuntu 10.04 apenas diz opção desconhecida --to-destination ...

    
por Kyle Brandt 26.07.2010 / 18:45

2 respostas

1

Até onde sei, o comportamento de reescrita de endereço que você está descrevendo ocorrerá, desde que o pacote de resposta de saída seja roteado pelo mesmo roteador que rotearam / DNAT para a solicitação de entrada. Se qualquer outro roteador N + 1 no pool de roteadores altamente disponível estiver manipulando o pacote de resposta de saída, eles não "verão" essa conexão no banco de dados de estado do Netfilter.

Parece que você quer um roteador Netfilter altamente disponível que compartilhe informações de máquina de estado NAT . A ferramenta ct_sync mencionada nesse documento foi praticamente abandonada, mas a ferramenta conntrackd das ferramentas conntrack foi desenvolvida para fazer algumas das as mesmas coisas que ct_sync.

Se você está planejando fazer stateful packet filtering (ou NAT, que é apenas um superconjunto de stateful packet filtering) então você vai precisar de um método para distribuir o banco de dados de estados (ou, alternativamente, ir com stateless filtrando na rede e fazendo filtragem com estados em cada host).

    
por 26.07.2010 / 20:04
1

Com o tráfego da Web, isso está se tornando mais comum. Existe um cenário particular com o qual você está preocupado? Eu não tenho SNATs refletindo todos os meus DNATs.

Cenários que me interessam ..

  • eu separo o SNAT no tráfego de escritório / desenvolvimento.
  • Asseguro que o DNAT e o SNAT correspondam ao MX e a todos os MTAs de saída.

Pelo que entendi, a regra geral é evitá-lo quando for razoavelmente possível. Mas com implementações modernas e roteamento dinâmico, acredito que essa perspectiva está se tornando mais obsoleta.

    
por 26.07.2010 / 19:00