Eu tenho uma configuração de uma máquina cliente (Ubuntu 14.04.2 LTS) que se conecta diretamente a duas máquinas servidoras. As máquinas servidoras - na mesma sub-rede - não podem rotear entre si. Os pacotes não devem rotear entre eth1 e eth2 do cliente (ou seja, cliente não é um roteador) e como há um ato de descoberta envolvido, a tabela de roteamento não pode ser pré-programada com os IP do servidorX.
Abaixo está um diagrama bruto. eth0 é deixado de fora desta imagem, pois não pode encaminhar para a sub-rede 172.16.37.0/24 . Não há firewalls (ambos iptables e ufw estão limpos como apito).
client server01
+-------------------+ +-------------------+
| 172.16.37.53 eth1-|----------|-eth1 172.16.37.11 |
| | +-------------------+
| | server02
| | +-------------------+
| 172.16.37.54 eth2-|----------|-eth1 172.16.37.12 |
+------------------ + +-------------------+
O problema que estou encontrando é que ping -I eth2 172.16.37.12 não funciona na máquina cliente. Em suma, o que eu observo via tcpdump é:
client:eth2 emite ping-request server02:eth1 recebe pedido de ping server02:eth1 emite um ARP que tem 172.16.37.54
client:eth2 recebe o ARP que tem Se eu enviar ARPs gratuitos com arping -A -I eth2 172.16.37.54 do cliente, a observação é assim:
client:eth2 emite ping-request server02:eth1 recebe pedido de ping server02:eth1 emite ping-reply para o cliente client:eth2 recebe resposta de ping Quando eu strace d minha sessão de ping, ele continua tentando recvmsg ; nada aparece na tomada.
Aqui está a tabela de roteamento para as observações acima mencionadas:
$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 172.16.187.2 0.0.0.0 UG 0 0 0 eth0 172.16.37.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 172.16.37.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2 172.16.187.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Se eu adicionar uma rota de host na tabela de roteamento para 172.16.37.12 -> eth2 , a resolução de ARP e a operação de ping funcionarão conforme pretendido. No entanto, não posso pré-programar as rotas do host, já que preciso descobrir as máquinas conectadas - tudo que tenho são as interfaces ativas e suas sub-redes.
Os pacotes não são recebidos em eth1 ao testar eth2 (eu tinha praticamente todas as interfaces sendo assistidas). Também é importante notar que esse problema não acontece com eth1 ; ele é capaz de ping -I eth1 corretamente sem a entrada de rota do host (e devido à ordem de rota, a opção -I é excessiva neste caso, mas geralmente não posso confiar na ordem da tabela).
Por que o aplicativo (em um caso, o cache ARP; o outro ping ) está recebendo os pacotes? Como posso rastrear onde os dados estão indo? Tudo parece estar funcionando corretamente até o pacote ser entregue ao aplicativo.
Tags networking ping arp route subnet