Kvifor IPv6-nabooppdaging mislukkast over ein ruta VPN

IPv6-nabooppdaging høyrer til ei lenkje, og ein ruta tunnel er ei grense mellom to lenkjer. Den eine setninga forklarer nesten kvar rapport om ein ekstern vert som svarar på adressa og ikkje kan finnast på annan måte. Sjekk omfanget av adressa du testar før du sjekkar tunnelen. Ei lenkjelokal adresse er berre meiningsfull på si eiga lenkje, og ei multicast-gruppe for den førespurde knuten er avgrensa på same måte. Ingen av dei kryssar ein ruttar, og difor kan ein ping til ei global adresse lukkast medan oppdaging for same verten ikkje gjer det.

Omfang kjem før konfigurasjon

Naboønske og nabokunngjering har ei hoppgrens på 255 og vert ikkje vidaresende, etter design. Ruttaren mellom tunnelen din og det eksterne LAN-et vidaresender IPv6-pakkar og vidaresender ikkje nabomeldingar på hans vegner. Dermed inneheld nabobufferen på tunnelgrensesnittet motparten og lite anna, noko som er korrekt åtferd og ikkje ein feil som skal rettast.

Ei lenkjelokal adresse som ei fe80::-oppføring er òg soneavgrensa, og same tekst kan nemne ein annan vert på ei anna lenkje. Å teste ei frå den andre sida av tunnelen beviser ingenting anna enn at adressa er tvitydig.

Fella er føresetnaden om at prefikset er på lenkja

Ein vert som trur at eit prefiks er på lenkja, sender eit naboønske i staden for å overlate pakken til ruttaren sin, og det gjeld òg eit /64 som er ruta til ein ekstern stad. Når eit slikt prefiks kjem som på-lenkje, spør verten den lokale lenkja om ein vert som bur ein annan stad, og ingenting svarar. Rut noko mindre til den eksterne verten, eller avslutt prefikset ved ruttaren som vil svare for det.

Eit /128 for ein einaste teneste er den minst overraskande ordninga, og ho fjernar tvitydigheita heilt. Spesifikasjonen for nabooppdaging skildrar meldingssettet og på-lenkje-flagg som avgjer dette.

Bruing endrar reglane med vilje

Når tunnelen ber Ethernet-rammer, vert det eksterne og det lokale segmentet éi lenkje, multicast når begge sider, og nabooppdaging oppfører seg som på ein svitsj. Konsekvensane følgjer med: broadcast- og multicast-oversvømmelse, oppdaging av dupliserte adresser over brua og ruttarannonseringar som lek inn i eit segment som ikkje burde sjå dei. Feildomenet spenner no òg over to stader. Ingenting av dette talar mot bruing, og kvart punkt er ein grunn til å bru bevisst i staden for tilfeldig.

Å byte ein profil frå TUN til TAP for å få oppdaging til å visast er feil rekkjefølgje av operasjonar. Tenaren, klienten og adresseplanen må vere samde, og mobile klientar tilbyd ikkje eit TAP-grensesnitt i det heile, så eit slikt design fungerer på ein berbar PC og sviktar på ein telefon. Nabo-proxyar og -relé er separate mekanismar med eigne krav, og dei høyrer til den dokumenterte ordninga til nettverksadministratoren og ikkje til innstillingane i ein app.

Test med adressa applikasjonen brukar

Stadfest ruta med ip -6 route get, inspiser nabooppføringa med ip -6 neigh, og stadfest deretter tenesta over den ruta stien. DNS og returvegen er separate kontrollar, og ei sunn nabooppføring beviser ingen av dei.

Viss applikasjonen insisterer på ein lenkjelokal eller oppdagingsbasert destinasjon, er det ein designsamtale og ikkje ei tuneøving, fordi inga klientinnstilling får ein lenkjeavgrensa mekanisme til å verke gjennom ein ruttar.

Skriv ned kva design du har

Noter ruta eller brua før hendinga, sidan dei to utrullingane svarar på desse spørsmåla ulikt, og ein vaktande ingeniør bør ikkje måtte utleie det frå ein profil.

Å lese meldingssettet éin gong fjernar freistinga til å forklare ein lenkjeomfangseigenskap som ein VPN-feil, som er den dyraste feildiagnosen på dette området.