A vészkapcsoló csak az IPv4-et blokkolja: miért szökik ki mégis az IPv6
Egy IPv4-es tűzfalszabály-készlet semmit sem mond az IPv6-ról. Kettős vermű eszközön az alagút megszakadhat, miközben egy alkalmazás működő útvonalat tart fenn körülötte.
Az alagút megszakad, a vészkapcsoló jelenti, hogy működésbe lépett, és egy letöltés tovább fut. Az IPv4-szabályokban semmi sem tört el. Az alkalmazás egyszerűen olyan útvonalra váltott, amelyre ezeket a szabályokat soha nem írták meg.
A kettős vermű eszközöknek két független kijáratuk van. Az egyik blokkolása fél blokkolás.
Két szabálykészlet, két alapértelmezés
Linuxon az iptables és az ip6tables külön táblák külön szabályzatokkal. Az IPv4-tábla INPUT és OUTPUT láncának DROP-ra állítása semmit sem változtat az IPv6-táblában, ahol az alapértelmezés általában ACCEPT. Ugyanez a felosztás létezik az nftablesben, ahol megvizsgálhat egy családot, és megállapíthatja, hogy csak az egyikük hordozza a szabályait. Ez az aszimmetria normális, és az egész probléma ez.
Ezért egy vészkapcsoló alaposnak tűnhet, és részlegesen viselkedhet. Az IPv4-szabályokat író szkript lefutott, a számlálók nőnek, a naplósor megjelenik, és egy IPv6-csomag teljesen érintetlenül hagyja el a fizikai interfészt.
Azt olvassa, mit telepít valójában az ügyfele, ne azt, amit a marketingoldal ígér. Egyes ügyfelek az IPv6-ot az alagútba irányítják, mások szándékosan blokkolják, megint mások békén hagyják, miközben egy platformszintű lezárás más szabályt érvényesít. Itt a gyártó dokumentációja az egyetlen forrás, amelyben érdemes megbízni.
Mit mond el az interfész konfigurációja
A wg-quick kézikönyvoldala IPv6-szabályokat tartalmaz a példakonfigurációjában, és az ok pontosan ez a hézag. A példa nem díszítés. Azért létezik, mert csak az IPv4-szabályok nyitva hagynák a második családot.
Egy példa felének lemásolása egy szabályzat felét eredményezi. Ez a szivárgás leggyakoribb eredete. Egy blogbejegyzés megrövidítette a példát a hossza miatt. A rövidített változat aztán az a sablon lett, amelyet mindenki újrahasznált.
# 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
Ha a második parancs engedélyező szabályzatot ír ki, miközben az első DROP-ot, megtalálta a választ anélkül, hogy hozzányúlna az ügyfélhez. Ez az aszimmetria a hiba.
Miért nem egyetlen lekérdezés a teljes történet
Egyetlen név egyszerre A-rekordot és AAAA-rekordot is visszaadhat, és nem minden alkalmazás választ ugyanúgy. A böngésző előnyben részesítheti az IPv6-ot, amikor a hálózat kínálja, és hiba esetén visszaeshet, míg egy háttérszinkronizálás vagy frissítő a saját feloldóját és saját preferenciáját használja. Egy sikeres IPv4-es teszt tehát egy útvonalat bizonyít, nem a szabályzatot.
A hálózati átmenetek is megváltoztatják a választ. Egy másik Wi-Fi-hálózathoz csatlakozás, az alvásból való felébredés vagy a mobilhálózatra váltás új IPv6-előtagot adhat az eszköznek, és az irodai LAN-on elegendőnek tűnő szabályzat lehet, hogy nem fedi le.
Tesztelje azt az állapotot, amikor az alagút le van állítva
A csatlakozva végzett teszt azt mondja, hogy az alagút működik. Az érdekes teszt az elérhetetlen állapot, mert akkor kell a vészkapcsolónak tartania. Állítsa le szándékosan az alagutat, majd próbálja ki a fontos célpontokat abból az alkalmazásból, amelyet véd.
# 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/
Mindkét családnak zártan kell meghiúsulnia. Ha az IPv4-kérés időtúllépésbe fut, és az IPv6-kérés állapotkódot ad vissza, a szabályzat hiányos, és az alagút bármennyi újratesztelése sem változtat ezen.
Tartsa meg a dokumentált kivételeket ebben a tesztben is. A helyi hálózatfelderítésnek, egy DHCP-megújításnak vagy a VPN-végpont felé vezető indítási útvonalnak elérhetőnek kell maradnia, és ezeket a kivételeket a szabályzatban kell megnevezni, nem pedig egy kiesés során felfedezni. Az a szivárgásteszt, amely azért hiúsul meg, mert az alagút nem tud újra feljönni, nem biztonsági lelet, hanem kapcsolódási lelet.