Prekidač veze blokira samo IPv4: zašto IPv6 ipak izlazi

Tunel padne, prekidač veze prijavi da se aktivirao, a preuzimanje se nastavlja. Ništa nije pokvareno u pravilima za IPv4. Aplikacija se jednostavno premjestila na put za koji ta pravila nikada nisu napisana.

Dual-stack uređaji imaju dva nezavisna izlaza. Blokada jednog od njih je pola blokade.

Dva skupa pravila, dva podrazumijevana stanja

Na Linuxu su iptables i ip6tables odvojene tabele s odvojenim politikama. Postavljanje lanaca INPUT i OUTPUT IPv4 tabele na DROP ne mijenja ništa u IPv6 tabeli, gdje je podrazumijevana vrijednost obično ACCEPT. Ista podjela postoji u nftablesu, gdje možete pregledati jednu porodicu i otkriti da samo jedna od njih nosi vaša pravila. Ta asimetrija je normalna i cijeli problem je upravo u njoj.

Zato prekidač veze može izgledati temeljit, a djelovati djelimično. Skripta koja je napisala pravila za IPv4 se izvršila, brojači rastu, linija u dnevniku se pojavljuje, a IPv6 paket izlazi kroz fizički interfejs potpuno netaknut.

Čitajte šta vaš klijent zaista instalira, a ne šta obećava marketinška stranica. Neki klijenti usmjeravaju IPv6 u tunel, neki ga namjerno blokiraju, a neki ga ostavljaju na miru dok zaključavanje na nivou platforme primjenjuje drugo pravilo. Dokumentacija proizvođača jedini je izvor kojem se ovdje vrijedi povjeriti.

Šta vam govori konfiguracija interfejsa

Stranica priručnika za wg-quick uključuje IPv6 pravila u svojoj primjer konfiguraciji, a razlog je upravo ta praznina. Primjer nije ukras. Postoji zato što bi samo IPv4 pravila ostavila drugu porodicu otvorenom.

Kopiranje pola primjera daje pola politike. To je najčešće porijeklo ovog curenja. Objava na blogu skratila je primjer zbog dužine. Skraćena verzija tada je postala šablon koji su svi ponovno koristili.

# 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

Ako druga naredba ispisuje dopuštajuću politiku, a prva ispisuje DROP, našli ste odgovor bez diranja klijenta. Ta asimetrija je greška.

Zašto jedan upit nije cijela priča

Jedno ime može vratiti i A zapis i AAAA zapis, a aplikacije ne biraju sve na isti način. Preglednik može preferirati IPv6 kada ga mreža nudi i vratiti se pri neuspjehu, dok pozadinska sinhronizacija ili program za ažuriranje koristi vlastiti razrješivač i vlastito opredjeljenje. Zato jedan uspješan test preko IPv4 dokazuje jedan put, a ne politiku.

Mrežni prelazi također mijenjaju odgovor. Pridruživanje drugoj Wi-Fi mreži, buđenje iz sna ili prelazak na mobilnu mrežu može uređaju dati novi IPv6 prefiks, a politika koja se činila dovoljnom na kancelarijskom LAN-u možda ga ne pokriva.

Testirajte stanje u kojem je tunel isključen

Testiranje dok ste povezani govori vam da tunel radi. Zanimljiv test je nedostupno stanje, jer tada prekidač veze treba da izdrži. Namjerno zaustavite tunel, zatim isprobajte važne odredišne tačke iz aplikacije koju štitite.

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

Obje porodice treba da padnu zatvoreno. Ako IPv4 zahtjev istekne, a IPv6 zahtjev vrati statusni kod, politika je nepotpuna i nikakvo ponovno testiranje tunela to neće promijeniti.

Zadržite dokumentovane izuzetke i u tom testu. Otkrivanje lokalne mreže, obnavljanje DHCP-a ili put za podizanje do VPN krajnje tačke mogu trebati ostati dostupni, a ti izuzeci treba da budu navedeni u politici, a ne otkriveni tokom prekida. Test curenja koji ne uspije zato što se tunel ne može vratiti nije sigurnosni nalaz, to je nalaz o povezanosti.