IPv6-trafikk utenom VPN-en: finn ruten som lekker

To testsider er uenige: den ene rapporterer leverandørens adresse gjennom tunnelen, den andre rapporterer hjemmeprefikset ditt, og den åpenbare konklusjonen er at VPN-en lekker. Den konklusjonen hopper over et trinn, fordi de to rapportene utløste to forskjellige rutingbeslutninger, og bare én av dem skulle inn i tunnelen. Gapet er vanligvis reelt, og det er et dekningsproblem og ikke en ødelagt tunnel. Tre spørsmål avgjør det: hvilken flyt som faktisk gikk ut, hvilken rute kjernen valgte for den, og hvilken atferd klienten hadde tenkt.

Arbeid i den rekkefølgen. Svarer man i feil rekkefølge, blir det en lang diskusjon om klienten er defekt, mens det riktige svaret er at det aldri ble installert noen IPv6-rute.

Hvilken flyt som faktisk gikk ut, og på hvilket nettverkskort

Begynn med en test som navngir familien den brukte, og skriv deretter ned applikasjonen, aksessnettet, profilen som gjelder og om forbindelsen i det hele tatt tilbyr IPv6. De fire fakta er det som gjør to kjøringer sammenlignbare, og den fjerde glemmer folk: et nettverk uten v6-prefiks kan ikke lekke v6, og et nettverk som legger til ett senere, endrer svaret.

Send én forespørsel per familie i stedet for å laste en side og lese resultatet. En enkelt side kan blande v6- og v4-ressurser, en bakgrunnsprosess kan oppføre seg annerledes enn fanen foran deg, og et hurtiglagret svar kan overleve nettverksendringen du prøver å teste. Fest målet du tester og noter det, slik at en gjentatt kjøring måler det samme.

Å lese ruten kjernen valgte

Rutetabellen svarer på spørsmålet nettleseren ikke kan. Spør systemet hvor en bestemt destinasjon vil gå, og ta med både policyregler og standardruten du ser, fordi begge kan overstyre den:

ip -6 route get 2606:4700:4700::1111
ip -6 rule show
ip -6 route show table all

Et mer spesifikt prefiks er den vanlige grunnen til at én destinasjon ligger utenfor tunnelen mens alt annet blir inne, og en policyregel kan gjøre det samme med høyere prioritet enn noen rute. Les også metrikken, fordi to oppføringer for samme prefiks avgjøres av metrikken og ikke av rekkefølgen på skjermen. På Windows er den tilsvarende listen Get-NetRoute -AddressFamily IPv6, sortert etter metrikk for å matche beslutningsrekkefølgen. En regel som ser riktig ut i tabellen, kan likevel tape for en policyregel med lavere nummer, og derfor hører regellisten sammen med rutelisten i samme åndedrag.

Hvor klientens IPv6-policy kommer fra

En klient kan være bygget for å føre v6 gjennom tunnelen, for å avvise det, eller for å tillate et navngitt unntak, og de tre intensjonene gir tre forskjellige riktige resultater. Les profilen og klientens egen dokumentasjon før du kaller en observasjon en lekkasje, for en klient som blokkerer v6 mens operativsystemet fortsatt sender naboøking på den fysiske lenken, oppfører seg som designet.

En applikasjon som bevisst er utelukket fra tunnelen, er et annet tilfelle enn en familie tunnelen aldri bar. Det første er en beslutning om ett program, det andre er et hull i dekningen, og reparasjonen er tilsvarende forskjellig. Les klientens liste over utelukkede programmer før du leter etter en rute som aldri skulle finnes.

Smal observasjon, når tabellen er uenig

Når ruteoppslaget er tvetydig, kan én grensesnittobservasjon på verten avgjøre det, men bare hvis den er rettet mot spørsmålet. Trafikk til selve VPN-endepunktet vil krysse det fysiske nettverkskortet etter design; det som betyr noe, er om applikasjonsflyten, som er adressert helt andre steder, også dukker opp der. Filtrer opptaket til destinasjonen du tester i stedet for å samle alt.

Et bredt opptak avdekker langt mer personlig trafikk enn det ene spørsmålet krever. Det svarer også mindre klart, fordi flyten du bryr deg om, kommer begravd i en strøm av urelaterte forbindelser. Filtrer til den testede destinasjonen, stopp etter en håndfull pakker, og slett opptaket.

Tre måter å lukke gapet

Før familien gjennom tunnelen, blokker den i klienten når tunnelen ikke kan bære den, eller registrer et bevisst unntak med eier og revisjonsdato. Hver av dem er forsvarlig, og det eneste som ikke er forsvarlig, er å la valget være implisitt, fordi et implisitt valg er nettopp det lekkasjen er. Hvis tunnelen ikke har noen v6-utgang i det hele tatt, er det både ærlig og testbart å avvise v6 i klienten. Det som betyr noe, er at valget står skrevet der neste person finner det, ikke utledet av atferd seks måneder senere.

Gjenta kontrollen etter en ny tilkobling og etter å ha flyttet mellom nettverk, siden en rute installert for forrige lenke kan overleve endringen. Noter deretter destinasjonen, ruten som ble valgt, klientpolicyen og familien testen brukte, slik at neste person leser en beslutning i stedet for å utlede den på nytt. RFC 7359 dokumenterer dual-stack-lekkasje som et designproblem og ikke en feil, og det er referansen å sitere når noen hevder at en fungerende v4-tunnel dekker alt.