Dobbelt-stak VPN: klienten vælger adressefamilien, ikke dig

Tunnelen er oppe, IPv4-websteder indlæses, og ét værtsnavn timer ud. Den umiddelbare konklusion er, at VPN'en er i stykker, eller at legitimationsoplysningerne er forkerte, og ingen af delene er normalt sande. Navnet returnerede både en IPv4- og en IPv6-adresse, programmet valgte én, og kun én af disse kandidater havde en fungerende vej. Klienten traf en valgbeslutning; tunnelen dækkede simpelthen ikke det, den valgte.

Valg er ikke et løfte om dækning

Standardadressevalget, beskrevet i RFC 6724, afgør, hvilket kilde- og destinationspar en vært foretrækker, når flere er tilgængelige. Happy Eyeballs lægger en forbindelsesstrategi ovenpå: den starter forsøg på begge familier og beholder den, der svarer først, så en bruger ikke venter på, at en brudt familie timer ud.

Ingen af mekanismerne opretter en rute. Hvis din tunnel kun bærer IPv4, er en AAAA-kandidat stadig en legitim destination, som klienten kan forsøge, og fejlen viser sig som en langsom indlæsning i stedet for en fejl, fordi browseren faldt tilbage. Brugeren rapporterer et langsomt websted, ikke et brudt, og supportbilletten arver den uklarhed. Genskab det med en fast familie, og rapporten bliver konkret.

Det fallback er grunden til, at symptomet er inkonsistent på tværs af programmer. En browser skjuler forsinkelsen; en kommandolinjeklient med en fast familie viser dig den rigtige fejl med det samme.

Find den familie, anmodningen faktisk brugte

Begynd med navnet, ikke tunnelen. Forespørg på begge posttyper, og noter, hvad der kom tilbage:

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

Hvis v4-anmodningen lykkes, og v6-anmodningen fejler, har du genskabt problemet i en form, du kan fejlfinde. Hvis begge lykkes fra shellen, og browseren stadig fejler, så se på programmets egen resolver eller et cachet svar, før du rører tunnelen.

Hold familien og destinationen i dine noter. En billet, der siger, at webstedet ikke indlæses over VPN'en, kan ingen kontrollere, mens en billet, der siger, at AAAA fejler, og A virker, peger på en bestemt rute.

Kontroller ruten for den familie

For den fejlende familie skal du spørge kernen, hvilken vej den ville bruge, og sammenligne den med tunnelens konfigurerede adresser. På Linux viser ip -6 route get for destinationen det interface og den kilde, der ville blive valgt.

Kontroller derefter selve tunnelen. WireGuard-peers bærer en liste over tilladte IP'er, og en post for 0.0.0.0/0 siger intet om IPv6. Hvis peerens liste ikke har noget IPv6-præfiks, har klienten ingen grund til at sende AAAA-trafik ind i tunnelen, og pakken forlader via det, værten ellers ville gøre.

Firewallregler og NAT-politik fortjener samme kontrol pr. familie. En regel skrevet til IPv4 dækker ikke IPv6 på nogen platform, og det er den enkelt mest almindelige grund til, at én familie virker, mens den anden ikke gør.

Deaktiver ikke IPv6 for at gøre skærmbilledet enkelt

Hvis du slår IPv6 fra systembredt, forsvinder symptomet, og du står uden en diagnose. Det ødelægger også enhver destination, der kun er IPv6, og det skjuler den samme fejl for det næste program. Hvis en maskine virkelig ikke bør bruge IPv6, er det en bevidst politik med en ejer og en test. At slå det fra under en hændelse er ingen af delene.

Beslut, hvad klienten skal gøre med familien, og konfigurer det eksplicit: bær den gennem tunnelen, eller blokér den på en understøttet måde, så valget aldrig tilbyder en uopnåelig kandidat. Begge er legitime design. En global deaktivering er ingen af dem, fordi det slet ikke er et design.

Hvad skal der stå i billetten

Noter fire ting: værtsnavnet, den familie, der fejlede, den rute kernen valgte, og resultatet af en familiespecifik anmodning. Det sæt er nok til, at en anden kan genskabe fejlen uden at gætte, hvilken af de to veje du mente.

RFC 6724's regler for adressevalg forklarer, hvorfor klienten foretrak den kandidat, den gjorde, og RFC 8305 forklarer den kapløbsadfærd, der skjulte forsinkelsen. Ingen af dem vil route en pakke for dig, og det er den del, tunnelen skal klare.