Dual-stack-VPN: de client kiest de adresfamilie, niet u

De tunnel staat, IPv4-sites laden en één hostnaam loopt in een time-out. De onmiddellijke conclusie is dat de VPN stuk is of dat de inloggegevens fout zijn, en meestal klopt geen van beide. De naam gaf zowel een IPv4- als een IPv6-adres terug, de toepassing koos er één, en slechts één van die kandidaten had een werkend pad. De client nam de selectiebeslissing; de tunnel dekte simpelweg niet wat hij selecteerde.

Kiezen is geen belofte van dekking

Standaardadresselectie, beschreven in RFC 6724, bepaalt welk paar van bron en bestemming een host verkiest wanneer er meerdere beschikbaar zijn. Happy Eyeballs voegt daar een verbindingsstrategie aan toe: het start pogingen op beide families en houdt degene die het eerst antwoordt, zodat een gebruiker niet wacht tot een kapotte familie een time-out krijgt.

Geen van beide mechanismen maakt een route. Als uw tunnel alleen IPv4 vervoert, is een AAAA-kandidaat nog steeds een legitieme bestemming die de client kan proberen, en de fout verschijnt als traag laden in plaats van als een fout, omdat de browser terugviel. De gebruiker meldt een trage site, geen kapotte, en het supportticket erft die vaagheid. Reproduceer het met een vaste familie en het rapport wordt specifiek.

Die terugval is de reden dat het symptoom tussen toepassingen inconsistent is. Een browser verbergt de vertraging; een opdrachtregelclient met een vaste familie toont u de echte fout meteen.

Zoek de familie die het verzoek werkelijk gebruikte

Begin bij de naam, niet bij de tunnel. Vraag beide recordtypen op en noteer wat er terugkwam:

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

Als het v4-verzoek slaagt en het v6-verzoek faalt, hebt u het probleem gereproduceerd in een vorm die u kunt debuggen. Als beide slagen vanuit de shell en de browser blijft falen, kijk dan naar de eigen resolver van de toepassing of een gecacht antwoord voordat u de tunnel aanraakt.

Houd de familie en de bestemming in uw notities. Een ticket dat zegt dat de site niet via de VPN laadt, kan niemand controleren, terwijl een ticket dat zegt dat AAAA faalt en A werkt, op een specifieke route wijst.

Controleer de route voor die familie

Vraag voor de falende familie aan de kernel welk pad hij zou gebruiken en vergelijk dat met de geconfigureerde adressen van de tunnel. Op Linux toont ip -6 route get voor de bestemming de interface en de bron die gekozen zouden worden.

Controleer daarna de tunnel zelf. WireGuard-peers dragen een lijst met toegestane IP's, en een vermelding voor 0.0.0.0/0 zegt niets over IPv6. Als de lijst van de peer geen IPv6-prefix heeft, heeft de client geen reden om AAAA-verkeer de tunnel in te sturen, en het pakket verlaat via wat de host anders zou doen.

Firewallregels en NAT-beleid verdienen dezelfde controle per familie. Een regel geschreven voor IPv4 dekt IPv6 op geen enkel platform, en dat is de meest voorkomende reden waarom de ene familie werkt en de andere niet.

Schakel IPv6 niet uit om de schermafbeelding simpel te houden

IPv6 systeembreed uitschakelen laat het symptoom verdwijnen en laat u zonder diagnose achter. Het breekt ook elke bestemming die alleen IPv6 is, en het verbergt dezelfde bug voor de volgende toepassing. Als een machine echt geen IPv6 zou moeten gebruiken, is dat bewust beleid met een eigenaar en een test. Het tijdens een incident uitschakelen is geen van beide.

Bepaal wat de client met de familie moet doen en configureer dat expliciet: draag hem door de tunnel, of blokkeer hem op een ondersteunde manier zodat de selectie nooit een onbereikbare kandidaat biedt. Beide zijn legitieme ontwerpen. Een wereldwijde uitschakeling is geen van beide, want dat is helemaal geen ontwerp.

Wat er in het ticket moet

Noteer vier dingen: de hostnaam, de familie die faalde, de route die de kernel koos, en het resultaat van een familiespecifiek verzoek. Die set is genoeg voor iemand anders om de fout te reproduceren zonder te raden welk van de twee paden u bedoelde.

De regels voor adresselectie van RFC 6724 leggen uit waarom de client de kandidaat verkoos die hij verkoos, en RFC 8305 legt het racegedrag uit dat de vertraging verborgen hield. Geen van beide zal een pakket voor u routeren, en dat is het deel dat de tunnel moet doen.