Kill switch na usmerjevalniku, ki pokriva FORWARD, OUTPUT in IPv6

Prijavite se v usmerjevalnik, prilepite nabor pravil kill switch iz forumske objave in LAN preneha brskati v trenutku, ko tunel pade. Dva dni pozneje usmerjevalnik še vedno posodablja svoj dinamični zapis DNS prek običajnega WAN-a, gostujoči prenosnik pa še vedno doseže strani IPv6. Obe vedenji sta običajni, ker so prilepljena pravila pokrivala eno verigo in eno družino naslovov, in nobeno od tega ni cel usmerjevalnik. Pregled poti paketov po vrsti pokaže natanko, kaj je bilo izpuščeno.

Začnite pri usmerjevalniku, ne pri prenosniku

Politika na ravni usmerjevalnika je privlačna za majhno pisarno, ker vsaka naprava za njim podeduje enako vedenje in nihče ne more pozabiti vklopiti stikala na odjemalcu. Daje vam tudi eno mesto za preizkušanje po vsaki posodobitvi vdelane programske opreme. Česar pa ne daje, je samodejno pokrivanje lastnega prometa usmerjevalnika ali druge družine naslovov, in to sta dve vrzeli za večino neuspešnih uvedb.

Preden karkoli spremenite, zapišite tri podatke na papir: ime vmesnika WAN, ime mostu LAN ter naslov in vrata končne točke VPN. Vse tri boste potrebovali v pravilih, ugibanje imen vmesnikov pa je najpogostejši razlog, da nabor pravil, ki izgleda pravilno, ne naredi ničesar.

Prehodite tri poti, ki jih lahko ubere paket

Promet s prenosnika v internet se posreduje, zato gre skozi verigo FORWARD. Promet, ki ga ustvari usmerjevalnik sam, na primer posredovanje DNS, poizvedbe NTP, posodobitve DDNS in nadzorni kanal VPN, gre skozi OUTPUT. Upravljavski promet, naslovljen na usmerjevalnik, prihaja skozi INPUT.

Kill switch, zgrajen samo v FORWARD, torej ščiti odjemalce in nič drugega. Tabela pokaže, zakaj je uhajanje iz uvodnega prizora predvidljivo in ne skrivnostno.

V večini zasnov ne potrebujete kill switcha na INPUT, morate pa ohraniti delujoč upravljavski dostop, medtem ko je tunel spuščen. Sicer se ob prvi okvari VPN odpeljete v pisarno s konzolnim kablom.

Uredite pravila tako, da se tunel še lahko dvigne

Delujoč kill switch je seznam dovoljenj, ki se konča z zavrnitvijo, in vrstni red je tisto, kar ga naredi kill switch namesto opeke. Najprej dovolite loopback, končno točko VPN, odgovore za vzpostavljene tokove in vmesnik tunela; ostalo zavrnite nazadnje.

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

Končna točka mora na tej točki biti naslov, ne ime gostitelja. Ko končna zavrnitev blokira DNS, pravila, ki navaja ime gostitelja ponudnika, ni več mogoče razrešiti, in tunel se po ponovnem zagonu nikoli več ne zažene. Če ponudnik menjava končne točke, razrešite ime, preden se politika uporabi, in osvežite to pravilo iz iste skripte.

Zrcalite obliko v FORWARD za promet odjemalcev in postavite izrecno upravljavsko pravilo nad zavrnitvijo. To upravljavsko pravilo naj bo ozko, a dosegljivo, in ga potrdite tako, da odprete drugo sejo SSH, preden zaprete prvo. Zaklepanje sebe med spremembo kill switcha je dovolj pogosto, da ga načrtujete. Na usmerjevalniku z WireGuardom allowed-ips partnerja odločajo, kaj vstopi v tunel, medtem ko ta pravila odločajo, kaj sme oditi brez njega.

IPv6 potrebuje svoja vrata

Vse zgoraj je IPv4. Če ima vaš LAN delujoč IPv6 in tunel prenaša samo IPv4, ima vsaka pokrita naprava še vedno neposredno pot v internet, ki je vaša nova pravila nikoli ne vidijo. Prenosnik z dvojnim skladom jo bo z veseljem izbral, kill switch pa bo videti pokvarjen le tistemu, ki preizkuša z IPv4.

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

Tudi tukaj je vrstni red pomemben: dovoljenje za loopback mora priti pred zavrnitvijo WAN, sicer lokalne storitve na usmerjevalniku začnejo čudno odpovedovati. Če omrežje sploh ne uporablja IPv6, je izklop na WAN in LAN preprostejši in ne pušča ničesar pozabljenega.

Nekateri odjemalci VPN namestijo privzeto pot samo za IPv4 in pustijo obstoječo privzeto pot IPv6 nedotaknjeno. Preverite usmerjevalno tabelo, potem ko se tunel poveže, namesto da predpostavljate, da je odjemalec to uredil.

Dokažite to s spuštenim tunelom

Ustavite tunel z usmerjevalnika in preizkusite s treh mest v tem vrstnem 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

Iskanje poti vam pove, kam bi paket šel, števci pa, ali so vaša pravila kdaj zadela. Pravilo z nič paketi po neuspešnem preizkusu ne ščiti ničesar, običajen vzrok pa je ime vmesnika, ki se razlikuje od vpisanega. Izrecno preizkusite promet, ki ga ustvari usmerjevalnik, ker preizkus s strani LAN ne more izvajati OUTPUT.

Odločite se o načinu okvare, preden ga potrebujete. Fail-closed ohrani odjemalce brez povezave, dokler se tunel ne vrne; fail-open obnovi običajen dostop do WAN in izniči namen za promet, ki vam je bil pomemben. Blackhole pot do bazena VPN z visoko metriko je koristen drugi sloj za zasnove fail-closed, saj preživi, ko pot tunela izgine, namesto da bi se vrnila na privzeto.

Nastavitev sprejmite šele, ko odjemalec v LAN, zahteva, ki jo ustvari usmerjevalnik, in zahteva IPv6 vsi spodletijo s spuštenim tunelom, in vsi trije spet delujejo, ko se dvigne.