IPv6-trafik uden om VPN’et: find den lækkende rute

To testsider er uenige: den ene rapporterer udbyderens adresse gennem tunnelen, den anden rapporterer dit hjemmepræfiks, og den nærliggende konklusion er, at VPN’et lækker. Den konklusion springer et skridt over, fordi de to rapporter udløste to forskellige rutevalg, og kun det ene af dem skulle ind i tunnelen. Hullet er som regel virkeligt, og det er et dækningsproblem snarere end en brudt tunnel. Tre spørgsmål afgør det: hvilket flow der faktisk gik ud, hvilken rute kernen valgte til det, og hvilken adfærd klienten havde til hensigt.

Arbejd i den rækkefølge. Besvarer man dem i omvendt rækkefølge, får man en lang diskussion om, hvorvidt klienten er defekt, når det rigtige svar er, at der aldrig blev installeret nogen IPv6-rute.

Hvilket flow gik faktisk ud, og på hvilket netkort

Begynd med en test, der angiver, hvilken familie den brugte, og skriv derefter applikationen, adgangsnettet, den aktive profil og om forbindelsen overhovedet tilbyder IPv6. De fire fakta er det, der gør to kørsler sammenlignelige, og den fjerde er den, folk glemmer: et netværk uden v6-præfiks kan ikke lække v6, og et netværk, der senere får et, ændrer svaret.

Send én anmodning per familie i stedet for at indlæse en side og læse resultatet. En enkelt side kan blande v6- og v4-ressourcer, en baggrundsproces kan opføre sig anderledes end den fane, du ser på, og et cachet svar kan overleve det netværksskift, du prøver at teste. Fastlæg destinationen, du tester, og notér den, så en gentaget kørsel måler det samme.

Sådan læser du ruten, som kernen valgte

Rutetabellen besvarer det spørgsmål, browseren ikke kan. Spørg systemet, hvor en bestemt destination vil gå hen, og medtag policyregler såvel som standardruten, fordi begge kan tilsidesætte den:

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

Et mere specifikt præfiks er den sædvanlige grund til, at én destination ligger uden for tunnelen, mens alt andet bliver inde, og en policyregel kan gøre det samme med højere prioritet end nogen rute. Læs også metric, da to poster for det samme præfiks afgøres af metric og ikke af deres rækkefølge på skærmen. På Windows er den tilsvarende liste Get-NetRoute -AddressFamily IPv6, sorteret efter metric, så den matcher beslutningsrækkefølgen. En regel, der ser rigtig ud i tabellen, kan stadig tabe til en policyregel med lavere nummer, og derfor hører regellisten sammen med rutelisten.

Hvor klientens IPv6-politik kommer fra

En klient kan være bygget til at føre v6 gennem tunnelen, at afvise det eller at tillade en navngiven undtagelse, og de tre hensigter giver tre forskellige korrekte resultater. Læs profilen og klientens egen dokumentation, før du kalder en observation en lækage, for en klient, der blokerer v6, mens styresystemet stadig sender neighbour discovery på det fysiske link, opfører sig som designet.

En applikation, der bevidst er udelukket fra tunnelen, er en anden sag end en familie, som tunnelen aldrig har båret. Det første er en beslutning om ét program, det andet er et hul i dækningen, og udbedringen er tilsvarende forskellig. Læs klientens liste over udelukkede programmer, før du leder efter en rute, der aldrig var meningen skulle findes.

Smal observation, når tabellen er uenig

Når ruteopslaget er tvetydigt, kan én grænsefladeobservation på værten afgøre det, men kun hvis den er rettet mod spørgsmålet. Trafik til selve VPN-endepunktet vil gå over det fysiske netkort med vilje; det afgørende er, om applikationsflowet, som er adresseret helt andre steder hen, også dukker op der. Filtrér optagelsen til den destination, du tester, i stedet for at samle alt ind.

En bred optagelse blotlægger langt mere personlig trafik, end det ene spørgsmål kræver. Den besvarer også spørgsmålet mindre klart, fordi det flow, du er interesseret i, ankommer begravet i en strøm af urelaterede forbindelser. Filtrér til den testede destination, stop efter en håndfuld pakker, og slet optagelsen.

Tre måder at lukke hullet

Før familien gennem tunnelen, blokér den i klienten, når tunnelen ikke kan bære den, eller registrér en bevidst undtagelse med en ejer og en revisionsdato. Hver af dem kan forsvares, og det eneste, der ikke kan forsvares, er at lade valget være implicit, for et implicit valg er netop, hvad lækagen er. Hvis tunnelen slet ikke har nogen v6-udgang, er det både ærligt og testbart at afvise v6 i klienten. Det afgørende er, at valget er skrevet ned, hvor den næste kan finde det, ikke udledt af adfærd seks måneder senere.

Gentag kontrollen efter en genopkobling og efter at have skiftet netværk, for en rute, der blev installeret til det forrige link, kan overleve skiftet. Notér derefter destinationen, den valgte rute, klientpolitikken og den familie, testen brugte, så den næste læser en beslutning i stedet for at udlede den igen. RFC 7359 dokumenterer dual-stack-lækage som et designproblem snarere end en fejl, og det er referencen, man citerer, når nogen påstår, at en fungerende v4-tunnel dækker alt.