Avārijas slēdzis bloķē tikai IPv4: kāpēc IPv6 joprojām izkļūst

Tunelis nokrīt, avārijas slēdzis ziņo, ka tas ir iedarbojies, un lejupielāde turpinās. IPv4 noteikumos nekas nav salūzis. Lietotne vienkārši pārvietojās uz ceļu, kuram šie noteikumi nekad netika rakstīti.

Divkāršas stekas ierīcēm ir divas neatkarīgas izejas. Vienas no tām bloķēšana ir puse bloka.

Divi noteikumu kopumi, divi noklusējumi

Linux iptables un ip6tables ir atsevišķas tabulas ar atsevišķām politikām. IPv4 tabulas INPUT un OUTPUT ķēžu iestatīšana uz DROP neko nemaina IPv6 tabulā, kur noklusējums parasti ir ACCEPT. Tāda pati sadalīšana pastāv nftables, kur var apskatīt vienu saimi un atklāt, ka tikai viena no tām nes jūsu noteikumus. Šī asimetrija ir normāla, un tā ir visa problēma.

Tāpēc avārijas slēdzis var izskatīties rūpīgi un darboties daļēji. Skripts, kas rakstīja IPv4 noteikumus, tika izpildīts, skaitītāji pieaug, žurnāla rinda parādās, un IPv6 pakete iziet caur fizisko saskarni pilnīgi neskarta.

Lasiet, ko jūsu klients faktiski instalē, nevis ko sola mārketinga lapa. Daži klienti novirza IPv6 uz tuneli, citi to apzināti bloķē, bet vēl citi atstāj to mierā, kamēr platformas līmeņa bloķēšana piemēro citu noteikumu. Ražotāja dokumentācija šeit ir vienīgais avots, kam ir vērts uzticēties.

Ko jums stāsta saskarnes konfigurācija

wg-quick rokasgrāmatas lapa savā piemēra konfigurācijā iekļauj IPv6 noteikumus, un iemesls ir tieši šī plaisa. Piemērs nav rotājums. Tas pastāv tāpēc, ka tikai IPv4 noteikumi atstātu otro saimi atvērtu.

Puses piemēra kopēšana rada pusi politikas. Tas ir visizplatītākais šīs noplūdes avots. Kāds emuāra ieraksts saīsināja piemēru garuma dēļ. Pēc tam saīsinātā versija kļuva par veidni, ko visi izmantoja atkārtoti.

# 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

Ja otrā komanda izdrukā atļaujošu politiku, bet pirmā izdrukā DROP, jūs esat atradis atbildi, nepieskaroties klientam. Šī asimetrija ir kļūda.

Kāpēc viena meklēšana nav viss stāsts

Viens nosaukums var atgriezt gan A ierakstu, gan AAAA ierakstu, un lietotnes ne visas izvēlas vienādi. Pārlūks var dot priekšroku IPv6, kad tīkls to piedāvā, un atteikties neveiksmes gadījumā, kamēr fona sinhronizācija vai atjauninātājs izmanto savu risinātāju un savu izvēli. Tāpēc viens veiksmīgs tests pār IPv4 pierāda vienu ceļu, nevis politiku.

Tīkla pārejas maina arī atbildi. Pievienošanās citam Wi-Fi tīklam, pamošanās no miega vai pāreja uz mobilo tīklu var piešķirt ierīcei jaunu IPv6 prefiksu, un politika, kas biroja LAN tīklā šķita pietiekama, to var neaptvert.

Pārbaudiet stāvokli, kad tunelis ir izslēgts

Testēšana, kamēr esat savienots, pasaka, ka tunelis darbojas. Interesantais tests ir nepieejamais stāvoklis, jo tieši tad avārijas slēdzim ir jāiztur. Apzināti apturiet tuneli, pēc tam izmēģiniet svarīgos galamērķus no lietotnes, kuru aizsargājat.

# 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/

Abām saimēm vajadzētu neizdoties slēgti. Ja IPv4 pieprasījums beidzas ar taimautu un IPv6 pieprasījums atgriež statusa kodu, politika ir nepilnīga, un nekāds tunela atkārtots tests to nemainīs.

Saglabājiet arī dokumentētos izņēmumus šajā testā. Vietējā tīkla atklāšana, DHCP atjaunošana vai sāknēšanas ceļš uz VPN galapunktu var būt jāatstāj pieejams, un šie izņēmumi ir jānosauc politikā, nevis jāatklāj pārtraukuma laikā. Noplūdes tests, kas neizdodas tāpēc, ka tunelis nevar atgriezties, nav drošības atradums, tas ir savienojamības atradums.