Waarom IPv6-buurontdekking oor 'n geroteerde VPN misluk

IPv6-buurontdekking hoort by 'n skakel, en 'n geroteerde tonnel is die grens tussen twee skakels. Daardie een sin verklaar byna elke verslag van 'n afgeleë gasheer wat op sy adres antwoord en deur niks anders gevind kan word nie. Kontroleer die omvang van die adres wat jy toets voordat jy die tonnel ondersoek. 'n Skakel-plaaslike adres het net op sy eie skakel betekenis, en 'n aangevraagde-nodus-multicastgroep het dieselfde omvang. Nie een van hulle steek 'n roeteerder oor nie, en daarom kan 'n ping na 'n globale adres slaag terwyl ontdekking vir dieselfde gasheer misluk.

Omvang kom voor konfigurasie

Buurversoek en buuraankondiging dra 'n spronglimiet van 255 en word volgens ontwerp nie aangestuur nie. Die roeteerder tussen jou tonnel en die afgeleë LAN stuur IPv6-pakkette aan en stuur nie buurboodskappe namens dit nie. Dus bevat die buurkas op die tonnelkoppelvlak die eweknie en min anders, wat korrekte gedrag is en nie 'n fout om reg te maak nie.

'n Skakel-plaaslike adres soos 'n fe80::-inskrywing is ook sonegebonde, en dieselfde teks kan op 'n ander skakel 'n ander gasheer aandui. Om een van die ander kant van die tonnel te toets bewys niks behalwe dat die adres dubbelsinnig is.

Die strik is die aanname dat die voorvoegsel op die skakel is

'n Gasheer wat glo 'n voorvoegsel is op die skakel, stuur 'n buurversoek in plaas daarvan om die pakket aan sy roeteerder te gee, en dit sluit 'n /64 in wat na 'n afgeleë terrein geroteer word. Wanneer so 'n voorvoegsel as op-die-skakel aankom, vra die gasheer die plaaslike skakel vir 'n gasheer wat elders woon, en niks antwoord nie. Roeteer iets kleiner na die afgeleë gasheer, of beëindig die voorvoegsel by die roeteerder wat namens dit sal antwoord.

'n /128 vir 'n enkele diens is die minste verrassende reëling, en dit verwyder die dubbelsinnigheid heeltemal. Die spesifikasie vir buurontdekking beskryf die boodskapstel en die op-die-skakel-vlag wat dit bepaal.

Oorbrugging verander die reëls doelbewus

Wanneer die tonnel Ethernet-rame dra, word die afgeleë en plaaslike segmente een skakel, multicast bereik beide kante, en buurontdekking gedra hom soos op 'n skakelaar. Die gevolge kom saam daarmee: uitsaai- en multicast-vloeding, duplikaatadresopsporing oor die brug, en roeteerderaankondigings wat in 'n segment lek wat hulle nie behoort te sien nie. Die foutdomein strek nou ook oor twee terreine. Niks daarvan is 'n argument teen oorbrugging nie, en elke punt is 'n rede om doelbewus eerder as toevallig te brug.

Om 'n profiel van TUN na TAP te verander om ontdekking te laat verskyn, is die verkeerde volgorde van bewerkings. Die bediener, kliënt en adresseringsplan moet almal saamstem, en mobiele kliënte bied glad nie 'n TAP-koppelvlak nie, so so 'n ontwerp werk op 'n skootrekenaar en misluk op 'n selfoon. Buurproksieë en herleiers is afsonderlike meganismes met hul eie vereistes, en hulle hoort by die netwerkadministrateur se gedokumenteerde reëling eerder as by 'n app se instellings.

Toets met die adres wat die toepassing gebruik

Bevestig die roete met ip -6 route get, inspekteer die buurinskrywing met ip -6 neigh, en bevestig dan die diens oor die geroteerde pad. DNS en die terugpad is afsonderlike kontroles, en 'n gesonde buurinskrywing bewys nie een daarvan nie.

As die toepassing daarop aandring om 'n skakel-plaaslike of ontdekkingsgebaseerde bestemming te gebruik, is dit 'n ontwerpgesprek eerder as 'n instel-oefening, want geen kliëntinstelling maak 'n skakelgebonde meganisme oor 'n roeteerder werkend nie.

Skryf neer watter ontwerp jy het

Teken geroteerd of oorbrug voor die voorval aan, want die twee ontplooiings antwoord hierdie vrae anders en 'n diensdoenbeampte behoort dit nie uit 'n profiel te moet aflei nie.

Om die boodskapstel een keer te lees verwyder die versoeking om 'n skakelomvang-eienskap as 'n VPN-fout te verduidelik, wat die duurste verkeerde diagnose op hierdie gebied is.