Dubbelstapel-VPN: die kliënt kies die adresfamilie, nie jy nie

Die tonnel is op, IPv4-werwe laai, en een gasheernaam hou uit. Die onmiddellike gevolgtrekking is dat die VPN stukkend is of die geloofsbriewe verkeerd is, en nie een daarvan is gewoonlik waar nie. Die naam het sowel 'n IPv4- as 'n IPv6-adres teruggegee, die toepassing het een gekies, en net een van daardie kandidate het 'n werkende pad gehad. Die kliënt het 'n keuse gemaak; die tonnel het bloot nie gedek wat hy gekies het nie.

Keuse is nie 'n belofte van dekking nie

Verstek-adreskeuse, soos in RFC 6724 beskryf, bepaal watter bron- en bestemmingspaar 'n gasheer verkies wanneer verskeie beskikbaar is. Happy Eyeballs voeg 'n verbindingstrategie daarby: dit begin pogings op beide families en behou die een wat eerste antwoord, sodat 'n gebruiker nie wag vir 'n stukkende familie om uit te hou nie.

Nie een van die meganismes skep 'n roete nie. As jou tonnel slegs IPv4 dra, is 'n AAAA-kandidaat steeds 'n geldige bestemming wat die kliënt kan probeer, en die mislukking wys as 'n stadige laai eerder as 'n fout, omdat die blaaier teruggeval het. Die gebruiker rapporteer 'n stadige werf, nie 'n stukkende een nie, en die ondersteuningskaartjie erf daardie vaagheid. Herproduseer dit met 'n vaste familie en die verslag word spesifiek.

Daardie terugval is hoekom die simptoom wisselvallig oor toepassings is. 'n Blaaier verberg die vertraging; 'n opdragreël-kliënt met 'n vaste familie wys jou die werklike mislukking onmiddellik.

Vind die familie wat die versoek werklik gebruik het

Begin met die naam, nie die tonnel nie. Vra beide rekordtipes en let op wat terugkom:

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 die v4-versoek slaag en die v6-versoek misluk, het jy die probleem herproduseer in 'n vorm wat jy kan ontfout. As albei van die dop slaag en die blaaier steeds misluk, kyk na die toepassing se eie oplosser of 'n gekaste antwoord voordat jy aan die tonnel raak.

Hou die familie en die bestemming in jou notas. 'n Kaartjie wat sê die werf laai nie oor die VPN nie, kan deur niemand nagegaan word nie, terwyl 'n kaartjie wat sê AAAA misluk en A werk, na 'n spesifieke roete wys.

Kontroleer die roete vir daardie familie

Vir die mislukkende familie, vra die kern watter pad dit sou gebruik en vergelyk dit met die tonnel se gekonfigureerde adresse. Op Linux wys ip -6 route get vir die bestemming die koppelvlak en bron wat gekies sou word.

Kontroleer dan die tonnel self. WireGuard-eweknieë dra 'n lys toegelate IP's, en 'n inskrywing vir 0.0.0.0/0 sê niks oor IPv6 nie. As die eweknie se lys geen IPv6-voorvoegsel het nie, het die kliënt geen rede om AAAA-verkeer in die tonnel te stuur nie, en die pakkie verlaat deur wat die gasheer andersins sou doen.

Brandmuur-reëls en NAT-beleid verdien dieselfde kontrole per familie. 'n Reël geskryf vir IPv4 dek nie IPv6 op enige platform nie, en dit is die enkele mees algemene rede hoekom een familie werk terwyl die ander nie.

Moenie IPv6 afskakel om die skermskoot eenvoudig te maak nie

Om IPv6 stelselwyd af te skakel sal die simptoom laat verdwyn en jou sonder 'n diagnose laat. Dit breek ook enige bestemming wat slegs IPv6 is, en dit verberg dieselfde fout vir die volgende toepassing. As 'n masjien werklik nie IPv6 behoort te gebruik nie, is dit 'n doelbewuste beleid met 'n eienaar en 'n toets. Om dit tydens 'n voorval af te skakel is nie een van dié nie.

Bepaal wat die kliënt met die familie moet doen en konfigureer dit uitdruklik: dra dit deur die tonnel, of blokkeer dit op 'n ondersteunde manier sodat die keuse nooit 'n onbereikbare kandidaat bied nie. Albei is geldige ontwerpe. 'n Globale afskakeling is nie een nie, want dit is glad nie 'n ontwerp nie.

Wat om in die kaartjie te sit

Teken vier dinge aan: die gasheernaam, die familie wat misluk het, die roete wat die kern gekies het, en die resultaat van 'n familie-spesifieke versoek. Daardie stel is genoeg vir iemand anders om die mislukking te herproduseer sonder om te raai watter van die twee paaie jy bedoel het.

Die RFC 6724-adreskeusereëls verduidelik hoekom die kliënt die kandidaat verkies het wat dit gedoen het, en RFC 8305 verduidelik die wedloopgedrag wat die vertraging verberg het. Nie een van hulle sal 'n pakkie vir jou roeteer nie, en dit is die deel wat die tonnel moet doen.