Problemas de ping com duas interfaces, mesma sub-rede, conexões diretas para dois hosts separados

3

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
  • O ARP nunca responde (e o cache do arp não é atualizado)

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
  • o aplicativo ping nunca recebe pacotes

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.

    
por doktorstick 23.03.2016 / 00:25

0 respostas