Hädalüliti blokeerib ainult IPv4: miks IPv6 ikka välja pääseb

Tunnel katkeb, hädalüliti teatab, et see rakendus, ja allalaadimine jätkub. IPv4 reeglites pole midagi katki. Rakendus lihtsalt liikus teele, mille jaoks neid reegleid kunagi ei kirjutatud.

Kahe virna seadmetel on kaks sõltumatut väljapääsu. Ühe blokeerimine on pool blokeeringut.

Kaks reeglikogumit, kaks vaikeväärtust

Linuxis on iptables ja ip6tables eraldi tabelid eraldi poliitikatega. IPv4 tabeli INPUT- ja OUTPUT-ahelate seadmine DROP-ile ei muuda IPv6 tabelis midagi, kus vaikeväärtus on tavaliselt ACCEPT. Sama jaotus on ka nftablesis, kus saab uurida ühte perekonda ja avastada, et ainult üks neist kannab sinu reegleid. See asümmeetria on normaalne ja kogu probleem ongi selles.

Sellepärast võib hädalüliti tunduda põhjalik, käitudes osaliselt. Skript, mis IPv4 reeglid kirjutas, jooksis, loendurid kasvavad, logirida ilmub ja IPv6 pakett lahkub füüsilisest liidesest täiesti puutumata.

Loe, mida sinu klient tegelikult paigaldab, mitte mida turundusleht lubab. Mõned kliendid suunavad IPv6 tunneli, mõned blokeerivad selle meelega ja mõned jätavad selle rahule, samal ajal kui platvormitasandi lukustus rakendab teistsugust reeglit. Tootja dokumentatsioon on ainus allikas, mida siin usaldada tasub.

Mida ütleb sulle liidese konfiguratsioon

wg-quicki käsiraamatuleht sisaldab IPv6 reegleid oma näidiskonfiguratsioonis ja põhjus on täpselt see lünk. Näide pole kaunistus. See on olemas, sest ainult IPv4 reeglid jätaksid teise perekonna avatuks.

Poole näite kopeerimine annab poole poliitikast. See on selle lekke kõige tavalisem allikas. Blogipostitus kärpis näidet pikkuse tõttu. Seejärel sai kärbitud versioonist mall, mida kõik uuesti kasutasid.

# 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

Kui teine käsk väljastab lubava poliitika, samal ajal kui esimene väljastab DROP, oled vastuse leidnud ilma klienti puutumata. See asümmeetria ongi viga.

Miks ühest otsingust ei piisa

Üks nimi võib tagastada nii A-kirje kui ka AAAA-kirje ning rakendused ei vali kõik ühtemoodi. Brauser võib eelistada IPv6-te, kui võrk seda pakub, ja ebaõnnestumisel tagasi langeda, samal ajal kui taustasünkroonimine või uuendaja kasutab oma lahendajat ja oma eelistust. Seega tõestab üks edukas test IPv4 kaudu ühte teed, mitte poliitikat.

Võrguüleminekud muudavad vastust samuti. Teise Wi-Fi võrku liitumine, unest ärkamine või mobiilivõrku lülitumine võib anda seadmele uue IPv6 prefiksi ja kontori LAN-is piisavana tundunud poliitika ei pruugi seda katta.

Testi olekut, kus tunnel on maas

Ühendatud olekus testimine ütleb sulle, et tunnel töötab. Huvitav test on kättesaamatu olek, sest just siis peaks hädalüliti pidama. Peata tunnel meelega ja proovi seejärel olulisi sihtkohti rakendusest, mida kaitstud.

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

Mõlemad perekonnad peaksid sulgunult ebaõnnestuma. Kui IPv4 päring aegub ja IPv6 päring tagastab olekukoodi, on poliitika puudulik ja ükski tunneli kordustestimine ei muuda seda.

Hoia selles testis ka dokumenteeritud erandeid. Kohaliku võrgu avastamine, DHCP uuendamine või alglaadimistee VPN-i lõpp-punkti võib vajada kättesaadavaks jäämist ja need erandid tuleks poliitikas nimetada, mitte katkestuse ajal avastada. Lekketest, mis ebaõnnestub, sest tunnel ei saa tagasi tulla, ei ole turvalisuse leid, vaid ühenduvuse leid.