Een netwerk met alleen IPv6 breekt de VPN voordat de tunnel begint

De laptop maakt verbinding met een conferentie-Wi-Fi die alleen IPv6 uitdeelt, de VPN-client draait en faalt, en hetzelfde profiel werkte een uur eerder in een hotel. Aan de inloggegevens is niets veranderd. Wat is veranderd, is dat de client nu een IPv4-bestemming moet bereiken via een netwerk dat alleen IPv6 draagt, en niet elke client weet hoe dat moet.

Doorloop dezelfde vijf stappen die de pakketten doorlopen.

Stap 1: kijk naar de naamopzoeking

Als het profiel een hostnaam gebruikt, is de eerste vraag wat de resolver teruggeeft. dig AAAA vpn.example.com geeft op het netwerk met alleen IPv6 een echt AAAA-record, een uit DNS64 gesynthetiseerd record of helemaal niets. Een gesynthetiseerd antwoord codeert de IPv4-bestemming in een vertaalprefix, en pas dan kan een client zonder IPv6-bestemming die bereiken. Een profiel met een hardgecodeerd IPv4-adres komt nooit zo ver, want er is geen naam om te synthetiseren.

Dat ene verschil verklaart de meeste rapporten van werkt-daar-faalt-hier, en het kost één opdracht om het te zien.

Stap 2: zie welke familie de client heeft gebeld

Kijk naar de socket in plaats van de voortgangsbalk. Een client die een IPv4-socket naar een IPv4-adres opent op een link met alleen IPv6 heeft nergens om die naartoe te sturen, en de fout verschijnt als een time-out in plaats van een naamfout. ss -tanp terwijl de client verbindt, toont het externe adres en de familie die hij heeft geprobeerd. Vergelijk dat met ip -6 route om te bevestigen dat de standaard een echte volgende IPv6-hop is.

De adresfamilie in de sockettabel is het feit. De voortgangsbalk is een samenvatting die iemand anders heeft geschreven.

Stap 3: scheid de vertaling van de tunnel

NAT64 en DNS64 zijn hoe het toegangsnetwerk IPv4-bestemmingen bereikt, en ze doen niets voor de tunnel als die eenmaal staat. Een tunnel die over een vertaald pad is opgezet, onderhandelt nog steeds over zijn eigen interne adressering, en de interne IPv4- of IPv6-dekking is een aparte beleidsvraag. Als de client verbindt en dan niets bereikt, ben je voorbij de vertaling en in de routering, wat een ander onderzoek met ander bewijs is.

Een mislukte vertaling ziet eruit als nooit verbinden. Een mislukte interne dekking ziet eruit als verbinden en niets bereiken.

Stap 4: test hetzelfde profiel op een ander netwerk

Neem hetzelfde profiel, dezelfde clientversie en dezelfde inloggegevens mee naar een dual-stacknetwerk en herhaal. Als het daar werkt en faalt op het pad met alleen IPv6, is de variabele het toegangsnetwerk en niet het profiel. Noteer de clientversie en de netwerkconditie in de ticket, want de uiteindelijke oplossing is een clientupdate of een andere bestemming.

Een rapport dat zegt dat de VPN kapot is, is niet uitvoerbaar. Een rapport dat zegt dat het alleen faalt op toegang met alleen IPv6, is een bugrapport.

Stap 5: repareer het pad, niet de beveiligingsinstellingen

De verleidelijke reparaties maken alles erger. IPv6 uitschakelen verwijdert het enige pad dat het netwerk biedt. De client naar een openbare resolver wijzen breekt de DNS64-synthese, want die synthese moet van de resolver achter de vertaler komen. Certificaatverificatie uitschakelen geeft je een verbinding naar iets wat je niet kunt identificeren. Geen van die is een reparatie, en twee ervan zijn beveiligingsregressies die het incident zullen overleven.

De echte opties zijn een client die het netwerkvertaalmodel ondersteunt, of een bestemming met een bereikbaar IPv6-adres. Vraag om een van beide.