Хост ping ipv6 получил хост назначения недоступным до запуска tcpdump

Сначала (все компьютеры загружались), когда я пропинговал шлюз (компьютер linux, две сетевые карты (одна из них - usb)) с компьютера с Windows, я получил: "Узел назначения недоступен", но когда я запускаю "tcpdump -i LANINTERFACE ip6"на шлюзе пинг получил ответ от шлюза, что не так с моей сетью, есть идеи?
Шлюз и компьютер Windows используют статический IPv6-адрес.

Конфигурация ipv6 для шлюза:

# ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
4: enp0s29f0u2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:XXX:YYYY:ZZZZ:WWWW::1111/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::2e0:4cff:fe53:4458/64 scope link
       valid_lft forever preferred_lft forever
5: enp2s0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:XXX:YYYY:ZZZZ:WWWW::3333/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::216:d3ff:feb3:34a5/64 scope link
       valid_lft forever preferred_lft forever

На компьютерах с ОС Windows (используйте следующий IPv6-адрес, статический):

IPv6 address: 2001:XXX:YYYY:ZZZZ:WWWW::6666
Subnet prefix length: 64
Default Gateway: 2001:XXX:YYYY:ZZZZ:WWWW::1111

Таблица маршрутизации шлюза Linux:

# ip -6 route
2001:XXX:YYYY:ZZZZ::/64 dev enp0s29f0u2  proto kernel  metric 256
2001:XXX:YYYY:ZZZZ::/64 dev enp2s0  proto kernel  metric 256
fe80::/64 dev enp0s29f0u2  proto kernel  metric 256
fe80::/64 dev enp2s0  proto kernel  metric 256
ff00::/8 dev enp0s29f0u2  metric 256
ff00::/8 dev enp2s0  metric 256
default via fe80::1614:4bff:fe60:63eb dev enp2s0  metric 5

Я получил один linux box в качестве маршрутизатора (enp2s0,enp0s29f0u2), а другие - компьютеры с Windows. 'Wan' подключен к адаптеру linux box enp2s0, а enp0s29f0u2 подключен к беспроводному маршрутизатору (режим переключения (dhcp off)), все ПК с Windows подключены к беспроводному маршрутизатору.

Источник

1 ответ

Решение

Есть одна очевидная ошибка в конфигурации вашего шлюза. Оба интерфейса были настроены с одинаковым /64,

В правильной конфигурации вы используете префикс связи, полученный от вашего провайдера по интерфейсу WAN, и вы используете маршрутизированный префикс, полученный от вашего провайдера по интерфейсу LAN. Если маршрутизируемый префикс короче /64 (что это должно быть), то вы можете выбрать любой /64 из этого /48 для вашей локальной сети. Например, если ваш провайдер дал вам маршрутизированный префикс 2001:db8:1234::/48Ваш префикс локальной сети может быть 2001:db8:1234::/64, 2001:db8:1234:ffff::/64, 2001:db8:1234:babe::/48или любой из 65533 других возможностей.

Что происходит, когда вы бежите tcpdump заключается в том, что он (по умолчанию) переводит сетевой интерфейс в беспорядочный режим, что означает, что аппаратное обеспечение начнет принимать кадры Ethernet, даже если они не были отправлены на MAC-адрес этого сетевого интерфейса.

Не очевидно, как эти двое могли быть связаны. Но можно сформулировать гипотезу, которую затем можно проверить.

Может случиться так, что после получения запросов на обнаружение соседнего узла, шлюз отвечает MAC-адресом другого интерфейса. Это, по крайней мере, правдоподобное поведение, учитывая, что оба интерфейса настроены с одинаковым /64, Но когда пакеты отправляются на этот другой MAC-адрес, сетевой интерфейс отбрасывает их до тех пор, пока сетевой интерфейс не переключится в случайный режим.

Есть несколько вещей, которые вы можете сделать, чтобы проверить эту гипотезу:

  • Бежать tcpdump без беспорядочного режима (-p переключатель). Если tcpdump помогает в беспорядочном режиме, но не иначе, мы подтвердили, что беспорядочный режим имеет значение.
  • Посмотрите, какой MAC-адрес отправляется в ответах на обнаружение соседей, и сравните его с двумя сетевыми интерфейсами.
  • Наблюдайте за MAC-адресом назначения на пакетах, отправляемых на IP-адрес, чтобы увидеть, на какой MAC-адрес они отправлены (это можно сделать с помощью Ethereal или tcpdump в беспорядочном режиме).
  • Переконфигурируйте интерфейс, который был настроен с неверным префиксом сети, чтобы увидеть, помогает ли это.
Источник
Другие вопросы по тегам