Чому виявлення сусідів 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, а це найдорожча хибна діагностика в цій галузі.