Întrerupătorul de urgență blochează doar IPv4: de ce IPv6 tot iese

Un set de reguli de firewall pentru IPv4 nu spune nimic despre IPv6. Pe un dispozitiv cu stivă dublă, tunelul poate cădea în timp ce o aplicație păstrează o cale funcțională în jurul lui.

Tunelul cade, întrerupătorul de urgență raportează că a acționat, iar o descărcare continuă. Nimic nu este stricat în regulile IPv4. Aplicația s-a mutat pur și simplu pe o cale pentru care acele reguli nu au fost niciodată scrise.

Dispozitivele cu stivă dublă au două ieșiri independente. Un blocaj pe una dintre ele este jumătate de blocaj.

Două seturi de reguli, două valori implicite

Pe Linux, iptables și ip6tables sunt tabele separate cu politici separate. Setarea lanțurilor INPUT și OUTPUT din tabelul IPv4 pe DROP nu schimbă nimic în tabelul IPv6, unde valoarea implicită este de obicei ACCEPT. Aceeași separare există în nftables, unde poți inspecta o familie și descoperi că doar una dintre ele poartă regulile tale. Această asimetrie este normală, și ea este întreaga problemă.

De aceea un întrerupător de urgență poate părea complet și se poate comporta parțial. Scriptul care a scris regulile IPv4 a rulat, contoarele cresc, linia din jurnal apare, iar un pachet IPv6 iese prin interfața fizică complet neatins.

Citește ce instalează de fapt clientul tău, nu ce promite pagina de marketing. Unii clienți rutează IPv6 în tunel, alții îl blochează deliberat, iar alții îl lasă în pace în timp ce o blocare la nivel de platformă aplică o altă regulă. Documentația furnizorului este singura sursă în care merită să ai încredere aici.

Ce îți spune configurația interfeței

Pagina de manual a wg-quick include reguli IPv6 în configurația sa exemplu, iar motivul este exact această lacună. Exemplul nu este decor. El există pentru că doar regulile IPv4 ar lăsa a doua familie deschisă.

Copierea jumătății unui exemplu produce jumătate dintr-o politică. Aceasta este cea mai comună origine a acestei scurgeri. O postare de blog a scurtat exemplul din cauza lungimii. Versiunea scurtată a devenit apoi șablonul pe care toată lumea l-a reutilizat.

# 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

Dacă a doua comandă afișează o politică permisivă în timp ce prima afișează DROP, ai găsit răspunsul fără să atingi clientul. Această asimetrie este defectul.

De ce o singură căutare nu este toată povestea

Un singur nume poate returna atât o înregistrare A, cât și una AAAA, iar aplicațiile nu aleg toate la fel. Un browser poate prefera IPv6 când rețeaua îl oferă și poate reveni la eșec, în timp ce o sincronizare din fundal sau un actualizator folosește propriul resolver și propria preferință. Prin urmare, un test reușit pe IPv4 demonstrează o cale, nu politica.

Tranzițiile de rețea schimbă și ele răspunsul. Conectarea la o altă rețea Wi-Fi, trezirea din repaus sau trecerea la rețeaua mobilă poate oferi dispozitivului un nou prefix IPv6, iar politica ce părea suficientă în LAN-ul biroului s-ar putea să nu îl acopere.

Testează starea în care tunelul este oprit

Testarea cât timp ești conectat îți spune că tunelul funcționează. Testul interesant este starea indisponibilă, pentru că atunci ar trebui să reziste întrerupătorul de urgență. Oprește tunelul intenționat, apoi încearcă destinațiile care contează din aplicația pe care o protejezi.

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

Ambele familii ar trebui să eșueze închis. Dacă cererea IPv4 expiră și cererea IPv6 returnează un cod de stare, politica este incompletă, și nicio cantitate de retestare a tunelului nu va schimba asta.

Păstrează și excepțiile documentate în acel test. Descoperirea rețelei locale, o reînnoire DHCP sau calea de pornire către punctul final VPN pot avea nevoie să rămână accesibile, iar acele excepții ar trebui să fie numite în politică în loc să fie descoperite în timpul unei întreruperi. Un test de scurgere care eșuează pentru că tunelul nu poate reveni nu este o constatare de securitate, este o constatare de conectivitate.

Articole similare