VPN me dy shtresa: klienti zgjedh familjen e adresave, jo ju

Tuneli është lart, faqet IPv4 ngarkohen dhe një emër hosti skadon. Përfundimi i menjëhershëm është se VPN-ja është prishur ose kredencialet janë të gabuara, dhe zakonisht asnjëra nuk është e vërtetë. Emri ktheu si adresë IPv4 ashtu edhe IPv6, aplikacioni zgjodhi njërën, dhe vetëm një prej atyre kandidatëve kishte një rrugë funksionale. Vendimin e zgjedhjes e mori klienti; tuneli thjesht nuk mbulonte atë që kishte zgjedhur.

Zgjedhja nuk është premtim mbulimi

Zgjedhja e paracaktuar e adresës, e përshkruar në RFC 6724, vendos se cilin çift burimi dhe destinacioni hosti preferon kur ka disa të disponueshëm. Happy Eyeballs shton sipër një strategji lidhjeje: nis përpjekje në të dyja familjet dhe mban atë që përgjigjet e para, kështu që përdoruesi nuk pret që një familje e prishur të skadojë.

Asnjëri prej mekanizmave nuk krijon një rrugë. Nëse tuneli juaj mbart vetëm IPv4, një kandidat AAAA është ende një destinacion i ligjshëm që klienti mund të provojë, dhe dështimi shfaqet si ngarkim i ngadaltë dhe jo si gabim, sepse shfletuesi u kthye pas. Përdoruesi raporton një sajt të ngadaltë, jo të prishur, dhe bileta e mbështetjes trashëgon atë paqartësi. Riprodhojeni me një familje fikse dhe raporti bëhet i saktë.

Pikërisht për shkak të atij kthimi pas, simptomi është i paqëndrueshëm midis aplikacioneve. Shfletuesi fsheh vonesën; një klient i linjës së komandës me familje fikse ju tregon dështimin e vërtetë menjëherë.

Gjeni familjen që kërkesa përdori vërtet

Filloni me emrin, jo me tunelin. Pyetni të dy llojet e regjistrave dhe shënoni çfarë u kthye:

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

Nëse kërkesa v4 ka sukses dhe kërkesa v6 dështon, e keni riprodhuar problemin në një formë që mund ta korrigjoni. Nëse të dyja kanë sukses nga shell-i dhe shfletuesi vazhdon të dështojë, shikoni zgjidhësin e vetë aplikacionit ose një përgjigje të ruajtur në cache përpara se të prekni tunelin.

Mbani familjen dhe destinacionin në shënimet tuaja. Një biletë që thotë se sajti nuk ngarkohet përmes VPN-së nuk mund ta verifikojë askush, ndërsa një biletë që thotë se AAAA dështon dhe A funksionon tregon një rrugë të caktuar.

Kontrolloni rrugën për atë familje

Për familjen që dështon, pyetni kernelin se cilën rrugë do të përdorte dhe krahasojeni me adresat e konfiguruara të tunelit. Në Linux, ip -6 route get për destinacionin tregon ndërfaqen dhe burimin që do të zgjidheshin.

Më pas kontrolloni vetë tunelin. Peer-ët e WireGuard mbajnë një listë të IP-ve të lejuara, dhe një hyrje për 0.0.0.0/0 nuk thotë asgjë për IPv6. Nëse lista e peer-it nuk ka prefiks IPv6, klienti nuk ka arsye të dërgojë trafik AAAA në tunel, dhe paketa del nëpër atë që hosti do të bënte ndryshe.

Rregullat e firewall-it dhe politika NAT meritojnë të njëjtin kontroll për çdo familje. Një rregull i shkruar për IPv4 nuk mbulon IPv6 në asnjë platformë, dhe kjo është arsyeja më e zakonshme që një familje funksionon ndërsa tjetra jo.

Mos e çaktivizoni IPv6 për ta bërë pamjen e ekranit të thjeshtë

Çaktivizimi i IPv6 në të gjithë sistemin do ta bëjë simptomën të zhduket dhe do t'ju lërë pa diagnozë. Ai gjithashtu prish çdo destinacion që është vetëm IPv6, dhe fsheh të njëjtin bug për aplikacionin tjetër. Nëse një makinë vërtet nuk duhet të përdorë IPv6, kjo është një politikë e qëllimshme me pronar dhe test. Çaktivizimi gjatë një incidenti nuk është asnjëra prej tyre.

Vendosni çfarë duhet të bëjë klienti me familjen dhe konfiguroni atë në mënyrë eksplicite: kalojeni nëpër tunel, ose bllokojeni në një mënyrë të mbështetur që zgjedhja të mos ofrojë kurrë një kandidat të paarritshëm. Të dyja janë dizajne të ligjshme. Çaktivizimi global nuk është asnjëra, sepse nuk është fare dizajn.

Çfarë të shkruani në biletë

Shënoni katër gjëra: emrin e hostit, familjen që dështoi, rrugën që zgjodhi kerneli dhe rezultatin e një kërkese specifike për familjen. Ky grup është i mjaftueshëm që dikush tjetër të riprodhojë dështimin pa hamendësuar se cilën nga dy rrugët kishit fjalën.

Rregullat e zgjedhjes së adresave RFC 6724 shpjegojnë pse klienti preferoi kandidatin që preferoi, dhe RFC 8305 shpjegon sjelljen e garës që fshehu vonesën. Asnjëra prej tyre nuk do të drejtojë një paketë për ju, dhe kjo është pjesa që duhet të bëjë tuneli.