IPv6-trafik förbi VPN: hitta rutten som läcker

Två testsidor är oense: den ena rapporterar leverantörens adress genom tunneln, den andra rapporterar ditt hemprefix, och den uppenbara slutsatsen är att VPN läcker. Den slutsatsen hoppar över ett steg, eftersom de två rapporterna utlöste två olika routingbeslut och bara ett av dem skulle in i tunneln. Gapet är oftast verkligt, och det är ett täckningsproblem och inte en trasig tunnel. Tre frågor avgör det: vilket flöde som faktiskt gick ut, vilken rutt kärnan valde för det, och vilket beteende klienten avsåg.

Arbeta i den ordningen. Att svara i fel ordning ger en lång diskussion om huruvida klienten är felaktig, när det riktiga svaret är att ingen IPv6-rutt någonsin installerades.

Vilket flöde som faktiskt gick ut, och på vilket nätverkskort

Börja med ett test som namnger familjen det använde, och skriv sedan ned programmet, åtkomstnätet, profilen som gäller och om anslutningen överhuvudtaget erbjuder IPv6. De fyra fakta är det som gör två körningar jämförbara, och den fjärde glömmer folk: ett nätverk utan v6-prefix kan inte läcka v6, och ett nätverk som lägger till ett senare ändrar svaret.

Skicka en förfrågan per familj i stället för att läsa in en sida och läsa dess resultat. En enda sida kan blanda v6- och v4-resurser, en bakgrundsprocess kan bete sig annorlunda än fliken framför dig, och ett cachelagrat svar kan överleva den nätverksändring du försöker testa. Lås det mål du testar och anteckna det, så att en upprepad körning mäter samma sak.

Att läsa rutten som kärnan valde

Routtabellen svarar på frågan som webbläsaren inte kan. Fråga systemet vart ett visst mål skulle gå, och ta med både policyregler och den synliga standardrutten, eftersom båda kan åsidosätta den:

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

Ett mer specifikt prefix är det vanliga skälet till att ett mål ligger utanför tunneln medan allt annat stannar innanför, och en policyregel kan göra samma sak med högre prioritet än någon rutt. Läs också metriken, eftersom två poster för samma prefix avgörs av metriken och inte av deras ordning på skärmen. I Windows är den motsvarande listan Get-NetRoute -AddressFamily IPv6, sorterad efter metrik för att matcha beslutsordningen. En regel som ser korrekt ut i tabellen kan ändå förlora mot en policyregel med lägre nummer, och därför hör regellistan till samma andetag som rutlistan.

Varifrån klientens IPv6-policy kommer

En klient kan vara byggd för att föra v6 genom tunneln, för att avvisa det eller för att tillåta ett namngivet undantag, och de tre avsikterna ger tre olika korrekta resultat. Läs profilen och klientens egen dokumentation innan du kallar en observation en läcka, för en klient som blockerar v6 medan operativsystemet fortfarande skickar grannupptäckt på den fysiska länken beter sig som designat.

Ett program som medvetet undantagits från tunneln är ett annat fall än en familj som tunneln aldrig bar. Det första är ett beslut om ett program, det andra är ett hål i täckningen, och reparationen skiljer sig därefter. Läs klientens lista över undantagna program innan du letar efter en rutt som aldrig borde ha funnits.

Smal observation, när tabellen säger emot

När ruttuppslagningen är tvetydig kan en enda gränssnittsobservation på värden avgöra det, men bara om den är riktad mot frågan. Trafik till själva VPN-slutpunkten kommer att korsa det fysiska nätverkskortet enligt design; det som spelar roll är om programflödet, adresserat helt någon annanstans, också dyker upp där. Filtrera fångsten till målet du testar i stället för att samla allt.

En bred fångst blottar långt mer personlig trafik än den enda frågan kräver. Den svarar också mindre tydligt, eftersom flödet du bryr dig om anländer begravt i en ström av orelaterade anslutningar. Filtrera till det testade målet, stanna efter en handfull paket och radera fångsten.

Tre sätt att stänga gapet

För familjen genom tunneln, blockera den i klienten när tunneln inte kan bära den, eller registrera ett medvetet undantag med ägare och granskningsdatum. Varje är försvarbart, och det enda som inte är försvarbart är att lämna valet implicit, eftersom ett implicit val är precis vad läckan är. Om tunneln inte har någon v6-utgång alls är det både ärligt och testbart att avvisa v6 i klienten. Det som spelar roll är att valet står skrivet där nästa person hittar det, inte härlett ur beteende sex månader senare.

Upprepa kontrollen efter en återanslutning och efter att ha flyttat mellan nätverk, eftersom en rutt installerad för föregående länk kan överleva ändringen. Anteckna sedan målet, den valda rutten, klientpolicyn och familjen testet använde, så att nästa person läser ett beslut i stället för att härleda det igen. RFC 7359 dokumenterar dual-stack-läckage som ett designproblem och inte en bugg, och det är referensen att citera när någon hävdar att en fungerande v4-tunnel täcker allt.