Зашто откривање суседа IPv6 не ради кроз рутирани VPN

Откривање суседа IPv6 припада једној вези, а рутирани тунел је граница између две везе. Та једна реченица објашњава готово сваку пријаву удаљеног хоста који одговара на адресу и не може се наћи ни на који други начин. Проверите опсег адресе коју тестирате пре него што проверите тунел. Адреса локална за везу има смисла само на својој вези, а multicast група траженог чвора је ограничена на исти начин. Ниједна не прелази рутер, зато ping на глобалну адресу може успети док откривање за исти хост не ради.

Опсег долази пре конфигурације

Захтев и објава суседа носе ограничење скока 255 и не прослеђују се, по дизајну. Рутер између вашег тунела и удаљене LAN мреже прослеђује IPv6 пакете и не преноси поруке суседа у његово име. Зато кеш суседа на интерфејсу тунела садржи партнера и мало тога другог, што је исправно понашање, а не недостатак који треба поправити.

Адреса локална за везу попут уноса fe80:: такође је везана за зону, а исти текст може означавати други хост на другој вези. Тестирање такве адресе са друге стране тунела не доказује ништа осим да је адреса двосмислена.

Замка је претпоставка да је префикс на вези

Хост који верује да је префикс на вези шаље захтев суседа уместо да пакет преда свом рутеру, а то укључује /64 рутиран ка удаљеној локацији. Када такав префикс стигне као на вези, хост пита локалну везу за хост који живи негде другде, и ништа не одговара. Рутирајте нешто мање ка удаљеном хосту или завршите префикс на рутеру који ће одговарати за њега.

/128 за једну услугу најмање је изненађујуће решење и потпуно уклања двосмисленост. Спецификација откривања суседа описује скуп порука и заставицу „на вези“ која то одлучује.

Мост мења правила намерно

Када тунел преноси Ethernet оквире, удаљени и локални сегмент постају једна веза, multicast стиже на обе стране, а откривање суседа се понаша као на прекидачу. Последице долазе са тим: поплава broadcast-а и multicast-а, откривање дуплираних адреса преко моста и објаве рутера које цуре у сегмент који их не би требало да види. Домен отказа сада покрива и две локације. Ништа од тога није аргумент против моста, и свака тачка је разлог да се мост гради намерно, а не случајно.

Пребацивање профила са TUN на TAP да би се откривање појавило погрешан је редослед радњи. Сервер, клијент и план адресирања морају се сложити, а мобилни клијенти уопште не нуде TAP интерфејс, па такав дизајн ради на преносном рачунару, а пада на телефону. Прокси и релеји суседа одвојени су механизми са сопственим захтевима и припадају документованом уређењу мрежног администратора, а не подешавањима апликације.

Тестирајте адресом коју апликација користи

Потврдите руту помоћу ip -6 route get, прегледајте унос суседа помоћу ip -6 neigh, затим потврдите услугу преко рутиране путање. DNS и повратна путања одвојене су провере и здрав унос суседа не доказује ниједну од њих.

Ако апликација инсистира на одредишту локалном за везу или на откривању, то је разговор о дизајну, а не вежба подешавања, јер ниједна клијентска поставка не чини механизам ограничен на везу функционалним кроз рутер.

Запишите који дизајн имате

Забележите рутирано или мостовно пре инцидента, јер две имплементације на ова питања одговарају различито и дежурни инжењер то не би требало да закључује из профила.

Једнократно читање скупа порука уклања искушење да се својство опсега везе објасни као VPN грешка, што је најскупља погрешна дијагноза у овој области.