В предыдущем вопрос, Я пытался определить, почему мои клиенты OpenVPN не могли пинговать локальную сеть сервера, хотя локальная сеть сервера могла пинговать клиентов.
Изучив это дальше, я определил, что, по крайней мере, в случае одного из серверов, проблема возникает из-за решения ядра переслать кадр Ethernet, содержащий ответ ping, в направлении MAC-адреса, который не знает как направить пакет.
Так, например:
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
Пинги с 10.11.11.7 на 10.8.0.10 работают. Запросы Ping от 10.8.0.10 до 10.11.11.7 поступают, как ожидалось, но ответы никогда не доходят до 10.8.0.10, по-видимому, потому что они маршрутизируются в направлении 10.11.11.1 вместо 10.11.11.2, который содержит VPN-сервер, который может маршрутизировать на 10.8.0.0 / 24.
Например:
Когда я пытаюсь выполнить эхо-запрос 10.8.0.10 из 10.11.11.7, запрос уходит на интерфейс, содержащий 10.11.11.2, который содержит шлюз VPN, который может подключиться к 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
Ожидаемый ответ приходит по обратному пути ...
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
С другой стороны, когда 10.8.0.10 проверяет связь с 10.11.11.7, запрос проверки связи получен на ожидаемом интерфейсе:
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
но он уходит в сторону 10.11.11.1 вместо 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
Это неожиданно, потому что таблица маршрутов 10.11.11.7 настроена следующим образом:
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
Итак, мой вопрос: почему ядро отправляет ответ ping в направлении 10.11.11.1, хотя шлюз определен как 10.11.11.2?
Обновить:
Загрязняя кеш arp в 10.11.11.7 с MAC-адресом для 10.11.11.1, это фактически указывает на 10.11.11.2, например:
sudo / sbin / arp -s 10.11.11.1 de: ad: be: 3b: 24: 48
Я смог получить пинг с 10.8.0.10 до 10.11.11.7, работающий должным образом.
Очевидно, это было сделано только для демонстрации. Почему мое ядро изначально выбирает неправильный MAC-адрес назначения?
Обновление 2:
Согласно lsmod, сетевой драйвер, вероятно:
virtio_net 48449 0
что, возможно, указывает на то, что виртуальная машина работает под KVM.
Обновление 3:
На этот вопрос был дан ответ с предложением ptman рассмотреть вопрос о маршрутизации на основе политики и источника в своем ответ на другой мой вопрос.
Спасибо, птман!
На этот вопрос ответил ptman, который предложил рассмотреть политику и маршрутизацию на основе источника в своем ответе на мой вопрос.
Короче говоря, проблема была вызвана статическим маршрутом по умолчанию для конкретного адаптера, который интерпретировался до любого из правил в основной таблице маршрутизации (которая отображается с / sbin / route).
Этот маршрут по умолчанию перехватывает и перенаправляет пакеты, предназначенные для 10.8.0.0/24, и направляет их на 10.11.11.1 вместо предполагаемого перехода 10.11.11.2. В результате правило, которое должно было направить эти пакеты на 10.11.11.2, никогда не применялось.
Отчасти путаница возникла из-за того, что / sbin / route не показывает статические маршруты, специфичные для адаптера. Знайте о таких маршрутах и ознакомьтесь с: / sbin / IP правило и / sbin / ip таблица списка маршрутов все