Hvorfor IPv6-nabo-opdagelse fejler over en routet VPN

IPv6-nabo-opdagelse hører til et link, og en routet tunnel er en grænse mellem to links. Den ene sætning forklarer næsten enhver rapport om en fjern vært, der svarer på adressen og ikke kan findes på anden vis. Kontrollér omfanget af den adresse, du tester, før du kontrollerer tunnelen. En link-lokal adresse giver kun mening på sit eget link, og en multicast-gruppe for den efterspurgte node er afgrænset på samme måde. Ingen af dem krydser en router, og derfor kan et ping til en global adresse lykkes, mens opdagelse for den samme vært ikke gør.

Omfang kommer før konfiguration

Naboanmodning og naboannoncering har en hopgrænse på 255 og videresendes ikke, efter design. Routeren mellem din tunnel og det fjerne LAN videresender IPv6-pakker og videresender ikke nabomeddelelser på dens vegne. Så nabocachen på tunnelinterfacet indeholder modparten og lidt andet, hvilket er korrekt adfærd og ikke en fejl, der skal rettes.

En link-lokal adresse som en fe80::-post er også zoneafgrænset, og den samme tekst kan navngive en anden vært på et andet link. At teste en fra den anden side af tunnelen beviser intet andet, end at adressen er tvetydig.

Fælden er antagelsen om, at præfikset er på linket

En vært, der tror, at et præfiks er på linket, sender en naboanmodning i stedet for at overlade pakken til sin router, og det gælder også et /64, der er routet til et fjernt sted. Når et sådant præfiks ankommer som på-link, spørger værten det lokale link om en vært, der bor andre steder, og intet svarer. Rout noget mindre til den fjerne vært, eller afslut præfikset ved den router, der vil svare for det.

Et /128 til en enkelt tjeneste er den mindst overraskende ordning, og den fjerner tvetydigheden helt. Specifikationen for nabo-opdagelse beskriver meddelelsessættet og på-link-flaget, der afgør dette.

Bridging ændrer reglerne med vilje

Når tunnelen bærer Ethernet-rammer, bliver det fjerne og det lokale segment ét link, multicast når begge sider, og nabo-opdagelse opfører sig som på en switch. Konsekvenserne følger med: broadcast- og multicast-oversvømmelse, detektering af dublerede adresser over broen og routerannonceringer, der lækker ind i et segment, som ikke burde se dem. Fejldomænet spænder nu også over to steder. Intet af det taler imod bridging, og hvert punkt er en grund til at bygge bro bevidst i stedet for tilfældigt.

At skifte en profil fra TUN til TAP for at få opdagelse til at fremstå er den forkerte rækkefølge. Serveren, klienten og adresseplanen skal alle være enige, og mobile klienter tilbyder slet ikke et TAP-interface, så et sådant design virker på en bærbar og fejler på en telefon. Nabo-proxyer og -relæer er separate mekanismer med egne krav, og de hører til netværksadministratorens dokumenterede ordning og ikke til en apps indstillinger.

Test med den adresse, applikationen bruger

Bekræft ruten med ip -6 route get, inspicér naboposten med ip -6 neigh, og bekræft derefter tjenesten over den routed sti. DNS og returvejen er separate kontroller, og en sund nabopost beviser ingen af dem.

Hvis applikationen insisterer på en link-lokal eller opdagelsesbaseret destination, er det en designsamtale og ikke en tuneøvelse, fordi ingen klientindstilling får en link-afgrænset mekanisme til at virke gennem en router.

Skriv ned, hvilket design du har

Notér routet eller bridged før hændelsen, da de to udrulninger besvarer disse spørgsmål forskelligt, og en vagthavende ingeniør ikke bør udlede det af en profil.

At læse meddelelsessættet én gang fjerner fristelsen til at forklare en link-omfangs-egenskab som en VPN-fejl, hvilket er den dyreste fejldiagnose på området.