Hvorfor IPv6-nabooppdagelse mislykkes over en rutet VPN

IPv6-nabooppdagelse hører til en lenke, og en rutet tunnel er en grense mellom to lenker. Den ene setningen forklarer nesten enhver rapport om en ekstern vert som svarer på adressen og ikke kan finnes på annen måte. Sjekk omfanget av adressen du tester før du sjekker tunnelen. En lenkelokal adresse er bare meningsfull på sin egen lenke, og en multicast-gruppe for den forespurte noden er avgrenset på samme måte. Ingen av dem krysser en ruter, og derfor kan en ping til en global adresse lykkes mens oppdagelse for samme vert ikke gjør det.

Omfang kommer før konfigurasjon

Naboanmodning og naboannonsering har en hoppgrense på 255 og videresendes ikke, etter design. Ruteren mellom tunnelen din og det eksterne LAN-et videresender IPv6-pakker og videresender ikke nabomeldinger på dens vegne. Dermed inneholder nabobufferen på tunnelgrensesnittet motparten og lite annet, noe som er korrekt oppførsel og ikke en feil som skal rettes.

En lenkelokal adresse som en fe80::-oppføring er også sonebegrenset, og samme tekst kan navngi en annen vert på en annen lenke. Å teste en fra den andre siden av tunnelen beviser ingenting annet enn at adressen er tvetydig.

Fellen er antakelsen om at prefikset er på lenken

En vert som tror at et prefiks er på lenken, sender en naboanmodning i stedet for å overlate pakken til ruteren sin, og det gjelder også et /64 som er rutet til et eksternt sted. Når et slikt prefiks ankommer som på-lenke, spør verten den lokale lenken om en vert som bor et annet sted, og ingenting svarer. Rut noe mindre til den eksterne verten, eller avslutt prefikset ved ruteren som vil svare for det.

Et /128 for en enkelt tjeneste er den minst overraskende ordningen, og den fjerner tvetydigheten helt. Spesifikasjonen for nabooppdagelse beskriver meldingssettet og på-lenke-flagget som avgjør dette.

Broing endrer reglene med vilje

Når tunnelen bærer Ethernet-rammer, blir det eksterne og det lokale segmentet én lenke, multicast når begge sider, og nabooppdagelse oppfører seg som på en svitsj. Konsekvensene følger med: broadcast- og multicast-oversvømmelse, deteksjon av dupliserte adresser over broen og ruterannonseringer som lekker inn i et segment som ikke burde se dem. Feildomenet spenner nå også over to steder. Ingenting av dette taler mot broing, og hvert punkt er en grunn til å bro bevisst i stedet for tilfeldig.

Å bytte en profil fra TUN til TAP for å få oppdagelse til å vises er feil rekkefølge av operasjoner. Serveren, klienten og adresseplanen må være enige, og mobile klienter tilbyr ikke et TAP-grensesnitt i det hele tatt, så et slikt design fungerer på en bærbar PC og feiler på en telefon. Nabo-proxyer og -reléer er separate mekanismer med egne krav, og de hører til nettverksadministratorens dokumenterte ordning og ikke til innstillingene i en app.

Test med adressen applikasjonen bruker

Bekreft ruten med ip -6 route get, inspiser nabooppføringen med ip -6 neigh, og bekreft deretter tjenesten over den rutede stien. DNS og returveien er separate kontroller, og en sunn nabooppføring beviser ingen av dem.

Hvis applikasjonen insisterer på en lenkelokal eller oppdagelsesbasert destinasjon, er det en designsamtale og ikke en tuneøvelse, fordi ingen klientinnstilling får en lenkebegrenset mekanisme til å virke gjennom en ruter.

Skriv ned hvilket design du har

Noter rutet eller broet før hendelsen, siden de to utrullingene svarer på disse spørsmålene ulikt, og en vaktende ingeniør bør ikke måtte utlede det fra en profil.

Å lese meldingssettet én gang fjerner fristelsen til å forklare en lenkeomfangsegenskap som en VPN-feil, som er den dyreste feildiagnosen på dette området.