Ping работает только после арпинга адреса назначения.

Вопрос или проблема

У меня есть виртуальная машина 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 могут быть вызваны несколькими факторами, включая:

  1. Отсутствие ARP записи: ARP (Address Resolution Protocol) используется для сопоставления IP-адресов с MAC-адресами. Если устройство, к которому вы хотите подключиться, не имеет соответствующего ARP-запроса, оно не сможет корректно ответить на запрос ping. В вашем случае, cilium_host не отвечает на ARP-запросы.

  2. Подсеть: cilium и ваш Kubernetes кластер используют диапазон IP-адресов, который отличается от 192.168.54.0/24. Если маршрутизатор или устройства в этой подсети не настроены для обработки ARP-запросов, связанных с адресами из диапазона 192.168.254.0/28, это может привести к тому, что запросы ping не работают.

  3. Состояние сетевых интерфейсов: Сетевые интерфейсы на вашем OpenWrt и VM могут быть неправильно настроены или, возможно, находятся в состоянии, которое не позволяет им обмениваться пакетами корректно.

Рекомендации

  1. Настройка ARP: Убедитесь, что ваш маршрутизатор OpenWrt способен обрабатывать ARP-запросы для подсети 192.168.254.0. Это может потребовать настройки br-lan для приема ARP-запросов из этой подсети.

  2. Тестирование маршрутизации: Проверьте, сможете ли вы получить доступ к другим адресам в диапазоне 192.168.254.0/28. Это поможет определить, есть ли общая проблема с маршрутизацией.

  3. Проверка конфигурации Cilium: Убедитесь, что параметры Cilium CNI корректно отражают ваши сетевые настройки, а также что он настроен на обработку ARP-запросов.

  4. Анализ пакетов: Используйте инструменты анализа трафика (например, tcpdump) для просмотра ARP-запросов и ответов между OpenWrt и cilium_host. Это позволит вам увидеть, отправляются ли ARP-запросы и получаются ли на них ответы.

Примеры

  1. Запуск команды tcpdump -i br-lan arp на OpenWrt может помочь в мониторинге ARP-запросов. Посмотрите, видите ли вы ARP-запросы, когда вы выполняете ping /arping.

  2. Если вы получите ответ с использованием arping, но не сможете установить ARP-запись в таблице, возможно, придется проверить настройки фаервола или сетевые правила на OpenWrt.

Подтверждения

Обратите внимание на вывод команды ip nei. Если запись о 192.168.254.13 отсутствует, это указывает на то, что ARP-запрос не был успешно обработан. Фактически, ARP-запросы отправляются в широковещательном формате, и если ваш OpenWrt не видит эти пакеты, он не сможет обновить свою таблицу ARP.

Заключение

Проблема с пингом и ARP может быть комплексной, но ряд шагов поможет выявить и устранить ее. Необходимо тщательно проверить маршруты, настройки интерфейсов, а также убедиться в корректной работе сетевых протоколов. Следуя вышеизложенным рекомендациям, вы сможете найти и устранить корень проблемы, обеспечив стабильное взаимодействие между ваших Kubernetes кластером и OpenWrt маршрутизатором.

Оцените материал
Добавить комментарий

Капча загружается...