Reitittimen kill switch, joka kattaa FORWARDin, OUTPUTin ja IPv6:n

Kirjaudut reitittimeen, liität foorumiviestistä kill switch -sääntösarjan, ja LAN lakannee selaamasta heti, kun tunneli putoaa. Kaksi päivää myöhemmin reititin päivittää yhä dynaamista DNS-tietuettaan tavallisen WANin kautta, ja vieraskannettava saavuttaa yhä IPv6-sivustoja. Molemmat käyttäytymiset ovat normaaleja, koska liitetyt säännöt kattoivat yhden ketjun ja yhden osoiteperheen, eikä kumpikaan niistä ole koko reititin. Pakettien polkujen läpikäynti järjestyksessä näyttää tarkalleen, mikä jäi pois.

Aloita reitittimestä, älä kannettavasta

Reititintason käytäntö on houkutteleva pienelle toimistolle, koska jokainen sen takana oleva laite perii saman käyttäytymisen eikä kukaan voi unohtaa kytkeä asiakasohjelman kytkintä päälle. Se antaa myös yhden paikan testata jokaisen firmware-päivityksen jälkeen. Mitä se ei anna, on automaattinen kattavuus reitittimen omasta liikenteestä tai toisesta osoiteperheestä, ja ne ovat kaksi aukkoa useimpien epäonnistuneiden käyttöönottojen takana.

Ennen kuin muutat mitään, kirjoita kolme asiaa paperille: WAN-liittymän nimi, LAN-sillan nimi sekä VPN-päätepisteen osoite ja portti. Tarvitset kaikki kolme säännöissä, ja liittymien nimien arvaaminen on yleisin syy siihen, ettei oikealta näyttävä sääntösarja tee mitään.

Käy läpi kolme polkua, jotka paketti voi ottaa

Liikenne kannettavasta internetiin välitetään eteenpäin, joten se kulkee FORWARD-ketjun läpi. Liikenne, jonka reititin itse tuottaa, kuten DNS-edelleenvälitys, NTP-kyselyt, DDNS-päivitykset ja VPN:n ohjauskanava, kulkee OUTPUTin läpi. Reitittimelle osoitettu hallintaliikenne saapuu INPUTin kautta.

Vain FORWARDiin rakennettu kill switch suojaa siis asiakkaita eikä mitään muuta. Taulukko näyttää, miksi alkukohtauksen vuoto on ennustettavissa eikä mystistä.

Useimmissa suunnitelmissa et tarvitse kill switchiä INPUTiin, mutta hallintayhteyden on pysyttävä toiminnassa, kun tunneli on alhaalla. Muuten ajat toimistolle konsolikaapelin kanssa ensimmäisellä VPN-vikakerralla.

Järjestä säännöt niin, että tunneli voi yhä nousta

Toimiva kill switch on sallittujen luettelo, joka päättyy hylkäykseen, ja järjestys tekee siitä kill switchin eikä tiiliskiven. Salli ensin loopback, VPN-päätepiste, vakiintuneiden virtojen vastaukset ja tunneliliittymä; hylkää loput viimeiseksi.

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

Päätepisteen on oltava tässä kohdassa osoite, ei isäntänimi. Kun lopullinen hylkäys estää DNS:n, sääntöä, joka nimeää palveluntarjoajan isäntänimen, ei enää voi ratkaista, ja tunneli ei käynnisty enää koskaan uudelleenkäynnistyksen jälkeen. Jos palveluntarjoaja vaihtaa päätepisteitä, ratkaise nimi ennen käytännön soveltamista ja päivitä kyseinen sääntö samasta skriptistä.

Toista muoto FORWARDissa asiakasliikenteelle ja aseta selkeä hallintasääntö hylkäyksen yläpuolelle. Pidä hallintasääntö kapeana mutta saavutettavana ja vahvista se avaamalla toinen SSH-istunto ennen kuin suljet ensimmäisen. Itsensä ulos lukitseminen kill switchin muutoksen aikana on riittävän yleistä suunniteltavaksi. WireGuardia ajavassa reitittimessä vertaislaitteen allowed-ips määrittää, mikä tulee tunneliin, kun taas nämä säännöt määrittävät, mikä saa lähteä ilman sitä.

IPv6 tarvitsee oman etuoven

Kaikki edellä on IPv4:tä. Jos LANissasi on toimiva IPv6 ja tunneli kuljettaa vain IPv4:tä, jokaisella katetulla laitteella on yhä suora reitti internetiin, jota uudet sääntösi eivät koskaan näe. Kaksoispinon kannettava suosii sitä mielellään, ja kill switch näyttää rikkinäiseltä vain siltä, joka testaa IPv4:llä.

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

Tässäkin järjestys ratkaisee: loopbackin sallinta on ennen WANin hylkäystä, muuten reitittimen paikalliset palvelut alkavat epäonnistua oudolla tavalla. Jos verkko ei käytä IPv6:ta lainkaan, sen poistaminen käytöstä WANissa ja LANissa on yksinkertaisempaa eikä mitään jää unohdettavaksi.

Jotkin VPN-asiakasohjelmat asentavat oletusreitin vain IPv4:lle ja jättävät olemassa olevan IPv6-oletusreitin koskemattomaksi. Tarkista reititystaulukko sen jälkeen, kun tunneli on yhdistetty, sen sijaan että olettaisit asiakasohjelman hoitaneen sen.

Todista se tunneli alhaalla

Pysäytä tunneli reitittimestä ja testaa kolmesta paikasta tässä järjestyksessä:

# 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

Reittihakku kertoo, minne paketti menisi, ja laskurit kertovat, osuivatko sääntösi koskaan. Nollan paketin sääntö epäonnistuneen testin jälkeen ei suojaa mitään, ja tavallinen syy on liittymän nimi, joka poikkeaa kirjoittamastasi. Testaa reitittimen tuottama liikenne nimenomaisesti, koska LANin puolelta tehty testi ei voi käyttää OUTPUTia.

Päätä vikatila ennen kuin tarvitset sitä. Fail-closed pitää asiakkaat offline-tilassa, kunnes tunneli palaa; fail-open palauttaa tavallisen WAN-yhteyden ja vesittää tarkoituksen siltä liikenteeltä, josta välitit. Korkean metrijärjestyksen blackhole-reitti VPN-pooliin on hyödyllinen toinen kerros fail-closed-suunnitelmissa, koska se säilyy, kun tunnelireitti katoaa, sen sijaan että putoaisi oletusreitille.

Hyväksy asetelma vasta, kun LAN-asiakasohjelma, reitittimen tuottama pyyntö ja IPv6-pyyntö kaikki epäonnistuvat tunnelin ollessa alhaalla, ja kaikki kolme toimivat taas, kun se on ylhäällä.