TL; DR:
Em um cenário de roteamento complexo, as solicitações / mensagens de ICMP e DNS funcionam da maneira esperada do host para a Internet por meio de um roteador incorporado, mas os navegadores da web (por exemplo, TCP e / ou HTTP) não. Como posso depurar problemas com tabelas de roteamento RPDM +? parece que quando eu adiciono um roteamento padrão para a tabela principal do roteador, algumas regras do RPDM são ignoradas e não entendo o comportamento que vejo.
Explicação completa:
Eu tenho um dispositivo integrado ao Linux que está conectado a dois ISPs simultaneamente, e forneço 2 dispositivos host (via eth0, eth1) acesso exclusivo a cada ISP. Isso significa que o host 1 usará exclusivamente a conexão ISP 1 e o host 2 usará exclusivamente a conexão ISP 2. Ao mesmo tempo, quero que o dispositivo incorporado compartilhe uma conexão com um dos ISPs com um host (digamos, através da conexão ISP 2 - eth3).
Eu uso o RPDM para separar o manuseio de cada dispositivo:
32762: from all iif eth3 lookup 102
32763: from all iif eth2 lookup 101
32764: from 192.168.1.102 lookup 102
32765: from 192.168.1.101 lookup 101
onde as tabelas de roteamento são configuradas como por exemplo:
default dev eth2 scope link
123.123.123.123 dev eth2 scope link
124.124.124.124 dev eth3 scope link
127.0.0.0/8 dev lo scope link
192.168.1.0/24 dev bridge0 scope link
Eu uso o baile de máscaras nas duas conexões ISP:
iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE
iptables -t nat -A POSTROUTING -o eth3 -j MASQUERADE
Contanto que o dispositivo não tenha nenhuma rota padrão configurada, e cada um dos hosts tenha o DNS configurado corretamente (isto é, os endereços DNS dos ISPs) - tudo funciona como esperado, sem acesso à Internet ao próprio dispositivo.
Quando adiciono uma rota padrão à tabela de roteamento principal do dispositivo (vamos supor que é eth3), o dispositivo ganha acesso à Internet, mas o host 1 (que deve usar eth2) perde a conectividade e alguns pacotes são perdidos em algum lugar o caminho. O ICMP do host 1 funciona bem, assim como o DNS. O Wireshark no host 1 mostra que há muitas retransmissões TCP. O tcpdump no dispositivo mostra que alguns pacotes do host 1 terminam na eth 3.
Como posso descobrir por que isso não está funcionando? parece que a rota padrão que eu adiciono tem precedência sobre as regras do RPDM, o que não deveria acontecer ..
saída de configuração aqui .
Esclarecimento:
Estou familiarizado com o alvo iptables / TRACE. Eu adicionei o rastreio para cada pacote que entrava na ponte, mas não vi nenhum saindo para a eth3 - apenas para a eth2, ao contrário do log do tcpdump. talvez estou procurando a coisa errada?
+ +
| |
| |
| |
| |
+---------------------------------------------------------+
|---------------------------------------------------------|
|| |eth2 (ISP connection)| |eth3 (ISP connetion 2)||
|| |IP 123.123.123.123 | |IP 124.124.124.124 ||
|| +---------------------+ +-----------------------|
|| ||
|| "Embedded Device" ||
|| +--------+------------+ ||
|| +-------+bridge0 + DHCP server+-----+ ||
|| | |IP 192.168.1.1 | | ||
|| | +---------------------+ | ||
|| | | ||
|--------+------------+ +------+------------|
|| eth0 | |eth1 ||
|| (local connection)| |(local connection)||
|| IP 192.168.10.1 | |IP 192.168.10.2 ||
|---------------------------------------------------------|
+---------------------------------------------------------+
| |
| |
| |
+--------------------+ +--------------------+
|--------------------| |--------------------|
|| host 1 || || host 2 ||
|| IP 192.168.1.100|| || IP 192.168.1.101 ||
|--------------------| |--------------------|
+--------------------+ +--------------------+
Apenas para futuros usuários:
O problema era com um acelerador de pacotes usado no dispositivo embutido que substitui as tabelas de roteamento do linux (chamado SFE, fornecido pela qualcomm). simplesmente ignorou algumas das regras mais complexas.
seu código aberto e um patch foram fornecidos.
boa sorte!
Tags networking routing linux