Почему обнаружение соседей IPv6 не работает через маршрутизируемый VPN

Обнаружение соседей IPv6 относится к одному каналу, а маршрутизируемый туннель — это граница между двумя каналами. Это одно предложение объясняет почти каждое сообщение об удалённом узле, который отвечает по адресу и не находится никаким другим способом. Проверьте область действия адреса, который вы тестируете, прежде чем проверять туннель. Адрес, локальный для канала, имеет смысл только в своём канале, и группа multicast запрошенного узла ограничена так же. Ни один из них не пересекает маршрутизатор, поэтому ping по глобальному адресу может проходить, а обнаружение для того же узла — нет.

Область действия важнее настройки

Запрос и объявление соседа несут ограничение переходов 255 и не пересылаются, по замыслу. Маршрутизатор между вашим туннелем и удалённой LAN пересылает пакеты IPv6 и не передаёт сообщения соседей от его имени. Поэтому кэш соседей на интерфейсе туннеля содержит партнёра и немного другое, что является правильным поведением, а не дефектом для исправления.

Адрес, локальный для канала, например запись fe80::, тоже ограничен зоной, и один и тот же текст может обозначать другой узел в другом канале. Проверка такого адреса с другой стороны туннеля ничего не доказывает, кроме того, что адрес неоднозначен.

Ловушка — предположение, что префикс находится в канале

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

/128 для одной службы — наименее неожиданное решение, и оно полностью снимает неоднозначность. Спецификация обнаружения соседей описывает набор сообщений и флаг нахождения в канале, который это решает.

Мосты по замыслу меняют правила

Когда туннель передаёт кадры Ethernet, удалённый и локальный сегменты становятся одним каналом, multicast доходит до обеих сторон, а обнаружение соседей ведёт себя как на коммутаторе. Последствия приходят вместе с этим: лавина широковещательных и multicast-пакетов, обнаружение дублирующихся адресов через мост и объявления маршрутизатора, просачивающиеся в сегмент, который не должен их видеть. Домен отказа теперь охватывает и две площадки. Ничто из этого не говорит против моста, и каждый пункт — причина строить мост осознанно, а не случайно.

Переключение профиля с TUN на TAP, чтобы обнаружение появилось, — неверный порядок действий. Сервер, клиент и план адресации должны согласоваться, а мобильные клиенты вообще не предлагают интерфейс TAP, поэтому такой проект работает на ноутбуке и отказывает на телефоне. Прокси и ретрансляторы соседей — отдельные механизмы со своими требованиями, и они относятся к документированному устройству администратора сети, а не к настройкам приложения.

Проверяйте тем адресом, который использует приложение

Подтвердите маршрут с помощью ip -6 route get, просмотрите запись соседа с помощью ip -6 neigh, затем подтвердите службу по маршрутизируемому пути. DNS и обратный путь — отдельные проверки, и исправная запись соседа не доказывает ни одну из них.

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

Запишите, какое решение у вас

Зафиксируйте до инцидента, маршрутизируемое оно или с мостом, поскольку два развёртывания отвечают на эти вопросы по-разному, и дежурный инженер не должен выводить это из профиля.

Однократное чтение набора сообщений убирает соблазн объяснять свойство области канала как ошибку VPN, а это самая дорогая неверная диагностика в этой области.