Ruuteri kill switch, mis katab FORWARD-i, OUTPUT-i ja IPv6

Logite ruuterisse sisse, kleepite foorumipostitusest kill switchi reeglistiku ja LAN lõpetab sirvimise hetkel, kui tunnel maha kukub. Kaks päeva hiljem uuendab ruuter endiselt oma dünaamilist DNS-kirjet tavalise WAN-i kaudu ja külalisarvuti jõuab endiselt IPv6-saitidele. Mõlemad käitumised on normaalsed, sest kleebitud reeglid katsid ühte ahelat ja ühte aadressiperekonda ning kumbki neist ei ole kogu ruuter. Pakettide teede järjekorras läbikäimine näitab täpselt, mis vahele jäi.

Alustage ruuterist, mitte sülearvutist

Ruuteri tasandi poliitika on väikekontorile atraktiivne, sest iga seade selle taga pärib sama käitumise ja keegi ei saa unustada kliendi lüliti sisselülitamist. See annab ka ühe koha testimiseks pärast iga püsivara uuendust. Mida see ei anna, on ruuteri enda liikluse või teise aadressiperekonna automaatne katvus, ja need on kaks lünka enamiku ebaõnnestunud juurutuste taga.

Enne millegi muutmist pange paberile kolm fakti: WAN-liidese nimi, LAN-silla nimi ning VPN-i lõpp-punkti aadress ja port. Teil läheb neid kõiki kolme reeglites vaja, ja liidesenimede oletamine on kõige tavalisem põhjus, miks õigesti näiv reeglistik ei tee midagi.

Käige läbi kolm teed, mida pakett võib võtta

Liiklus sülearvutist internetti suunatakse edasi, seega läbib see FORWARD-ahelat. Liiklus, mida ruuter ise genereerib, näiteks DNS-i edasisuunamine, NTP-päringud, DDNS-i uuendused ja VPN-i juhtkanal, läbib OUTPUT-i. Ruuterile adresseeritud haldusliiklus saabub INPUT-i kaudu.

Ainult FORWARD-i ehitatud kill switch kaitseb seega kliente ja mitte midagi muud. Tabel näitab, miks avastseenist pärit leke on ettearvatav, mitte müstiline.

Enamikus kavandites ei ole teil INPUT-il kill switchi vaja, kuid haldusjuurdepääs peab töötama ka siis, kui tunnel on maas. Vastasel juhul sõidate esimesel VPN-i rikke korral kontorisse konsoolikaabliga.

Järjestage reeglid nii, et tunnel saaks ikka üles tulla

Toimiv kill switch on lubade loend, mis lõpeb tagasilükkamisega, ja järjekord teeb sellest kill switchi, mitte telliskivi. Lubage esmalt loopback, VPN-i lõpp-punkt, olemasolevate voogude vastused ja tunneliliides; lükake ülejäänu viimasena tagasi.

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

Lõpp-punkt peab siinkohal olema aadress, mitte hostinimi. Kui lõplik tagasilükkamine blokeerib DNS-i, ei saa enam lahendada reeglit, mis nimetab teenusepakkuja hostinime, ja tunnel ei käivitu pärast taaskäivitust enam kunagi. Kui pakkuja pöörab lõpp-punkte, lahendage nimi enne poliitika rakendamist ja värskendage seda reeglit samast skriptist.

Peegeldage kuju FORWARD-is kliendiliikluse jaoks ja asetage tagasilükkamise kohale selgesõnaline haldusreegel. Hoidke see haldusreegel kitsas, kuid kättesaadav, ja kinnitage see teise SSH-sessiooni avamisega enne, kui sulgete esimese. Enda väljalülitamine kill switchi muutmise ajal on piisavalt tavaline, et sellega arvestada. WireGuardiga ruuteril otsustavad peersõlme allowed-ips väärtused, mis tunnelisse siseneb, samas kui need reeglid otsustavad, mis tohib ilma selleta välja minna.

IPv6 vajab oma ust

Kõik ülal on IPv4. Kui teie LAN-is töötab IPv6 ja tunnel kannab ainult IPv4, on igal kaetud seadmel endiselt otsene marsruut internetti, mida teie uued reeglid kunagi ei näe. Kahe virnaga sülearvuti eelistab seda hea meelega ja kill switch näib katki ainult sellele, kes testib IPv4-ga.

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

Ka siin loeb järjekord: loopbacki luba peab tulema enne WAN-i tagasilükkamist, muidu hakkavad ruuteri kohalikud teenused kummaliselt ebaõnnestuma. Kui võrk IPv6-t üldse ei kasuta, on selle WAN-is ja LAN-is väljalülitamine lihtsam ja midagi ei jää unustada.

Mõned VPN-kliendid paigaldavad vaikemarsruudi ainult IPv4 jaoks ja jätavad olemasoleva IPv6 vaikemarsruudi puutumata. Kontrollige marsruutimistabelit pärast tunneliga ühenduse loomist, selle asemel et eeldada, et klient sellega hakkama sai.

Tõestage seda tunneliga maas

Peatage tunnel ruuterist ja testige kolmest kohast selles järjekorras:

# 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

Marsruudiotsing ütleb, kuhu pakett läheks, ja loendurid ütlevad, kas teie reeglid üldse kunagi tabasid. Nullipaketiga reegel pärast ebaõnnestunud testi ei kaitse midagi ja tavaline põhjus on liidese nimi, mis erineb sellest, mille te trükkisite. Testige ruuteri genereeritud liiklust selgesõnaliselt, sest LAN-i poolelt tehtud test ei saa OUTPUT-i rakendada.

Otsustage rikkerežiim enne, kui seda vajate. Fail-closed hoiab kliendid võrguühenduseta, kuni tunnel naaseb; fail-open taastab tavalise WAN-juurdepääsu ja nurjab eesmärgi liikluse puhul, millest hoolisite. Suure mõõdikuga blackhole-marsruut VPN-i pooli on kasulik teine kiht fail-closed-kavandite jaoks, kuna see jääb püsima, kui tunnelimarsruut kaob, selle asemel et langeda tagasi vaikemarsruudile.

Nõustuge seadistusega alles siis, kui LAN-i klient, ruuteri genereeritud päring ja IPv6-päring kõik ebaõnnestuvad tunneliga maas ning kõik kolm töötavad taas, kui tunnel on üles.