Avarinis jungiklis blokuoja tik IPv4: kodėl IPv6 vis tiek išeina

Tunelis nukrenta, avarinis jungiklis praneša, kad suveikė, o atsisiuntimas tęsiasi. IPv4 taisyklėse niekas nesugedę. Programėlė tiesiog persikėlė į kelią, kuriam tos taisyklės niekada nebuvo parašytos.

Dvigubos rietuvės įrenginiai turi du nepriklausomus išėjimus. Vieno jų blokavimas yra pusė blokavimo.

Du taisyklių rinkiniai, dvi numatytosios reikšmės

Linux sistemoje iptables ir ip6tables yra atskiros lentelės su atskiromis politikomis. IPv4 lentelės INPUT ir OUTPUT grandinių nustatymas į DROP nieko nekeičia IPv6 lentelėje, kur numatytoji reikšmė paprastai yra ACCEPT. Toks pat suskirstymas egzistuoja nftables, kur galite patikrinti vieną šeimą ir pamatyti, kad tik viena jų neša jūsų taisykles. Ši asimetrija yra normalu, ir tai yra visa problema.

Štai kodėl avarinis jungiklis gali atrodyti nuodugniai, o veikti iš dalies. Scenarijus, parašęs IPv4 taisykles, įvykdytas, skaitikliai didėja, žurnalo eilutė atsiranda, o IPv6 paketas palieka fizinę sąsają visiškai neliestas.

Skaitykite, ką jūsų klientas iš tikrųjų įdiegia, o ne ką žada rinkodaros puslapis. Vieni klientai nukreipia IPv6 į tunelį, kiti sąmoningai jį blokuoja, o dar kiti palieka jį ramybėje, kol platformos lygmens užraktas taiko kitą taisyklę. Čia pardavėjo dokumentacija yra vienintelis šaltinis, kuriuo verta pasitikėti.

Ką jums sako sąsajos konfigūracija

„wg-quick“ vadovo puslapis savo pavyzdinėje konfigūracijoje įtraukia IPv6 taisykles, ir priežastis yra būtent ši spraga. Pavyzdys nėra puošmena. Jis egzistuoja todėl, kad vien IPv4 taisyklės paliktų antrąją šeimą atvirą.

Nukopijuoti pusę pavyzdžio reiškia gauti pusę politikos. Tai dažniausia šio nuotėkio priežastis. Vienas tinklaraščio įrašas sutrumpino pavyzdį dėl ilgio. Tada sutrumpinta versija tapo šablonu, kurį visi naudojo iš naujo.

# 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

Jei antroji komanda spausdina leidžiančią politiką, o pirmoji — DROP, atsakymą radote nelietę kliento. Ši asimetrija ir yra klaida.

Kodėl viena užklausa nėra visa istorija

Vienas vardas gali grąžinti ir A įrašą, ir AAAA įrašą, o programos renkasi ne visos vienodai. Naršyklė gali teikti pirmenybę IPv6, kai tinklas jį siūlo, ir atsitraukti nepavykus, o foninė sinchronizacija ar atnaujinimo programa naudoja savo paties sprendiklį ir savo pirmenybę. Todėl vienas sėkmingas bandymas per IPv4 įrodo vieną kelią, o ne politiką.

Tinklo perėjimai taip pat keičia atsakymą. Prisijungimas prie kito Wi-Fi tinklo, pabudimas iš miego ar perėjimas prie mobiliojo ryšio gali suteikti įrenginiui naują IPv6 priešdėlį, o politika, kuri atrodė pakankama biuro LAN tinkle, gali jo neapimti.

Išbandykite būseną, kai tunelis išjungtas

Bandymas prisijungus pasako, kad tunelis veikia. Įdomus bandymas yra neprieinama būsena, nes tada avarinis jungiklis turi išsilaikyti. Sąmoningai sustabdykite tunelį, tada išbandykite svarbias paskirties vietas iš programos, kurią saugote.

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

Abi šeimos turėtų nepavykti uždarai. Jei IPv4 užklausa baigiasi laiko limitu, o IPv6 užklausa grąžina būsenos kodą, politika yra nepilna, ir joks pakartotinis tunelio bandymas to nepakeis.

Išsaugokite ir dokumentuotas išimtis tame bandyme. Vietinio tinklo aptikimas, DHCP atnaujinimas ar įkrovos kelias iki VPN galinio taško gali turėti likti pasiekiami, ir šios išimtys turėtų būti įvardytos politikoje, o ne atrastos per sutrikimą. Nuotėkio bandymas, kuris nepavyksta todėl, kad tunelis negali vėl pakilti, nėra saugumo radinys, tai ryšio radinys.