Kill switch na usmjerivaču koji pokriva FORWARD, OUTPUT i IPv6

Prijavite se na usmjerivač, zalijepite skup kill-switch pravila s forumske objave i LAN prestaje pregledavati onog trenutka kada tunel padne. Dva dana kasnije usmjerivač još uvijek ažurira svoj dinamički DNS zapis preko običnog WAN-a, a gostujući prijenosnik još uvijek doseže IPv6 stranice. Oba su ponašanja normalna, jer su zalijepljena pravila pokrivala jedan lanac i jednu adresnu obitelj, a nijedno od toga nije cijeli usmjerivač. Prolazak kroz putanje paketa po redu pokazuje točno što je propušteno.

Počnite od usmjerivača, a ne od prijenosnika

Politika na razini usmjerivača privlačna je za mali ured jer svaki uređaj iza njega nasljeđuje isto ponašanje i nitko ne može zaboraviti uključiti prekidač na klijentu. Daje vam i jedno mjesto za testiranje nakon svakog ažuriranja firmvera. Ono što vam ne daje jest automatska pokrivenost usmjerivačevog vlastitog prometa ili druge adresne obitelji, a to su dva jaza iza većine neuspjelih implementacija.

Prije nego što bilo što uredite, zapišite tri činjenice na papir: naziv WAN sučelja, naziv LAN mosta te adresu i port VPN završne točke. Sva tri će vam trebati u pravilima, a pogađanje naziva sučelja najčešći je razlog zašto skup pravila koji izgleda ispravno ne čini ništa.

Prođite kroz tri puta koja paket može uzeti

Promet s prijenosnika na internet prosljeđuje se, pa prolazi kroz FORWARD lanac. Promet koji usmjerivač sam generira, poput prosljeđivanja DNS-a, NTP upita, DDNS ažuriranja i VPN kontrolnog kanala, prolazi kroz OUTPUT. Upravljački promet upućen usmjerivaču dolazi kroz INPUT.

Kill switch izgrađen samo u FORWARD-u zato štiti klijente i ništa drugo. Tablica pokazuje zašto je curenje iz uvodne scene predvidivo, a ne tajanstveno.

U većini dizajna ne treba vam kill switch na INPUT-u, ali trebate održati upravljački pristup funkcionalnim dok je tunel spušten. Inače se pri prvom padu VPN-a vozite u ured s konzolnim kabelom.

Poredajte pravila tako da se tunel ipak može podići

Ispravan kill switch popis je dopuštenja koji završava odbijanjem, a redoslijed je ono što ga čini kill switchem umjesto ciglom. Prvo dopustite loopback, VPN završnu točku, odgovore za uspostavljene tokove i tunelsko sučelje; na kraju odbijte ostalo.

iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 51820 -j ACCEPT
iptables -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -o eth0 -j REJECT

Završna točka u ovoj točki mora biti adresa, a ne ime hosta. Kada završno odbijanje blokira DNS, pravilo koje navodi ime hosta pružatelja više se ne može razriješiti i tunel se nakon ponovnog pokretanja nikada više ne pokreće. Ako pružatelj mijenja završne točke, razriješite ime prije nego što se politika primijeni i osvježite to pravilo iz iste skripte.

Preslikajte oblik u FORWARD-u za promet klijenata i postavite izričito upravljačko pravilo iznad odbijanja. Držite to upravljačko pravilo uskim, ali dostupnim, i potvrdite ga otvaranjem druge SSH sesije prije nego što zatvorite prvu. Zaključavanje sebe tijekom promjene kill switcha dovoljno je često da se planira. Na usmjerivaču sa WireGuardom, allowed-ips para odlučuje što ulazi u tunel, dok ova pravila odlučuju što smije izaći bez njega.

IPv6 trebaju vlastita vrata

Sve gore je IPv4. Ako vaš LAN ima funkcionalan IPv6, a tunel prenosi samo IPv4, svaki pokriveni uređaj i dalje ima izravnu rutu do interneta koju vaša nova pravila nikada ne vide. Prijenosnik s dual-stack rado će je preferirati, a kill switch izgledat će pokvaren samo osobi koja testira s IPv4.

ip6tables -A FORWARD -i br-lan -j REJECT
ip6tables -A OUTPUT -o eth0 -j REJECT
ip6tables -A OUTPUT -o lo -j ACCEPT

Redoslijed je i ovdje važan: dopuštenje za loopback mora doći prije odbijanja WAN-a, inače lokalne usluge na usmjerivaču počinju čudno otkazivati. Ako mreža uopće ne koristi IPv6, isključivanje na WAN-u i LAN-u jednostavnije je i ne ostavlja ništa za zaboraviti.

Neki VPN klijenti instaliraju zadanu rutu samo za IPv4 i ostavljaju postojeću IPv6 zadanu rutu netaknutom. Provjerite tablicu usmjeravanja nakon što se tunel poveže, umjesto da pretpostavite da je klijent to riješio.

Dokažite to sa spuštenim tunelom

Zaustavite tunel s usmjerivača i testirajte s tri mjesta u ovom redu:

# systemctl stop wg-quick@wg0
# ip route get 203.0.113.1
# curl -m 5 -sS http://example.com || echo blocked
# iptables -vnL OUTPUT | head
# ip6tables -vnL OUTPUT | head

Pretraga rute kaže vam kamo bi paket otišao, a brojači kažu jesu li vaša pravila ikada pogodila. Pravilo s nula paketa nakon neuspjelog testa ništa ne štiti, a uobičajen uzrok je naziv sučelja koji se razlikuje od onoga koji ste upisali. Testirajte promet koji generira usmjerivač izričito, jer test s LAN strane ne može aktivirati OUTPUT.

Odlučite o načinu kvara prije nego što vam zatreba. Fail-closed drži klijente izvan mreže dok se tunel ne vrati; fail-open vraća običan WAN pristup i promašuje svrhu za promet koji vam je bio važan. Blackhole ruta do VPN pool-a s visokom metrikom koristan je drugi sloj za fail-closed dizajne, jer preživljava kada tunelska ruta nestane, umjesto da se vrati na zadanu.

Prihvatite postavku tek kada LAN klijent, zahtjev koji generira usmjerivač i IPv6 zahtjev svi ne uspiju sa spuštenim tunelom i sva tri ponovno rade kada se podigne.