Kill switch na ruteru koji pokriva FORWARD, OUTPUT i IPv6

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

Počnite od rutera, a ne od laptopa

Politika na nivou rutera privlačna je za mali ured jer svaki uređaj iza njega nasljeđuje isto ponašanje i niko ne može zaboraviti da uključi prekidač na klijentu. Ona vam daje i jedno mjesto za testiranje nakon svakog ažuriranja firmvera. Ono što vam ne daje jest automatska pokrivenost ruterovog vlastitog saobraćaja ili druge adresne familije, a to su dva jaza iza većine neuspjelih implementacija.

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

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

Saobraćaj sa laptopa na internet se prosljeđuje, pa prolazi kroz FORWARD lanac. Saobraćaj koji ruter sam generiše, kao što su DNS prosljeđivanje, NTP upiti, DDNS ažuriranja i VPN kontrolni kanal, prolazi kroz OUTPUT. Upravljački saobraćaj upućen ruteru dolazi kroz INPUT.

Kill switch izgrađen samo u FORWARD-u zato štiti klijente i ništa drugo. Tabela 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. U suprotnom, prvi put kada VPN otkaže, vozite se u ured sa konzolnim kablom.

Poredajte pravila tako da tunel ipak može da se podigne

Ispravan kill switch je lista dozvola koja završava odbijanjem, a redoslijed je ono što ga čini kill switchom umjesto ciglom. Prvo dozvolite loopback, VPN endpoint, odgovore za uspostavljene tokove i tunelski interfejs; 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

Endpoint u ovoj tački mora biti adresa, a ne ime hosta. Kada završno odbijanje blokira DNS, pravilo koje navodi ime hosta provajdera više se ne može razriješiti i tunel nikada više ne starta nakon ponovnog pokretanja. Ako provajder mijenja endpointe, razriješite ime prije nego što se politika primijeni i osvježite to pravilo iz iste skripte.

Preslikajte oblik u FORWARD-u za klijentski saobraćaj i postavite eksplicitno 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 tokom promjene kill switcha dovoljno je često da se planira. Na ruteru sa WireGuardom, allowed-ips peera odlučuje šta ulazi u tunel, dok ova pravila odlučuju šta 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 direktnu rutu do interneta koju vaša nova pravila nikada ne vide. Laptop sa dual-stack će je rado preferirati, a kill switch će izgledati pokvaren samo osobi koja testira sa 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: dozvola za loopback mora doći prije odbijanja WAN-a, inače lokalne usluge na ruteru počinju čudno da otkazuju. Ako mreža uopšte ne koristi IPv6, isključivanje na WAN-u i LAN-u je jednostavnije 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 tabelu rutiranja nakon što se tunel poveže, umjesto da pretpostavite da je klijent to riješio.

Dokažite to sa spuštenim tunelom

Zaustavite tunel sa rutera i testirajte sa 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 vam kaže kuda bi paket otišao, a brojači kažu da li su vaša pravila ikada pogodila. Pravilo sa nula paketa nakon neuspjelog testa ništa ne štiti, a uobičajen uzrok je naziv interfejsa koji se razlikuje od onog koji ste otkucali. Testirajte saobraćaj koji generiše ruter eksplicitno, jer test sa LAN strane ne može aktivirati OUTPUT.

Odlučite o režimu kvara prije nego što vam zatreba. Fail-closed drži klijente offline dok se tunel ne vrati; fail-open vraća običan WAN pristup i promašuje svrhu za saobraćaj koji vam je bio važan. Blackhole ruta do VPN pula sa visokom metrikom korisna je drugi sloj za fail-closed dizajne, jer preživljava kada tunelska ruta nestane, umjesto da se vrati na zadanu.

Prihvatite postavku samo kada LAN klijent, zahtjev koji generiše ruter i IPv6 zahtjev svi otkažu sa spuštenim tunelom, i sva tri ponovo rade kada se podigne.