Вопрос или проблема
У меня есть виртуальная машина macOS, подключенная к сетевому интерфейсу Mac, маршрутизатор OpenWrt имеет подсеть 192.168.54.0/24, а адрес виртуальной машины составляет 192.168.54.15. У меня есть отдельный кластер Kubernetes на виртуальной машине с CIDR Pod 192.168.254.0/28 и CNI Cilium.
Интерфейсы ВМ:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: enp0s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether d2:ce:ba:d6:d3:97 brd ff:ff:ff:ff:ff:ff
inet 192.168.54.15/24 metric 1024 brd 192.168.54.255 scope global enp0s1
valid_lft forever preferred_lft forever
3: cilium_net@cilium_host: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 96:dd:fe:78:83:13 brd ff:ff:ff:ff:ff:ff
4: cilium_host@cilium_net: <BROADCAST,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 8e:66:4c:b5:d5:e8 brd ff:ff:ff:ff:ff:ff
inet 192.168.254.13/32 scope global cilium_host
valid_lft forever preferred_lft forever
6: lxc_health@if5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 5e:2e:e6:d1:d9:ec brd ff:ff:ff:ff:ff:ff link-netnsid 0
10: lxca0a4b8f7dc6d@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 32:c3:c3:a7:16:a4 brd ff:ff:ff:ff:ff:ff link-netns cni-57052f12-1959-6b0e-4271-6b05c21bef6c
Маршруты OpenWrt:
default via 192.168.1.1 dev eth0 src 192.168.1.2
192.168.1.0/24 dev eth0 scope link src 192.168.1.2
192.168.54.0/24 dev br-lan scope link src 192.168.54.1
192.168.254.0/28 via 192.168.54.15 dev br-lan
Брандмауэр OpenWrt:
root@GL-MT3000:~# nft list ruleset
table ip main {
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
oif "eth0" masquerade
}
}
Я не могу пинговать адрес cilium_host
на маршрутизаторе OpenWrt:
root@GL-MT3000:~# ping 192.168.254.13
PING 192.168.254.13 (192.168.254.13): 56 data bytes
^C
--- 192.168.254.13 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
Но если я сначала использую arping:
root@GL-MT3000:~# arping 192.168.254.13
ARPING 192.168.254.13 from 192.168.54.1 br-lan
Unicast reply from 192.168.254.13 [C8:89:F3:AE:C9:7C] 45.140ms
Unicast reply from 192.168.254.13 [C8:89:F3:AE:C9:7C] 3.995ms
Unicast reply from 192.168.254.13 [C8:89:F3:AE:C9:7C] 93.833ms
После этого пинг работает:
root@GL-MT3000:~# ping 192.168.254.13
PING 192.168.254.13 (192.168.254.13): 56 data bytes
64 bytes from 192.168.254.13: seq=0 ttl=64 time=2.993 ms
64 bytes from 192.168.254.13: seq=1 ttl=64 time=84.748 ms
^C
--- 192.168.254.13 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 2.993/43.870/84.748 ms
Но все еще нет ARP-записи для 192.168.254.13:
root@GL-MT3000:~# ip nei
192.168.1.40 dev eth0 used 0/0/0 probes 6 FAILED
192.168.54.2 dev br-lan used 0/0/0 probes 6 FAILED
192.168.1.1 dev eth0 lladdr 10:47:e7:3a:59:a8 ref 1 used 0/0/0 probes 1 REACHABLE
192.168.54.164 dev br-lan used 0/0/0 probes 6 FAILED
192.168.1.8 dev eth0 used 0/0/0 probes 6 FAILED
192.168.54.3 dev br-lan lladdr ec:74:8c:c2:a8:5d ref 1 used 0/0/0 probes 1 REACHABLE
192.168.1.101 dev eth0 used 0/0/0 probes 6 FAILED
192.168.1.155 dev eth0 used 0/0/0 probes 6 FAILED
192.168.1.139 dev eth0 used 0/0/0 probes 6 FAILED
192.168.1.7 dev eth0 used 0/0/0 probes 6 FAILED
192.168.1.100 dev eth0 used 0/0/0 probes 6 FAILED
192.168.1.14 dev eth0 used 0/0/0 probes 6 FAILED
192.168.1.21 dev eth0 used 0/0/0 probes 6 FAILED
192.168.54.6 dev br-lan lladdr 96:89:69:ca:08:66 ref 1 used 0/0/0 probes 1 REACHABLE
192.168.54.68 dev br-lan lladdr c8:89:f3:ae:c9:7c used 0/0/0 probes 6 STALE
192.168.1.106 dev eth0 used 0/0/0 probes 6 FAILED
192.168.1.5 dev eth0 used 0/0/0 probes 6 FAILED
192.168.54.238 dev br-lan used 0/0/0 probes 6 FAILED
192.168.54.15 dev br-lan lladdr c8:89:f3:ae:c9:7c used 0/0/0 probes 1 STALE
192.168.1.4 dev eth0 used 0/0/0 probes 6 FAILED
192.168.1.159 dev eth0 used 0/0/0 probes 6 FAILED
192.168.1.11 dev eth0 used 0/0/0 probes 6 FAILED
192.168.54.4 dev br-lan lladdr 70:31:7f:02:9b:18 ref 1 used 0/0/0 probes 1 REACHABLE
192.168.1.104 dev eth0 used 0/0/0 probes 6 FAILED
192.168.1.3 dev eth0 lladdr 3c:7c:3f:d8:94:d8 used 0/0/0 probes 6 STALE
192.168.1.10 dev eth0 used 0/0/0 probes 6 FAILED
192.168.54.5 dev br-lan lladdr c8:89:f3:ae:c9:7c ref 1 used 0/0/0 probes 1 REACHABLE
192.168.54.134 dev br-lan lladdr 78:df:72:33:42:38 ref 1 used 0/0/0 probes 1 REACHABLE
192.168.1.9 dev eth0 used 0/0/0 probes 6 FAILED
fe80::1 dev eth0 lladdr 10:47:e7:3a:59:a8 router used 0/0/0 probes 0 STALE
Вопросы:
- Почему нет ARP-записи в таблице?
- Почему пинг изначально не работает, несмотря на то, что у меня есть маршрут к нему, и как это исправить?
Ответ или решение
Анализ проблемы с ARP и Ping в Kubernetes на macOS VM через OpenWrt
Введение
Перед нами стоит интересная проблема: Ping к IP-адресу в подсеети cilium не срабатывает до тех пор, пока не выполнится ARPing. Давайте разберем это подробнее, соблюдая формулу FOREST: Факты, Объяснения, Рекомендации, Примеры, Подтверждения, и Заключение.
Факты
Вы используете macOS виртуальную машину, которая подключена к сетевой карте вашего Mac. OpenWrt маршрутизатор работает с подсетью 192.168.54.0/24, а VM имеет IP-адрес 192.168.54.15. Вы также настроили кластер Kubernetes с использованием Cilium CNI, имеющий CIDR подов 192.168.254.0/28. Ваша таблица маршрутизации и настройки ARP показывают, что маршрутизатор не может корректно работать с адресом 192.168.254.13, используемым cilium_host
.
Объяснения
Проблемы с ARP могут быть вызваны несколькими факторами, включая:
-
Отсутствие ARP записи: ARP (Address Resolution Protocol) используется для сопоставления IP-адресов с MAC-адресами. Если устройство, к которому вы хотите подключиться, не имеет соответствующего ARP-запроса, оно не сможет корректно ответить на запрос ping. В вашем случае,
cilium_host
не отвечает на ARP-запросы. -
Подсеть: cilium и ваш Kubernetes кластер используют диапазон IP-адресов, который отличается от 192.168.54.0/24. Если маршрутизатор или устройства в этой подсети не настроены для обработки ARP-запросов, связанных с адресами из диапазона
192.168.254.0/28
, это может привести к тому, что запросы ping не работают. -
Состояние сетевых интерфейсов: Сетевые интерфейсы на вашем OpenWrt и VM могут быть неправильно настроены или, возможно, находятся в состоянии, которое не позволяет им обмениваться пакетами корректно.
Рекомендации
-
Настройка ARP: Убедитесь, что ваш маршрутизатор OpenWrt способен обрабатывать ARP-запросы для подсети 192.168.254.0. Это может потребовать настройки br-lan для приема ARP-запросов из этой подсети.
-
Тестирование маршрутизации: Проверьте, сможете ли вы получить доступ к другим адресам в диапазоне 192.168.254.0/28. Это поможет определить, есть ли общая проблема с маршрутизацией.
-
Проверка конфигурации Cilium: Убедитесь, что параметры Cilium CNI корректно отражают ваши сетевые настройки, а также что он настроен на обработку ARP-запросов.
-
Анализ пакетов: Используйте инструменты анализа трафика (например, tcpdump) для просмотра ARP-запросов и ответов между OpenWrt и
cilium_host
. Это позволит вам увидеть, отправляются ли ARP-запросы и получаются ли на них ответы.
Примеры
-
Запуск команды
tcpdump -i br-lan arp
на OpenWrt может помочь в мониторинге ARP-запросов. Посмотрите, видите ли вы ARP-запросы, когда вы выполняете ping /arping. -
Если вы получите ответ с использованием
arping
, но не сможете установить ARP-запись в таблице, возможно, придется проверить настройки фаервола или сетевые правила на OpenWrt.
Подтверждения
Обратите внимание на вывод команды ip nei
. Если запись о 192.168.254.13
отсутствует, это указывает на то, что ARP-запрос не был успешно обработан. Фактически, ARP-запросы отправляются в широковещательном формате, и если ваш OpenWrt не видит эти пакеты, он не сможет обновить свою таблицу ARP.
Заключение
Проблема с пингом и ARP может быть комплексной, но ряд шагов поможет выявить и устранить ее. Необходимо тщательно проверить маршруты, настройки интерфейсов, а также убедиться в корректной работе сетевых протоколов. Следуя вышеизложенным рекомендациям, вы сможете найти и устранить корень проблемы, обеспечив стабильное взаимодействие между ваших Kubernetes кластером и OpenWrt маршрутизатором.