Kill switch sur la enkurservilo, kiu kovras FORWARD, OUTPUT kaj IPv6

Vi ensalutas la enkurservilon, algluas regularon pri kill switch el forumafiŝo, kaj la LAN ĉesas retumi en la momento, kiam la tunelo falas. Du tagojn poste la enkurservilo ankoraŭ ĝisdatigas sian dinamikan DNS-rikordon per la ordinara WAN, kaj la gasttekkomputilo ankoraŭ atingas IPv6-retejojn. Ambaŭ kondutoj estas normalaj, ĉar la algluitaj reguloj kovris unu ĉenon kaj unu adresfamilion, kaj neniu el ili estas la tuta enkurservilo. Trapasi la pakojn laŭ iliaj vojoj en ordo montras precize, kio estis preterlasita.

Komencu ĉe la enkurservilo, ne ĉe la tekkomputilo

Politiko sur enkurservila nivelo estas alloga por malgranda oficejo, ĉar ĉiu aparato malantaŭ ĝi heredas la saman konduton kaj neniu povas forgesi ŝalti klientan ŝaltilon. Ĝi ankaŭ donas al vi unu lokon por testi post ĉiu firmvara ĝisdatigo. Kion ĝi ne donas, estas aŭtomata kovrado de la propra trafiko de la enkurservilo aŭ de dua adresfamilio, kaj tiuj estas la du breĉoj malantaŭ plej multaj malsukcesintaj starigoj.

Antaŭ ol vi redaktos ion, notu tri faktojn sur papero: la nomon de la WAN-interfaco, la nomon de la LAN-ponto, kaj la adreson kaj pordon de la VPN-finpunkto. Vi bezonos ĉiujn tri en la reguloj, kaj diveni interfacajn nomojn estas la plej ofta kaŭzo, ke regula aro, kiu aspektas ĝuste, faras nenion.

Trapasu la tri vojojn, kiujn paketo povas preni

Trafiko de tekkomputilo al la interreto estas plusendita, do ĝi pasas tra la ĉeno FORWARD. Trafiko, kiun la enkurservilo mem generas, ekzemple DNS-plusendado, NTP-demandoj, DDNS-ĝisdatigoj kaj la VPN-kontrolkanalo, pasas tra OUTPUT. Administra trafiko adresita al la enkurservilo alvenas tra INPUT.

Kill switch konstruita nur en FORWARD do protektas klientojn kaj nenion alian. La tabelo montras, kial la liko en la malferma sceno estas antaŭvidebla, ne mistera.

En plej multaj dizajnoj vi ne bezonas kill switch sur INPUT, sed vi devas teni administran aliron funkcianta dum la tunelo estas mallevita. Alie, la unuan fojon kiam la VPN fiaskas, vi veturos al la oficejo kun konsola kablo.

Ordigi la regulojn tiel, ke la tunelo ankoraŭ povu ekleviĝi

Funkcianta kill switch estas listo de permesoj, kiu finiĝas per malakcepto, kaj la ordo faras ĝin kill switch anstataŭ briko. Unue permesu loopback, la VPN-finpunkton, respondojn por establitaj fluoj kaj la tunelan interfacon; malakceptu la ceteron laste.

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

La finpunkto devas esti adreso ĉe ĉi tiu punkto, ne gastignomo. Post kiam la fina malakcepto blokas DNS, regulo, kiu nomas la gastignomon de la provizanto, ne plu povas esti solvita, kaj la tunelo neniam relanĉiĝas post restartigo. Se la provizanto rotacias finpunktojn, solvu la nomon antaŭ ol la politiko aplikiĝos kaj refreŝigu tiun regulon el la sama skripto.

Spegulu la formon en FORWARD por klienta trafiko, kaj metu eksplicitan administran regulon super la malakcepto. Tenu tiun administran regulon mallarĝa sed atingebla, kaj konfirmu ĝin per malfermo de dua SSH-sesio antaŭ ol vi fermas la unuan. Sin ŝlosi dum ŝanĝo de kill switch estas sufiĉe ofta por plani ĝin. Sur enkurservilo kun WireGuard, la allowed-ips de la pairulo decidas, kio eniras la tunelon, dum ĉi tiuj reguloj decidas, kio rajtas eliri sen ĝi.

IPv6 bezonas sian propran pordon

Ĉio supre estas IPv4. Se via LAN havas funkciantan IPv6 kaj la tunelo portas nur IPv4, ĉiu kovrita aparato ankoraŭ havas rektan vojon al la interreto, kiun viaj novaj reguloj neniam vidas. Dulstaka tekkomputilo volonte preferos ĝin, kaj la kill switch aspektos rompita nur al la persono, kiu testas per IPv4.

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

Ankaŭ ĉi tie la ordo gravas: la loopback-permeso devas antaŭi la WAN-malakcepton, alie lokaj servoj sur la enkurservilo komencas malsukcesi strange. Se la reto tute ne uzas IPv6, malŝalti ĝin sur WAN kaj LAN estas pli simple kaj lasas nenion forgeseblan.

Kelkaj VPN-klientoj instalas defaŭltan vojon nur por IPv4 kaj lasas la ekzistantan IPv6-defaŭlton netuŝita. Kontrolu la enkurservilan tabelon post kiam la tunelo konektiĝas, anstataŭ supozi, ke la kliento traktis ĝin.

Pruvu ĝin kun la tunelo mallevita

Haltigu la tunelon de la enkurservilo kaj testu el tri lokoj en ĉi tiu ordo:

# 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

La voja serĉo diras al vi, kien paketo irus, kaj la nombriloj diras al vi, ĉu viaj reguloj iam ajn kongruis. Regulo kun nula pakoj post malsukcesa testo protektas nenion, kaj la kutima kaŭzo estas interfaca nomo, kiu diferencas de tiu, kiun vi tajpis. Testu eksplicite la trafikon generitan de la enkurservilo, ĉar testo de la LAN-flanko ne povas ekzerci OUTPUT.

Decidu la fiaskan reĝimon antaŭ ol vi bezonos ĝin. Fail-closed tenas klientojn eksterrete ĝis la tunelo revenos; fail-open restarigas ordinaran WAN-aliron kaj vanigas la celon por la trafiko, pri kiu vi zorgis. Blackhole-vojo al la VPN-pool kun alta metriko estas utila dua tavolo por fail-closed-dizajnoj, ĉar ĝi pluvivas, kiam la tunela vojo malaperas, anstataŭ reiri al la defaŭlta.

Akceptu la agordon nur kiam LAN-kliento, de la enkurservilo generita peto kaj IPv6-peto ĉiuj malsukcesas kun la tunelo mallevita, kaj ĉiuj tri denove funkcias, kiam ĝi estas supren.