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 E..T....@..h....
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!