Por que uma resposta de ping está sendo enviada para o gateway errado?

0

Em uma pergunta anterior , eu estava tentando determinar por que meus clientes OpenVPN não podiam executar ping na LAN do servidor, mesmo que a LAN do servidor pudesse executar ping nos clientes.

Tendo investigado mais detalhadamente, determinei que, pelo menos no caso de um dos servidores, o problema resulta de uma decisão do kernel de encaminhar um quadro Ethernet contendo a resposta ping na direção de um endereço MAC que não sabe como rotear o pacote.

Então, por exemplo:

10.11.11.7 de:ad:be:7f:45:72 
10.11.11.1 00:10:db:ff:70:01
10.11.11.2 de:ad:be:3b:24:48 

Pings de 10.11.11.7 a 10.8.0.10 funcionam. As solicitações de ping de 10.8.0.10 a 10.11.11.7 chegam como esperado, mas as respostas nunca chegam a 10.8.0.10, aparentemente porque são roteadas na direção de 10.11.11.1 em vez de 10.11.11.2, que contém o servidor VPN que pode rotear para 10.8.0.0 / 24

Por exemplo:

Quando tento executar o ping 10.8.0.10 a partir de 10.11.11.7, a solicitação sai na interface que contém 10.11.11.2, que contém o gateway VPN que pode alcançar 10.8.0.10.

01:46:39.973670 de:ad:be:7f:45:72 > de:ad:be:3b:24:48, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 10.11.11.7 > 10.8.0.10: ICMP echo request, id 49247, seq 6, length 64
0x0000:  4500 0054 0000 4000 4001 1b86 0a0b 0b07  E..T..@.@.......
0x0010:  0a08 000a 0800 37a4 c05f 0006 7ff8 5f4f  ......7.._...._O
0x0020:  0000 0000 53db 0e00 0000 0000 1011 1213  ....S...........
0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
0x0050:  3435 3637                                4567

A resposta esperada chega pelo caminho reverso ...

01:46:40.145368 de:ad:be:3b:24:48 > de:ad:be:7f:45:72, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl  63, id 53200, offset 0, flags [none], proto: ICMP (1), length: 84) 10.8.0.10 > 10.11.11.7: ICMP echo reply, id 49247, seq 6, length 64
0x0000:  4500 0054 cfd0 0000 3f01 8cb5 0a08 000a  E..T....?.......
0x0010:  0a0b 0b07 0000 3fa4 c05f 0006 7ff8 5f4f  ......?.._...._O
0x0020:  0000 0000 53db 0e00 0000 0000 1011 1213  ....S...........
0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
0x0050:  3435 3637                                4567

Por outro lado, quando 10.8.0.10 apaga 10.11.11.7, a solicitação de ping é recebida na interface esperada:

01:46:11.734359 de:ad:be:3b:24:48 > de:ad:be:7f:45:72, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl  63, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 10.8.0.10 > 10.11.11.7: ICMP echo request, id 15635, seq 74, length 64
0x0000:  4500 0054 0000 4000 3f01 1c86 0a08 000a  E..T..@.?.......
0x0010:  0a0b 0b07 0800 c1ff 3d13 004a 65f8 5f4f  ........=..Je._O
0x0020:  0000 0000 7088 0400 0000 0000 1011 1213  ....p...........
0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
0x0050:  3435 3637                                4567

mas parte na direção de 10.11.11.1, em vez de 10.11.11.2:

01:46:11.734383 de:ad:be:7f:45:72 > 00:10:db:ff:70:01, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl  64, id 41757, offset 0, flags [none], proto: ICMP (1), length: 84) 10.11.11.7 > 10.8.0.10: ICMP echo reply, id 15635, seq 74, length 64
0x0000:  4500 0054 a31d 0000 4001 b868 0a0b 0b07  [email protected]....
0x0010:  0a08 000a 0000 c9ff 3d13 004a 65f8 5f4f  ........=..Je._O
0x0020:  0000 0000 7088 0400 0000 0000 1011 1213  ....p...........
0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
0x0050:  3435 3637                                4567

Isso é inesperado, porque a tabela de rotas em 10.11.11.7 está configurada da seguinte maneira:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.11.11.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.8.0.0        10.11.11.2     255.255.255.0   UG    0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         10.11.11.2     0.0.0.0         UG    0      0        0 eth0

Então, minha pergunta é: por que o kernel está enviando a resposta ping na direção de 10.11.11.1, mesmo que o gateway seja definido como 10.11.11.2?

Atualizar:

Poluindo o cache arp em 10.11.11.7 com um endereço mac para 10.11.11.1, isso na verdade aponta para 10.11.11.2, por exemplo:

sudo / sbin / arp -s 10.11.11.1 de: ad: be: 3b: 24: 48

Consegui obter o ping de 10.8.0.10 a 10.11.11.7 funcionando conforme o esperado.

Obviamente, isso foi apenas para fins de demonstração. Por que meu kernel está escolhendo o endereço MAC de destino errado?

Atualização 2:

De acordo com lsmod, o driver de rede é provavelmente:

virtio_net             48449  0 

o que indica, talvez, que a máquina virtual esteja sendo executada no KVM.

Atualização 3:

Essa pergunta foi respondida com a sugestão de ptman de considerar o roteamento baseado em políticas e fontes em sua resposta a outra pergunta minha.

Obrigado ptman!

jonseymour
fonte

Respostas:

2

Esta pergunta foi respondida com a sugestão de ptman de considerar o roteamento baseado em políticas e fontes em sua resposta à minha pergunta.

Em poucas palavras, o problema foi causado por uma rota estática padrão específica do adaptador que estava sendo interpretada antes de qualquer uma das regras na tabela de roteamento principal (que é exibida com / sbin / route).

Essa rota padrão foi interceptar e desviar pacotes destinados a 10.8.0.0/24 e direcioná-los para 10.11.11.1 em vez do salto pretendido de 10.11.11.2. Como resultado, a regra que deveria ter desviado esses pacotes para 10.11.11.2 nunca estava sendo exercida.

A confusão surgiu, em parte, porque / sbin / route não mostra as rotas estáticas específicas do adaptador. Esteja ciente de tais rotas e familiarize-se com: / sbin / ip rule e / sbin / ip route list table all

jonseymour
fonte