Duvosta VPN: la kliento elektas la adresan familion, ne vi

Unu nomo, du familioj, du malsamaj vojoj. La tunelo povas esti sana kaj la peto tamen malsukcesi, ĉar la kliento elektis kandidaton, kiun vi neniam enkursigis.

La tunelo funkcias, IPv4-ejoj ŝarĝiĝas, kaj unu gastigantnomo eksvalidiĝas. La tuja konkludo estas, ke la VPN estas difektita aŭ ke la legitimoj estas malĝustaj, kaj kutime neniu el la du veras. La nomo resendis kaj IPv4-adreson kaj IPv6-adreson, la aplikaĵo elektis unu, kaj nur unu el tiuj kandidatoj havis funkciantan vojon. La kliento faris elekton; la tunelo simple ne kovris tion, kion ĝi elektis.

Elekto ne estas promeso pri kovrado

La defaŭlta adresa elekto, priskribita en RFC 6724, decidas, kiun paron de fonto kaj celo gastiganto preferas, kiam pluraj disponeblas. Happy Eyeballs aldonas sur tion konektan strategion: ĝi komencas provojn en ambaŭ familioj kaj konservas tiun, kiu respondas unue, por ke uzanto ne atendu, ĝis difektita familio eksvalidiĝos.

Neniu el la mekanismoj kreas vojon. Se via tunelo portas nur IPv4, AAAA-kandidato restas laŭleĝa celo, kiun la kliento povas provi, kaj la malsukceso aperas kiel malrapida ŝarĝo anstataŭ eraro, ĉar la retumilo fallbackis. La uzanto raportas malrapidan ejon, ne difektitan, kaj la subtena bileto heredas tiun malklarecon. Riproduktu ĝin kun fiksita familio kaj la raporto fariĝos preciza.

Pro tiu fallback la simptomo estas malkonsekvenca inter aplikaĵoj. Retumilo kaŝas la prokraston; komandlinia kliento kun fiksita familio montras al vi la veran malsukceson tuj.

Trovu la familion, kiun la peto efektive uzis

Komencu per la nomo, ne per la tunelo. Demandu ambaŭ rikordtipojn kaj notu, kio revenis:

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

Se la v4-peto sukcesas kaj la v6-peto malsukcesas, vi reproduktis la problemon en formo, kiun vi povas sencimigi. Se ambaŭ sukcesas el la ŝelo kaj la retumilo daŭre malsukcesas, rigardu la propran solvilon de la aplikaĵo aŭ kaŝitan respondon antaŭ ol tuŝi la tunelon.

Konservu la familion kaj la celon en viaj notoj. Bileto, kiu diras, ke la ejo ne ŝarĝiĝas tra la VPN, ne povas esti kontrolita de iu ajn, dum bileto, kiu diras, ke AAAA malsukcesas kaj A funkcias, montras al specifa vojo.

Kontrolu la vojon por tiu familio

Por la malsukcesa familio, demandu la kernon, kiun vojon ĝi uzus, kaj komparu ĝin kun la agorditaj adresoj de la tunelo. En Linux, ip -6 route get por la celo montras la interfacon kaj la fonton, kiuj estus elektitaj.

Poste kontrolu la tunelon mem. WireGuard-peer'oj portas liston de permesitaj IP-oj, kaj rikordo por 0.0.0.0/0 diras nenion pri IPv6. Se la listo de la peer ne havas IPv6-prefikson, la kliento havas neniun kialon sendi AAAA-trafikon en la tunelon, kaj la paketo eliras per tio, kion la gastiganto alie farus.

Fajroŝirmilaj reguloj kaj NAT-politiko meritigas la saman kontrolon por ĉiu familio. Regulo skribita por IPv4 ne kovras IPv6 sur neniu platformo, kaj tio estas la plej ofta kialo, kial unu familio funkcias dum la alia ne.

Ne malŝaltu IPv6 por simpligi la ekrankopion

Malŝalti IPv6 tutsisteme igos la simptomon malaperi kaj lasos vin sen diagnozo. Ĝi ankaŭ rompas ĉiun celon, kiu estas nur-IPv6, kaj kaŝas la saman cimon por la sekva aplikaĵo. Se maŝino vere ne devus uzi IPv6, tio estas intenca politiko kun posedanto kaj testo. Malŝalti ĝin dum incidento estas nek unu nek la alia.

Decidu, kion la kliento faru kun la familio, kaj agordu tion eksplice: portu ĝin tra la tunelo, aŭ bloku ĝin laŭsubtene tiel, ke la elekto neniam proponu neatingeblan kandidaton. Ambaŭ estas legitimaj dezajnoj. Tutmonda malŝalto estas nek unu nek la alia, ĉar ĝi tute ne estas dezajno.

Kion meti en la bileton

Notu kvar aferojn: la gastigantnomon, la familion, kiu malsukcesis, la vojon, kiun la kerno elektis, kaj la rezulton de familispecifa peto. Tiu aro sufiĉas, por ke iu alia reproduktu la malsukceson sen diveni, kiun el la du vojoj vi intencis.

La adreselektaj reguloj de RFC 6724 klarigas, kial la kliento preferis la kandidaton, kiun ĝi preferis, kaj RFC 8305 klarigas la konkursan konduton, kiu kaŝis la prokraston. Neniu el ili enkursigos paketon por vi, kaj tio estas la parto, kiun la tunelo devas fari.

Rilataj artikoloj