Dûbel-stapel VPN: de klient kiest de adresfamylje, net jo

De tunnel is oan, IPv4-sites lade, en ien hostnamme rint op tiid út. De direkte konklúzje is dat de VPN stikken is of dat de ynloggegevens ferkeard binne, en meastentiids is net ien fan beide wier. De namme joech sawol in IPv4- as in IPv6-adres werom, de applikaasje keas ien, en mar ien fan dy kandidaten hie in wurkjend paad. De klient naam in kar; de tunnel dekte gewoan net wat hy keas.

Karre is gjin belofte fan dekking

De standert adreskar, beskreaun yn RFC 6724, beslút hokker pear boarne en bestimming in host foarkar jout as der ferskate beskikber binne. Happy Eyeballs foeget dêr in ferbiningstrategie oan ta: it begjint pogingen yn beide famyljes en hâldt dy't it earst antwurdet, sadat in brûker net wachtet oant in stikken famylje útrint.

Gjin fan beide meganismen makket in rûte. As jo tunnel allinnich IPv4 ferfiert, is in AAAA-kandidaat noch hieltyd in legitime bestimming dy't de klient besykje kin, en de mislearring docht him foar as in stadige lading ynstee fan in flater, om't de browser weromfoel. De brûker meldt in stadige side, net in stikkene, en it stipekaartsje erft dy ûndúdlikens. Meitsje it opnij mei in fêste famylje en it rapport wurdt spesifyk.

Dy weromfal is de reden dat it symptoom oer applikaasjes hinne net lyk is. In browser ferberget de fertraging; in kommandorigel-klient mei in fêste famylje lit jo de echte mislearring daliks sjen.

Fyn de famylje dy't it fersyk eins brûkt hat

Begjin mei de namme, net mei de tunnel. Freegje beide rekordtypen op en skriuw op wat weromkaam:

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

As it v4-fersyk slagget en it v6-fersyk mislearret, hawwe jo it probleem opnij makke yn in foarm dy't jo debugge kinne. As beide fan de kommandorigel slagje en de browser noch altyd mislearret, sjoch dan nei de eigen resolver fan de applikaasje of in cache-antwurd foardat jo de tunnel oanreitsje.

Hâld de famylje en de bestimming yn jo notysjes. In kaartsje dat seit dat de side net oer de VPN lade, kin nimmen kontrolearje, wylst in kaartsje dat seit dat AAAA mislearret en A wurket, nei in spesifike rûte wiist.

Kontrolearje de rûte foar dy famylje

Freegje foar de mislearjende famylje de kernel hokker paad hy brûke soe, en ferlykje dat mei de konfigurearre adressen fan de tunnel. Op Linux lit ip -6 route get foar de bestimming de ynterface en boarne sjen dy't keazen wurde soene.

Kontrolearje dan de tunnel sels. WireGuard-peers drage in list mei tastiene IP's, en in ynskriuwing foar 0.0.0.0/0 seit neat oer IPv6. As de list fan de peer gjin IPv6-prefiks hat, hat de klient gjin reden om AAAA-ferkear yn de tunnel te stjoeren, en it pakket giet derút troch wat de host oars dwaan soe.

Firewallregels en NAT-belied fertsjinje deselde kontrôle per famylje. In regel skreaun foar IPv4 dekt IPv6 net op gjin inkeld platfoarm, en dat is de meast foarkommende reden dat ien famylje wurket en de oare net.

Skeakelje IPv6 net út om de skermôfbylding ienfâldich te meitsjen

IPv6 systeembreed út skeakelje sil it symptoom ferdwine litte en jo sûnder diagnoaze efterlitte. It brekt ek elke bestimming dy't allinnich IPv6 is, en it ferberget deselde bug foar de folgjende applikaasje. As in masine echt gjin IPv6 brûke moat, is dat in bewuste polityk mei in eigner en in test. It yn in ynsidint útskeakelje is gjin fan beide.

Beslút wat de klient mei de famylje dwaan moat en konfigurearje dat eksplisyt: drage dy troch de tunnel, of blokkearje dy op in stipe wize sadat de kar nea in ûnberikbere kandidaat biedt. Beide binne legitime ûntwerpen. In globale útskeakeling is gjin fan beide, want it is hielendal gjin ûntwerp.

Wat moat der yn it kaartsje

Skriuw fjouwer dingen op: de hostnamme, de famylje dy't mislearre, de rûte dy't de kernel keas, en it resultaat fan in famyljespesifyk fersyk. Dy set is genôch foar in oar om de mislearring opnij te meitsjen sûnder te rieden hokker fan de twa paden jo bedoelden.

De regels foar adreskar fan RFC 6724 ferklearje wêrom't de klient foar de kandidaat keas dy't hy keas, en RFC 8305 ferklearret it racegedrach dat de fertraging ferburch. Gjin fan beide sil in pakket foar jo route, en dat is it diel dat de tunnel dwaan moat.