Dobbeltstakk-VPN: klienten velger adressefamilien, ikke du
Ett navn, to familier, to ulike veier. Tunnelen kan være sunn og forespørselen likevel feile, fordi klienten valgte en kandidat du aldri rutet.
Tunnelen er oppe, IPv4-nettsteder lastes, og ett vertsnavn timer ut. Den umiddelbare konklusjonen er at VPN-en er ødelagt eller at påloggingsinformasjonen er feil, og ingen av delene stemmer vanligvis. Navnet returnerte både en IPv4- og en IPv6-adresse, applikasjonen valgte én, og bare én av disse kandidatene hadde en fungerende vei. Klienten tok valgbeslutningen; tunnelen dekket rett og slett ikke det den valgte.
Valg er ikke et løfte om dekning
Standard adressevalg, beskrevet i RFC 6724, avgjør hvilket kilde- og målpar en vert foretrekker når flere er tilgjengelige. Happy Eyeballs legger en tilkoblingsstrategi på toppen: den starter forsøk i begge familier og beholder den som svarer først, slik at en bruker ikke venter på at en ødelagt familie skal time ut.
Ingen av mekanismene oppretter en rute. Hvis tunnelen din bare fører IPv4, er en AAAA-kandidat fortsatt en legitim destinasjon som klienten kan prøve, og feilen vises som langsom lasting i stedet for en feil, fordi nettleseren falt tilbake. Brukeren rapporterer et langsomt nettsted, ikke et ødelagt, og støttebilletter arver den uklarheten. Reproduser det med en fast familie, og rapporten blir konkret.
Det tilbakefallet er grunnen til at symptomet er inkonsekvent på tvers av applikasjoner. En nettleser skjuler forsinkelsen; en kommandolinjeklient med en fast familie viser deg den virkelige feilen umiddelbart.
Finn familien forespørselen faktisk brukte
Begynn med navnet, ikke tunnelen. Spør på begge posttypene og noter hva som kom tilbake:
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.comHvis v4-forespørselen lykkes og v6-forespørselen feiler, har du reprodusert problemet i en form du kan feilsøke. Hvis begge lykkes fra skallet og nettleseren fortsatt feiler, se på applikasjonens egen resolver eller et bufret svar før du rører tunnelen.
Hold familien og destinasjonen i notatene dine. En billett som sier at nettstedet ikke lastes over VPN-en, kan ingen kontrollere, mens en billett som sier at AAAA feiler og A virker, peker på en bestemt rute.
Kontroller ruten for den familien
For familien som feiler, spør kjernen hvilken vei den ville bruke, og sammenlign den med tunnelens konfigurerte adresser. På Linux viser ip -6 route get for destinasjonen grensesnittet og kilden som ville blitt valgt.
Kontroller deretter selve tunnelen. WireGuard-peere fører en liste over tillatte IP-er, og en oppføring for 0.0.0.0/0 sier ingenting om IPv6. Hvis peerens liste ikke har noe IPv6-prefiks, har klienten ingen grunn til å sende AAAA-trafikk inn i tunnelen, og pakken forlater via det verten ellers ville gjort.
Brannmurregler og NAT-policy fortjener samme kontroll per familie. En regel skrevet for IPv4 dekker ikke IPv6 på noen plattform, og det er den vanligste grunnen til at én familie virker mens den andre ikke gjør det.
Ikke deaktiver IPv6 for å gjøre skjermbildet enkelt
Å slå av IPv6 systemvidt vil få symptomet til å forsvinne og la deg stå uten diagnose. Det ødelegger også enhver destinasjon som bare er IPv6, og det skjuler den samme feilen for neste applikasjon. Hvis en maskin virkelig ikke bør bruke IPv6, er det en bevisst policy med en eier og en test. Å slå det av under en hendelse er ingen av delene.
Bestem hva klienten skal gjøre med familien, og konfigurer det eksplisitt: før den gjennom tunnelen, eller blokker den på en støttet måte slik at valget aldri tilbyr en uoppnåelig kandidat. Begge er legitime design. En global deaktivering er ingen av dem, fordi det ikke er et design i det hele tatt.
Hva som skal stå i billetten
Noter fire ting: vertsnavnet, familien som feilet, ruten kjernen valgte, og resultatet av en familiespesifikk forespørsel. Det settet er nok for noen andre til å reprodusere feilen uten å gjette hvilken av de to veiene du mente.
Reglene for adressevalg i RFC 6724 forklarer hvorfor klienten foretrakk den kandidaten den gjorde, og RFC 8305 forklarer kappløpsatferden som skjulte forsinkelsen. Ingen av dem vil rute en pakke for deg, og det er den delen tunnelen må klare.