Wêrom IPv6-buorûntdekking mislearret oer in rûtearre VPN

IPv6-buorûntdekking heart by in keppeling, en in rûtearre tunnel is de grins tusken twa keppelings. Dy iene sin ferklearret hast elk rapport oer in ôfstân-host dy't op syn adres antwurdet en troch neat oars te finen is. Kontrolearje it berik fan it adres dat jo testje foardat jo de tunnel kontrolearje. In keppeling-lokaal adres hat allinnich betsjutting op syn eigen keppeling, en in multicast-groep fan 'e oanfrege knooppunt is itselde beheind. Gjin fan beide giet oer in rûter, en dêrom kin in ping nei in globale adres slagje wylst ûntdekking foar deselde host net slagget.

Berik komt foar konfiguraasje

Buorfregete en buoraankundiging drage in hoplimyt fan 255 en wurde neffens it ûntwerp net trochstjoerd. De rûter tusken jo tunnel en it ôfstân-LAN stjoert IPv6-pakketten troch en stjoert buorberjochten net yn syn namme troch. Sa befettet de buorkaasje op 'e tunnelinterface de partner en net folle oars, wat korrekt gedrach is en gjin defekt om te reparearjen.

In keppeling-lokaal adres lykas in fe80::-ynfier is ek sônebeheind, en deselde tekst kin op in oare keppeling in oare host oantsjutte. Ien testen fan 'e oare kant fan 'e tunnel bewiist neat oars as dat it adres dûbelsinnich is.

De fal is de oanname dat it foarheaksel op 'e keppeling is

In host dy't tinkt dat in foarheaksel op 'e keppeling is, stjoert in buorfregete ynstee fan it pakket oan syn rûter te jaan, en dat omfettet in /64 dat nei in ôfstân lokaasje rûtearre is. As sa'n foarheaksel as op-de-keppeling oankomt, freget de host de lokale keppeling om in host dy't earne oars wennet, en neat antwurdet. Rûtearje wat lytsers nei de ôfstân-host, of einigje it foarheaksel by de rûter dy't derfoar antwurdzje sil.

In /128 foar ien tsjinst is de minst ferrassende regeling, en it ferwideret de dûbelsinnigens folslein. De spesifikaasje foar buorûntdekking beskriuwt de berjochtset en de op-de-keppeling-flagge dy't dit beslút.

Brêgjen feroaret de regels mei opsetsin

As de tunnel Ethernet-ramen ferfiert, wurde it ôfstân- en it lokale segmint ien keppeling, multicast berikt beide kanten, en buorûntdekking gedraacht him as op in switch. De gefolgen komme derby: broadcast- en multicast-oerstreaming, deteksje fan dûbele adressen oer de brêge, en rûteraankundigings dy't lekje yn in segmint dat se net sjen moatte. It flaterdomein omfettet no ek twa lokaasjes. Neat dêrfan is in argumint tsjin brêgjen, en elk punt is in reden om mei opsetsin te brêgjen ynstee fan by gefal.

In profyl fan TUN nei TAP feroarje om ûntdekking ferskine te litten is de ferkearde folchoarder fan operaasjes. De tsjinner, de klant en it adresplan moatte it iens wêze, en mobile klanten biede hielendal gjin TAP-interface oan, dus sa'n ûntwerp wurket op in laptop en mislearret op in tillefoan. Buorproksys en buorreleezjes binne aparte meganismen mei eigen easken, en se hearre by de dokumintearre regeling fan 'e netwurkbehearder en net by de ynstellingen fan in app.

Test mei it adres dat de applikaasje brûkt

Befêstigje de rûte mei ip -6 route get, besjoch de buorynfier mei ip -6 neigh, en befêstigje dan de tsjinst oer it rûtearre paad. DNS en it werompaad binne aparte kontrôles, en in sûne buorynfier bewiist gjin fan beide.

As de applikaasje oanstiet op in keppeling-lokaal of op ûntdekking basearre bestimming, is dat in ûntwerppetear en gjin ôfstimingsoefening, want gjin klantynstelling makket in oan 'e keppeling bûn meganisme wurkjend oer in rûter.

Skriuw op hokker ûntwerp jo hawwe

Registrearje foar it foarfal oft it rûtearre of brêge is, want de twa útrullingen beantwurdzje dizze fragen oars en in beretensyngenieur soe it net út in profyl ôfliede moatte.

It ien kear lêzen fan 'e berjochtset nimt de ferlieding wei om in eigenskip fan keppelingberik as in VPN-flater te ferklearjen, wat de djoerste ferkearde diagnoaze yn dit fjild is.