problema com NAT em um cenário múltiplo de uplink

Question

Estou tentando configurar um roteador pc linux que deve lidar com o roteamento e usar o NAT para fornecer conectividade a uma rede interna (também é o servidor DHCP e o firewall). No lado externo o computador possui 2 interfaces com 2 conectores cablemodem conectados (obtém IP público em ambos via DHCP).

O cenário é assim: link

Considerando o papel dinâmico das interfaces externas, eu terei que adicionar alguns scripts para /etc/network/if-up.d e /etc/network/if-down.d para estabelecer os valores corretos, mas agora eu só quero ter certeza de que funciona.

Então, para a configuração básica, estou usando isso: link

Nos testes que fiz um dos computadores pode se conectar à internet, mas o outro não pode. Ao farejar com o wireshark eu vi como o PC que não trabalha envia seus pacotes, o roteador os redireciona depois de aplicar o NAT e as respostas chegam ao roteador novamente, mas o NAT não é "desfeito" e o PC nunca as recebe. No outro lado o outro PC funciona perfeitamente. É claro que tenho dois gateways padrão (um por provedor) que aparecem ao mostrar a lista de rotas (route -n).

Supondo que ambas as interfaces externas tenham endereços e gateways bem conhecidos (estou sempre obtendo os mesmos endereços, então, para o teste, ele deve funcionar da mesma forma), o que está falhando aqui? Devo usar o alvo SNAT em vez do MASQUERADE? devo usar o recurso "route from" do iproute2 em vez de fwmark?

Agradecemos antecipadamente e considera

    

Answer 1

Se o que você postou no seu script é tudo o que você fez, então está faltando alguns passos.

Para dar uma olhada no seu script, minha primeira preocupação são as seguintes linhas. O arquivo /etc/iproute2/rt_tables geralmente não é recriado em cada reinicialização. Você provavelmente está repetidamente adicionando a mesma coisa ao arquivo. Isso causará problemas no futuro. Especialmente se você alterar os números que você usou.

echo "201 $TABLE1" >> /etc/iproute2/rt_tables
echo "202 $TABLE2" >> /etc/iproute2/rt_tables

A próxima questão é que as rotas que você adicionou às novas tabelas usam esses comandos.

ip route add default via $GW1 dev $DEV1 table $TABLE1
ip route add default via $GW2 dev $DEV2 table $TABLE2

Quando você cria uma nova tabela, ela fica completamente vazia. Isso significa que nem inclui rotas para sua rede local.

Então, se você executar um comando como este ip route show table main scope link , deverá ver linhas como esta.

192.168.1.0/24  dev eth1 proto kernel  src 192.168.1.100
192.168.2.0/24  dev eth2 proto kernel  src 192.168.2.100
192.168.3.0/24  dev eth3 proto kernel  src 192.168.3.1

São rotas locais, são necessárias para o roteamento funcionar e você deve recriá-las em todas as tabelas.

O comando genérico ficaria assim. Você precisa executar este comando para cada interface em cada tabela.

/sbin/ip route add table ${TABLE} scope link proto kernel dev ${IFACE} ${ROUTE}

    

Answer 2

Primeiro de tudo, qual é o pool do servidor dhcp? (Na configuração você tem 192.168.3. [2,3] hardtyped. Você verificou o caso de um dos PCs ter um ip desses?)

Você também tem logs habilitados para o iptables? Eles poderiam ajudá-lo.

Eu sei que isso não ajuda muito, mas apenas algumas dicas para solução de problemas: >

    

Answer 3

Tente usar SNAT em vez de MASQUERADE e use a opção --to para alterar o endereço de origem para um dos endereços do gateway.

Como:

iptables -t nat -o $DEV1 -A POSTROUTING -p tcp -j SNAT --to <ethX ip>
iptables -t nat -o $DEV2 -A POSTROUTING -p tcp -j SNAT --to <ethY ip>

Talvez você precise adicionar -s também, mas não posso ter certeza sem testar.

EDITAR : --to refere-se ao endereço da interface, não ao endereço GW.

    

Answer 4

Se você estiver usando o DHCP em ambos os gateways, você verificou se os servidores DHCP do seu provedor não lhe enviaram informações de gateway que seriam tomadas pela sua pilha e modificariam sua tabela de roteamento? Por padrão, é isso que pelo menos o dhclient faz.

    

Answer 5

Depois de não obter resultados com o DHCP, decidi testar algo: Eu estabeleci uma configuração estática para as interfaces externas usando os mesmos endereços que eu sempre obtive. Eu testei ambos do próprio roteador e, claro, funcionou, mas novamente sem resultados para o PC. Na verdade, não funcionou removendo o GW padrão na tabela principal, mesmo que as tabelas secundárias tivessem seus próprios GWs. E funcionou novamente apenas para a interface padrão, desde que eu estabelecesse novamente o GW padrão.

Então, meu palpite é que, de alguma forma, o sistema fwmark não funciona misturado ao NAT quando há várias interfaces (tabelas).

Vou tentar novamente adicionando dois escopos globais para o equilíbrio de tráfego, da mesma forma que aparece no guia do LARTC.

Atenciosamente