La haltigilo blokas nur IPv4: kial IPv6 ankoraŭ eliras

La tunelo falas, la haltigilo raportas, ke ĝi agis, kaj elŝuto daŭras. Nenio rompiĝis en la reguloj de IPv4. La aplikaĵo simple moviĝis al vojo, por kiu tiuj reguloj neniam estis skribitaj.

Duoblaj-stakaj aparatoj havas du sendependajn elirojn. Blokado de unu el ili estas duona blokado.

Du regul-aroj, du defaŭltoj

En Linux, iptables kaj ip6tables estas apartaj tabeloj kun apartaj politikoj. Agordi la ĉenojn INPUT kaj OUTPUT de la IPv4-tabelo al DROP ŝanĝas nenion en la IPv6-tabelo, kie la defaŭlto kutime estas ACCEPT. La sama divido ekzistas en nftables, kie vi povas inspekti unu familion kaj trovi, ke nur unu el ili portas viajn regulojn. Tiu malsimetrio estas normala, kaj ĝi estas la tuta problemo.

Tial haltigilo povas aspekti solida kaj agi parte. La skripto, kiu skribis la regulojn de IPv4, ruliĝis, la nombriloj pliiĝas, la protokola linio aperas, kaj IPv6-paketo forlasas la fizikan interfacon tute netuŝita.

Legu, kion via kliento fakte instalas, anstataŭ kion promesas la merkatika paĝo. Iuj klientoj enkursigas IPv6 en la tunelon, iuj intence blokas ĝin, kaj iuj lasas ĝin trankvila dum ŝloso sur platforma nivelo aplikas alian regulon. La dokumentaro de la vendisto estas la sola fonto fidinda ĉi tie.

Kion diras al vi la interfaca agordo

La manlibra paĝo de wg-quick inkluzivas IPv6-regulojn en sia ekzemplo-agordo, kaj la kialo estas ĝuste ĉi tiu breĉo. La ekzemplo ne estas ornamaĵo. Ĝi ekzistas ĉar nur la reguloj de IPv4 lasus la duan familion malfermita.

Kopii duonon de ekzemplo produktas duonon de politiko. Tio estas la plej ofta origino de ĉi tiu liko. Blogafiŝo mallongigis la ekzemplon pro longo. La mallongigita versio tiam fariĝis la ŝablono, kiun ĉiuj reuzis.

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

Se la dua komando presas permesan politikon dum la unua presas DROP, vi trovis la respondon sen tuŝi la klienton. Tiu malsimetrio estas la cimo.

Kial unu serĉo ne estas la tuta rakonto

Unu nomo povas redoni kaj A-rikordon kaj AAAA-rikordon, kaj aplikaĵoj ne ĉiuj elektas same. Retumilo povas preferi IPv6 kiam la reto proponas ĝin kaj retropaŝi ĉe malsukceso, dum fona sinkronigo aŭ ĝisdatigilo uzas sian propran solvilon kaj sian propran preferon. Tial unu sukcesa testo trans IPv4 pruvas unu vojon, ne la politikon.

Retaj transiroj ankaŭ ŝanĝas la respondon. Aliĝi al alia Wi-Fi-reto, vekiĝi el dormo aŭ ŝanĝi al poŝtelefona reto povas doni al la aparato novan IPv6-prefikson, kaj la politiko, kiu aspektis sufiĉa en la oficeja LAN, eble ne kovras ĝin.

Testu la staton, kiam la tunelo estas malsupre

Testado dum vi estas konektita diras al vi, ke la tunelo funkcias. La interesa testo estas la neatingebla stato, ĉar tiam la haltigilo devus teni. Intence haltigu la tunelon, poste provu la celojn, kiuj gravas, el la aplikaĵo, kiun vi protektas.

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

Ambaŭ familioj devus malsukcesi fermite. Se la IPv4-peto tempolimas kaj la IPv6-peto redonas statkodon, la politiko estas nekompleta, kaj neniu kvanto de retestado de la tunelo tion ŝanĝos.

Konservu ankaŭ la dokumentitajn esceptojn en tiu testo. Loka reta malkovro, DHCP-renovigo aŭ la startiga vojo al la VPN-finpunkto eble devas resti atingeblaj, kaj tiuj esceptoj estu nomitaj en la politiko anstataŭ malkovritaj dum interrompo. Likotesto, kiu malsukcesas ĉar la tunelo ne povas releviĝi, ne estas sekureca trovaĵo, ĝi estas konekteca trovaĵo.