Kodėl IPv6 kaimynų aptikimas nepavyksta per maršrutizuotą VPN

IPv6 kaimynų aptikimas priklauso vienam saitui, o maršrutizuotas tunelis yra riba tarp dviejų saitų. Tas vienas sakinys paaiškina beveik kiekvieną pranešimą apie tolimą mazgą, kuris atsako pagal adresą ir jo neįmanoma rasti jokiu kitu būdu. Prieš tikrindami tunelį patikrinkite testuojamo adreso apimtį. Su saitu susietas adresas turi prasmę tik savo saite, o prašomo mazgo multicast grupė apribota taip pat. Nė vienas neperžengia maršrutizatoriaus, todėl ping į pasaulinį adresą gali pavykti, nors to paties mazgo aptikimas nepavyksta.

Apimtis eina prieš konfigūraciją

Kaimyno užklausa ir skelbimas turi 255 šuolių ribą ir pagal konstrukciją nepersiunčiami. Maršrutizatorius tarp jūsų tunelio ir tolimo LAN persiunčia IPv6 paketus ir nepersiunčia kaimyno pranešimų jo vardu. Taigi tunelio sąsajos kaimynų podėlyje yra partneris ir nedaug kito, o tai teisingas elgesys, o ne taisytinas defektas.

Su saitu susietas adresas, pavyzdžiui, fe80:: įrašas, taip pat ribojamas zonos, ir tas pats tekstas kitame saite gali reikšti kitą mazgą. Vieno jų tikrinimas iš kitos tunelio pusės nieko neįrodo, išskyrus tai, kad adresas dviprasmis.

Spąstai yra prielaida, kad prefiksas yra saite

Mazgas, manantis, kad prefiksas yra saite, siunčia kaimyno užklausą, o ne perduoda paketą savo maršrutizatoriui, ir tai apima /64, maršrutizuotą į tolimą vietą. Kai toks prefiksas atkeliauja kaip esantis saite, mazgas klausia vietinio saito apie mazgą, gyvenantį kitur, ir niekas neatsako. Maršrutizuokite ką nors mažesnio tolimam mazgui arba užbaikite prefiksą maršrutizatoriuje, kuris atsakys už jį.

/128 vienai paslaugai yra mažiausiai stebinantis sprendimas, ir jis visiškai pašalina dviprasmiškumą. Kaimynų aptikimo specifikacija aprašo pranešimų rinkinį ir saite-esančio vėliavėlę, kuri tai nusprendžia.

Tiltas sąmoningai keičia taisykles

Kai tunelis perduoda Ethernet kadrus, tolimas ir vietinis segmentai tampa vienu saitu, multicast pasiekia abi puses, o kaimynų aptikimas elgiasi kaip komutatoriuje. Pasekmės ateina kartu: transliacijos ir multicast užtvindymas, pasikartojančių adresų aptikimas per tiltą ir maršrutizatoriaus skelbimai, nutekantys į segmentą, kuris jų neturėtų matyti. Gedimų sritis dabar apima ir dvi vietas. Niekas iš to nėra argumentas prieš tiltą, ir kiekvienas punktas yra priežastis tiesti tiltą sąmoningai, o ne atsitiktinai.

Profilio keitimas iš TUN į TAP, kad atsirastų aptikimas, yra neteisinga veiksmų tvarka. Serveris, klientas ir adresų planas turi sutarti, o mobilieji klientai visiškai nesiūlo TAP sąsajos, todėl toks dizainas veikia nešiojamajame ir nepavyksta telefone. Kaimynų tarpinės ir retransliatoriai yra atskiri mechanizmai su savo reikalavimais, ir jie priklauso dokumentuotam tinklo administratoriaus susitarimui, o ne programos nustatymams.

Testuokite adresu, kurį naudoja programa

Patvirtinkite maršrutą su ip -6 route get, patikrinkite kaimyno įrašą su ip -6 neigh, tada patvirtinkite paslaugą maršrutizuotu keliu. DNS ir grįžimo kelias yra atskiri patikrinimai, o sveikas kaimyno įrašas neįrodo nė vieno.

Jei programa reikalauja su saitu susieto ar aptikimu pagrįsto tikslo, tai dizaino pokalbis, o ne derinimo pratimas, nes joks kliento nustatymas nepadaro saitu apriboto mechanizmo veikiančio per maršrutizatorių.

Užrašykite, kokį dizainą turite

Prieš incidentą užfiksuokite, ar tai maršrutizuota, ar su tiltu, nes du diegimai į šiuos klausimus atsako skirtingai, ir budintis inžinierius neturėtų to spėti iš profilio.

Vienkartinis pranešimų rinkinio perskaitymas pašalina pagundą paaiškinti saito apimties savybę kaip VPN klaidą, o tai brangiausia klaidinga diagnozė šioje srityje.