In una domanda precedente , stavo cercando di determinare perché i miei client OpenVPN non potevano eseguire il ping della LAN del server, anche se la LAN del server poteva eseguire il ping dei client.
Dopo aver esaminato ulteriormente questo, ho determinato che, almeno nel caso di uno dei server, il problema deriva da una decisione del kernel di inoltrare un frame Ethernet contenente la risposta ping nella direzione di un indirizzo MAC che non conosce come instradare il pacchetto.
Quindi, per esempio:
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
Ping dal 10.11.11.7 al 10.8.0.10 di lavoro. Le richieste di ping dal 10.8.0.10 al 10.11.11.7 arrivano come previsto, ma le risposte non raggiungono mai il 10.8.0.10 apparentemente perché vengono instradate nella direzione del 10.11.11.1 invece del 10.11.11.2 che contiene il server VPN che può instradare al 10.8.0.0 / 24.
Per esempio:
Quando provo a eseguire il ping di 10.8.0.10 dal 10.11.11.7, la richiesta lascia sull'interfaccia contenente il 10.11.11.2 che contiene il gateway VPN che può raggiungere il 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
La risposta prevista arriva tramite il percorso inverso ...
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
D'altra parte, quando 10.8.0.10 esegue il ping del 10.11.11.7, la richiesta di ping viene ricevuta sull'interfaccia prevista:
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
ma parte nella direzione del 10.11.11.1, invece del 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
Ciò è imprevisto, poiché la tabella di route su 10.11.11.7 è configurata come segue:
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
Quindi, la mia domanda è: perché il kernel sta inviando la risposta ping nella direzione del 10.11.11.1, anche se il gateway è definito come 10.11.11.2?
Aggiornare:
Inquinando la cache arp in 10.11.11.7 con un indirizzo mac per 10.11.11.1, che in realtà punta a 10.11.11.2 ad esempio:
sudo / sbin / arp -s 10.11.11.1 de: ad: be: 3b: 24: 48
Sono stato in grado di ottenere il ping dal 10.8.0.10 al 10.11.11.7 funzionando come previsto.
Ovviamente, questo era solo a scopo dimostrativo. Perché il mio kernel sceglie innanzitutto l'indirizzo MAC di destinazione errato?
Aggiornamento 2:
Secondo lsmod, il driver di rete è probabilmente:
virtio_net 48449 0
che indica, forse, che la macchina virtuale è in esecuzione in KVM.
Aggiornamento 3:
A questa domanda è stato risposto con il suggerimento di ptman di prendere in considerazione l'instradamento basato su criteri e fonti nella sua risposta a un'altra mia domanda.
Grazie ptman!