Dubbelstack-VPN: klienten väljer adressfamiljen, inte du
Ett namn, två familjer, två olika vägar. Tunneln kan vara frisk och begäran ändå misslyckas, eftersom klienten valde en kandidat som du aldrig routade.
Tunneln är uppe, IPv4-webbplatser laddas och ett värdnamn tar timeout. Den omedelbara slutsatsen är att VPN:en är trasig eller att inloggningsuppgifterna är fel, och oftast stämmer inget av det. Namnet returnerade både en IPv4- och en IPv6-adress, programmet valde en, och bara en av dessa kandidater hade en fungerande väg. Klienten fattade valbeslutet; tunneln täckte helt enkelt inte det den valde.
Val är inte ett löfte om täckning
Standardadressvalet, som beskrivs i RFC 6724, avgör vilket par av källa och mål en värd föredrar när flera finns tillgängliga. Happy Eyeballs lägger en anslutningsstrategi ovanpå: den startar försök i båda familjerna och behåller den som svarar först, så att en användare inte väntar på att en trasig familj ska ta timeout.
Ingen av mekanismerna skapar en rutt. Om tunneln bara transporterar IPv4 är en AAAA-kandidat fortfarande ett legitimt mål som klienten kan prova, och felet visar sig som långsam laddning i stället för ett fel, eftersom webbläsaren föll tillbaka. Användaren rapporterar en långsam webbplats, inte en trasig, och supportbiljetten ärver den otydligheten. Reproducera det med en fast familj och rapporten blir specifik.
Det återfallet är anledningen till att symtomet är inkonsekvent mellan program. En webbläsare döljer fördröjningen; en kommandoradsclient med en fast familj visar dig det verkliga felet direkt.
Ta reda på vilken familj begäran faktiskt använde
Börja med namnet, inte med tunneln. Fråga efter båda posttyperna och notera vad som kom tillbaka:
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.comOm v4-begäran lyckas och v6-begäran misslyckas har du reproducerat problemet i en form du kan felsöka. Om båda lyckas från skalet och webbläsaren fortfarande misslyckas, titta på programmets egen resolver eller ett cachat svar innan du rör tunneln.
Håll familjen och målet i dina anteckningar. En biljett som säger att webbplatsen inte laddas via VPN:en kan ingen kontrollera, medan en biljett som säger att AAAA misslyckas och A fungerar pekar på en specifik rutt.
Kontrollera rutten för den familjen
För familjen som misslyckas, fråga kärnan vilken väg den skulle använda och jämför den med tunnelns konfigurerade adresser. På Linux visar ip -6 route get för målet det gränssnitt och den källa som skulle väljas.
Kontrollera sedan själva tunneln. WireGuard-peers bär en lista över tillåtna IP-adresser, och en post för 0.0.0.0/0 säger ingenting om IPv6. Om peerns lista inte har något IPv6-prefix har klienten ingen anledning att skicka AAAA-trafik in i tunneln, och paketet lämnar via det värden annars skulle göra.
Brandväggsregler och NAT-policy förtjänar samma kontroll per familj. En regel skriven för IPv4 täcker inte IPv6 på någon plattform, och det är den vanligaste anledningen till att en familj fungerar medan den andra inte gör det.
Inaktivera inte IPv6 för att göra skärmbilden enkel
Att stänga av IPv6 systembrett får symtomet att försvinna och lämnar dig utan diagnos. Det bryter också varje mål som bara är IPv6, och det döljer samma bugg för nästa program. Om en maskin verkligen inte borde använda IPv6 är det en medveten policy med en ägare och ett test. Att stänga av det under en incident är inget av dem.
Bestäm vad klienten ska göra med familjen och konfigurera det uttryckligen: bär den genom tunneln, eller blockera den på ett stödt sätt så att valet aldrig erbjuder en oåtkomlig kandidat. Båda är legitima designer. En global avstängning är inget av dem, eftersom det inte är en design alls.
Vad som ska stå i biljetten
Anteckna fyra saker: värdnamnet, familjen som misslyckades, rutten som kärnan valde och resultatet av en familjespecifik begäran. Den uppsättningen räcker för att någon annan ska kunna reproducera felet utan att gissa vilken av de två vägarna du menade.
Reglerna för adressval i RFC 6724 förklarar varför klienten föredrog den kandidat den gjorde, och RFC 8305 förklarar det tävlingsbeteende som dolde fördröjningen. Ingen av dem kommer att routa ett paket åt dig, och det är den delen tunneln måste klara.