Dobbeltstakk-VPN: klienten vel adressefamilien, ikkje du

Tunnelen er oppe, IPv4-nettstader lastar, og eitt vertsnamn går ut på tid. Den umiddelbare konklusjonen er at VPN-en er øydelagd eller at påloggingsinformasjonen er feil, og ingen av delane stemmer vanlegvis. Namnet returnerte både ein IPv4- og ein IPv6-adresse, applikasjonen valde éin, og berre éin av desse kandidatane hadde ein fungerande veg. Klienten tok valavgjerda; tunnelen dekte rett og slett ikkje det han valde.

Val er ikkje eit løfte om dekning

Standard adresseval, skildra i RFC 6724, avgjer kva kjelde- og målpar ein vert føretrekk når fleire er tilgjengelege. Happy Eyeballs legg ein tilkoplingsstrategi på toppen: han startar forsøk i begge familiar og held på den som svarar først, slik at ein brukar ikkje ventar på at ein øydelagd familie skal gå ut på tid.

Ingen av mekanismane opprettar ein rute. Viss tunnelen din berre fører IPv4, er ein AAAA-kandidat framleis ein legitim destinasjon som klienten kan prøve, og feilen viser seg som treg lasting i staden for ein feil, fordi nettlesaren fall tilbake. Brukaren rapporterer ein treg nettstad, ikkje ein øydelagd, og støttebillettar arvar den uklarleiken. Reproduser det med ein fast familie, og rapporten blir konkret.

Det tilbakefallet er grunnen til at symptomet er inkonsistent på tvers av applikasjonar. Ein nettlesar skjuler forseinkinga; ein kommandolinjeklient med ein fast familie viser deg den verkelege feilen med ein gong.

Finn familien førespurnaden faktisk brukte

Byrja med namnet, ikkje tunnelen. Spør på begge posttypane og noter kva 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.com

Viss v4-førespurnaden lukkast og v6-førespurnaden feilar, har du reprodusert problemet i ei form du kan feilsøkje. Viss begge lukkast frå skalet og nettlesaren framleis feilar, sjå på applikasjonen sin eigen resolvar eller eit bufra svar før du rører tunnelen.

Hald familien og destinasjonen i notata dine. Ein billett som seier at nettstaden ikkje lastar over VPN-en, kan ingen kontrollere, medan ein billett som seier at AAAA feilar og A verkar, peikar på ein bestemt rute.

Kontroller ruta for den familien

For familien som feilar, spør kjernen kva veg han ville bruke, og samanlikn han med dei konfigurerte adressene til tunnelen. På Linux viser ip -6 route get for destinasjonen grensesnittet og kjelda som ville bli vald.

Kontroller deretter sjølve tunnelen. WireGuard-peerar fører ei liste over tillatne IP-ar, og ei oppføring for 0.0.0.0/0 seier ingenting om IPv6. Viss lista til peeren ikkje har noko IPv6-prefiks, har klienten ingen grunn til å sende AAAA-trafikk inn i tunnelen, og pakken forlèt via det verten elles ville gjort.

Brannmurreglar og NAT-policy fortener same kontrollen per familie. Ein regel skriven for IPv4 dekkjer ikkje IPv6 på nokon plattform, og det er den vanlegaste grunnen til at éin familie verkar medan den andre ikkje gjer det.

Ikkje deaktiver IPv6 for å gjere skjermbiletet enkelt

Å slå av IPv6 systemvidt vil få symptomet til å forsvinne og late deg stå utan diagnose. Det øydelegg òg ein kvar destinasjon som berre er IPv6, og det skjuler den same feilen for neste applikasjon. Viss ein maskin verkeleg ikkje bør bruke IPv6, er det ein bevisst policy med ein eigar og ein test. Å slå det av under ei hending er ingen av delane.

Avgjer kva klienten skal gjere med familien, og konfigurer det eksplisitt: før han gjennom tunnelen, eller blokker han på ein støtta måte slik at valet aldri tilbyr ein uoppnåeleg kandidat. Begge er legitime design. Ei global deaktivering er ingen av dei, fordi det ikkje er eit design i det heile.

Kva som skal stå i billetten

Noter fire ting: vertsnamnet, familien som feila, ruta kjernen valde, og resultatet av ein familiespesifikk førespurnad. Det settet er nok for nokon andre til å reprodusere feilen utan å gjete kva av dei to vegane du meinte.

Reglane for adresseval i RFC 6724 forklarer kvifor klienten føretrekte den kandidaten han gjorde, og RFC 8305 forklarer kapplaupsoppførselen som skjulte forseinkinga. Ingen av dei vil rute ein pakke for deg, og det er den delen tunnelen må klare.