VPN cu stivă dublă: clientul alege familia de adrese, nu dumneavoastră

Tunelul este activ, site-urile IPv4 se încarcă și un nume de gazdă expiră. Concluzia imediată este că VPN-ul este stricat sau că datele de conectare sunt greșite, iar de obicei niciuna nu este adevărată. Numele a returnat atât o adresă IPv4, cât și una IPv6, aplicația a ales una, și doar unul dintre acești candidați avea o cale funcțională. Clientul a luat decizia de selecție; tunelul pur și simplu nu acoperea ceea ce selectase.

Alegerea nu este o promisiune de acoperire

Selecția implicită a adresei, descrisă în RFC 6724, decide ce pereche sursă-destinație preferă o gazdă atunci când există mai multe disponibile. Happy Eyeballs adaugă deasupra o strategie de conexiune: începe încercări în ambele familii și o păstrează pe cea care răspunde prima, astfel încât utilizatorul să nu aștepte expirarea unei familii stricate.

Niciunul dintre mecanisme nu creează o rută. Dacă tunelul transportă doar IPv4, un candidat AAAA rămâne o destinație legitimă pe care clientul o poate încerca, iar eșecul apare ca o încărcare lentă și nu ca o eroare, pentru că browserul a revenit. Utilizatorul raportează un site lent, nu unul stricat, iar tichetul de suport moștenește această vaguitate. Reproduceți cu o familie fixă și raportul devine specific.

Această revenire este motivul pentru care simptomul este inconsecvent între aplicații. Un browser ascunde întârzierea; un client de linie de comandă cu o familie fixă vă arată eșecul real imediat.

Aflați ce familie a folosit de fapt cererea

Începeți cu numele, nu cu tunelul. Interogați ambele tipuri de înregistrare și notați ce a revenit:

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

Dacă cererea v4 reușește și cererea v6 eșuează, ați reprodus problema într-o formă pe care o puteți depana. Dacă ambele reușesc din shell și browserul tot eșuează, priviți resolverul propriu al aplicației sau un răspuns din cache înainte de a atinge tunelul.

Păstrați familia și destinația în note. Un tichet care spune că site-ul nu se încarcă prin VPN nu poate fi verificat de nimeni, în timp ce un tichet care spune că AAAA eșuează și A funcționează indică o rută anume.

Verificați ruta pentru acea familie

Pentru familia care eșuează, întrebați nucleul ce cale ar folosi și comparați-o cu adresele configurate ale tunelului. În Linux, ip -6 route get pentru destinație arată interfața și sursa care ar fi alese.

Apoi verificați tunelul însuși. Peerii WireGuard poartă o listă de IP-uri permise, iar o intrare pentru 0.0.0.0/0 nu spune nimic despre IPv6. Dacă lista peerului nu are prefix IPv6, clientul nu are niciun motiv să trimită trafic AAAA în tunel, iar pachetul iese pe ceea ce gazda ar face altfel.

Regulile de firewall și politica NAT merită aceeași verificare pentru fiecare familie. O regulă scrisă pentru IPv4 nu acoperă IPv6 pe nicio platformă, și acesta este cel mai frecvent motiv pentru care o familie funcționează iar cealaltă nu.

Nu dezactivați IPv6 pentru a simplifica captura de ecran

Dezactivarea IPv6 la nivel de sistem va face simptomul să dispară și vă va lăsa fără diagnostic. De asemenea, strică orice destinație care este doar IPv6 și ascunde aceeași eroare pentru următoarea aplicație. Dacă o mașină chiar nu ar trebui să folosească IPv6, aceea este o politică deliberată cu un proprietar și un test. Dezactivarea în timpul unui incident nu este niciuna dintre ele.

Decideți ce trebuie să facă clientul cu familia și configurați explicit: transportați-o prin tunel sau blocați-o într-un mod acceptat, astfel încât selecția să nu ofere niciodată un candidat inaccesibil. Ambele sunt proiecte legitime. O dezactivare globală nu este niciuna dintre ele, pentru că nu este deloc un proiect.

Ce să puneți în tichet

Notați patru lucruri: numele gazdei, familia care a eșuat, ruta pe care a ales-o nucleul și rezultatul unei cereri specifice familiei. Acest set este suficient pentru ca altcineva să reproducă eșecul fără să ghicească pe care dintre cele două căi ați vrut să spuneți.

Regulile de selecție a adreselor din RFC 6724 explică de ce clientul a preferat candidatul pe care l-a preferat, iar RFC 8305 explică comportamentul de cursă care a ascuns întârzierea. Niciuna dintre ele nu va ruta un pachet pentru dumneavoastră, iar aceasta este partea pe care tunelul trebuie să o facă.