Защо откриването на съседи в IPv6 не работи през маршрутизиран VPN

Откриването на съседи в IPv6 принадлежи на връзката, а маршрутизираният тунел е граница между две връзки. Това едно изречение обяснява почти всеки доклад за отдалечен хост, който отговаря по адрес и не може да бъде намерен по друг начин. Проверете обхвата на адреса, който тествате, преди да проверите тунела. Локалният за връзката адрес има смисъл само на собствената си връзка, а мултикаст групата на заявения възел е ограничена по същия начин. Нито едно от двете не пресича рутер, затова ping към глобален адрес може да успее, докато откриването за същия хост не работи.

Обхватът идва преди конфигурацията

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

Локален за връзката адрес като запис fe80:: също е обвързан със зона и същият текст може да означава различен хост на друга връзка. Тестването на такъв от другата страна на тунела не доказва нищо освен това, че адресът е двусмислен.

Капанът е предположението, че префиксът е на връзката

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

/128 за една услуга е най-малко изненадващото решение и премахва двусмислието напълно. Спецификацията за откриване на съседи описва набора от съобщения и флага „на връзката“, който решава това.

Мостът променя правилата нарочно

Когато тунелът пренася Ethernet кадри, отдалеченият и локалният сегмент стават една връзка, мултикастът достига до двете страни и откриването на съседи се държи както на суич. Последствията идват с него: наводняване с broadcast и multicast, откриване на дублирани адреси през моста и обяви от рутера, изтичащи в сегмент, който не би трябвало да ги вижда. Домейнът на отказите вече обхваща и два обекта. Нищо от това не е аргумент срещу моста и всяка точка е причина да се прави мост нарочно, а не случайно.

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

Тествайте с адреса, който използва приложението

Потвърдете маршрута с ip -6 route get, прегледайте записа за съсед с ip -6 neigh, след което потвърдете услугата по маршрутизирания път. DNS и обратният път са отделни проверки и здрав запис за съсед не доказва нито една от тях.

Ако приложението настоява за локален за връзката или базиран на откриване адрес, това е разговор за дизайн, а не упражнение по настройка, защото никоя клиентска настройка не прави механизъм, ограничен до връзката, работещ през рутер.

Запишете какъв дизайн имате

Запишете маршрутизиран или мостов преди инцидента, тъй като двете внедрявания отговарят на тези въпроси различно и дежурният инженер не бива да го извежда от профил.

Еднократното прочитане на набора от съобщения премахва изкушението да се обясни свойство на обхвата на връзката като грешка във VPN, което е най-скъпата погрешна диагноза в тази област.