IPv6-verkeer langs de VPN: de lekkende route vinden

Twee testpagina’s zijn het oneens: de ene meldt het adres van de provider via de tunnel, de tweede meldt jouw thuisprefix, en de voor de hand liggende conclusie is dat de VPN lekt. Die conclusie slaat een stap over, want de twee rapporten hebben twee verschillende routeringsbeslissingen uitgevoerd en slechts één daarvan had de tunnel in moeten gaan. Het gat is meestal echt, en het is een dekkingsprobleem en geen kapotte tunnel. Drie vragen beslissen het: welke stroom is er werkelijk uit gegaan, welke route koos de kernel daarvoor, en welk gedrag bedoelde de client.

Werk in die volgorde. Ze in de verkeerde volgorde beantwoorden levert een lange discussie op over de vraag of de client defect is, terwijl het echte antwoord is dat er nooit een IPv6-route is geïnstalleerd.

Welke stroom is er werkelijk uit gegaan, en op welke adapter

Begin met een test die de gebruikte familie benoemt, en noteer dan de toepassing, het toegangsnetwerk, het geldende profiel en of de verbinding überhaupt IPv6 biedt. Die vier feiten maken twee runs vergelijkbaar, en de vierde vergeten mensen: een netwerk zonder v6-prefix kan geen v6 lekken, en een netwerk dat er later een toevoegt verandert het antwoord.

Stuur één verzoek per familie in plaats van een pagina te laden en het resultaat te lezen. Eén pagina kan v6- en v4-resources mengen, een achtergrondproces kan zich anders gedragen dan het tabblad voor je, en een gecachet antwoord kan de netwerkwijziging overleven die je probeert te testen. Leg de bestemming die je test vast en noteer die, zodat een herhaalde run hetzelfde meet.

De route lezen die de kernel koos

De routetabel beantwoordt de vraag die de browser niet kan. Vraag het systeem waar een specifieke bestemming heen gaat, en neem zowel beleidsregels als de zichtbare standaardroute mee, want beide kunnen die overschrijven:

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

Een specifieker prefix is de gebruikelijke reden dat één bestemming buiten de tunnel blijft terwijl al het andere binnen blijft, en een beleidsregel kan hetzelfde doen met een hogere prioriteit dan welke route dan ook. Lees ook de metriek, want twee vermeldingen voor hetzelfde prefix worden beslist door de metriek en niet door hun volgorde op het scherm. Op Windows is de gelijkwaardige lijst Get-NetRoute -AddressFamily IPv6, gesorteerd op metriek om bij de beslissingsvolgorde te passen. Een regel die er in de tabel juist uitziet, kan toch verliezen van een beleidsregel met een lager nummer, en daarom hoort de regellijst in dezelfde adem als de routelijst.

Waar het IPv6-beleid van de client vandaan komt

Een client kan gebouwd zijn om v6 door de tunnel te voeren, om het te weigeren of om een benoemde uitzondering toe te staan, en die drie bedoelingen geven drie verschillende juiste resultaten. Lees het profiel en de documentatie van de client zelf voordat je een waarneming een lek noemt, want een client die v6 blokkeert terwijl het besturingssysteem nog steeds buurontdekking over de fysieke link stuurt, gedraagt zich zoals ontworpen.

Een toepassing die bewust van de tunnel is uitgesloten, is een ander geval dan een familie die de tunnel nooit heeft gedragen. Het eerste is een beslissing over één programma, het tweede is een gat in de dekking, en de reparatie verschilt daarmee. Lees de lijst met uitgesloten programma’s van de client voordat je zoekt naar een route die er nooit had moeten zijn.

Smalle waarneming, wanneer de tabel tegenstribbelt

Wanneer de routeopzoeking dubbelzinnig is, kan één interfacewaarneming op de host het beslechten, maar alleen als die op de vraag is gericht. Verkeer naar het VPN-eindpunt zelf gaat per ontwerp over de fysieke adapter; wat telt is of de toepassingsstroom, die heel ergens anders is geadresseerd, daar ook verschijnt. Filter de opname op de bestemming die je test in plaats van alles te verzamelen.

Een brede opname legt veel meer persoonlijk verkeer bloot dan de ene vraag vereist. Ze antwoordt ook minder duidelijk, want de stroom die je aangaat komt begraven binnen in een stroom van niet-verwante verbindingen. Filter op de geteste bestemming, stop na een handvol pakketten en verwijder de opname.

Drie manieren om het gat te dichten

Voer de familie door de tunnel, blokkeer haar in de client wanneer de tunnel haar niet kan dragen, of leg een bewuste uitzondering vast met een eigenaar en een herzieningsdatum. Elk is verdedigbaar, en het enige dat niet verdedigbaar is, is de keuze impliciet laten, want een impliciete keuze is precies wat het lek is. Als de tunnel helemaal geen v6-uitgang heeft, is v6 weigeren in de client zowel eerlijk als testbaar. Wat telt is dat de keuze staat opgeschreven waar de volgende persoon haar vindt, niet zes maanden later uit gedrag afgeleid.

Herhaal de controle na opnieuw verbinden en na het wisselen tussen netwerken, want een route die voor de vorige link is geïnstalleerd kan de wijziging overleven. Noteer daarna de bestemming, de gekozen route, het clientbeleid en de familie die de test gebruikte, zodat de volgende persoon een beslissing leest in plaats van haar opnieuw af te leiden. RFC 7359 documenteert dual-stack-lekkage als een ontwerpprobleem en niet als een bug, en het is de referentie om aan te halen wanneer iemand beweert dat een werkende v4-tunnel alles dekt.