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