Kill switch na routeru, který pokrývá FORWARD, OUTPUT a IPv6

Přihlásíte se do routeru, vložíte sadu pravidel kill switch z příspěvku na fóru a LAN přestane prohlížet ve chvíli, kdy tunel spadne. O dva dny později router stále aktualizuje svůj záznam dynamického DNS přes běžné WAN a hostující notebook se stále dostane na stránky IPv6. Obě chování jsou normální, protože vložená pravidla pokrývala jeden řetězec a jednu adresní rodinu a ani jedno z toho není celý router. Projití cest paketů v pořadí přesně ukáže, co se vynechalo.

Začněte u routeru, ne u notebooku

Zásada na úrovni routeru je pro malou kancelář atraktivní, protože každé zařízení za ním zdědí stejné chování a nikdo nemůže zapomenout zapnout přepínač v klientovi. Dává vám také jedno místo k testování po každé aktualizaci firmwaru. Co vám nedává, je automatické pokrytí vlastního provozu routeru nebo druhé adresní rodiny, a to jsou dvě mezery za většinou neúspěšných nasazení.

Než cokoli upravíte, poznamenejte si na papír tři údaje: název rozhraní WAN, název mostu LAN a adresu a port koncového bodu VPN. Všechny tři budete v pravidlech potřebovat a hádání názvů rozhraní je nejčastějším důvodem, proč sada pravidel, která vypadá správně, nic nedělá.

Projděte tři cesty, kterými může paket jít

Provoz z notebooku do internetu se předává dál, takže prochází řetězcem FORWARD. Provoz, který generuje sám router, například přesměrování DNS, dotazy NTP, aktualizace DDNS a řídicí kanál VPN, prochází řetězcem OUTPUT. Řídicí provoz adresovaný routeru přichází přes INPUT.

Kill switch postavený jen ve FORWARD tedy chrání klienty a nic jiného. Tabulka ukazuje, proč je únik z úvodní scény předvídatelný, a ne záhadný.

Ve většině návrhů nepotřebujete kill switch na INPUT, ale musíte udržet funkční správcovský přístup, dokud je tunel dole. Jinak při prvním výpadku VPN jedete do kanceláře s konzolovým kabelem.

Seřaďte pravidla tak, aby se tunel ještě zvedl

Funkční kill switch je seznam povolení, který končí odmítnutím, a pořadí z něj dělá kill switch, a ne cihlu. Nejprve povolte loopback, koncový bod VPN, odpovědi pro navázané toky a rozhraní tunelu; zbytek odmítněte nakonec.

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

Koncový bod zde musí být adresa, ne název hostitele. Jakmile závěrečné odmítnutí zablokuje DNS, pravidlo, které uvádí název hostitele poskytovatele, už nelze přeložit, a tunel po restartu už nikdy nenaběhne. Pokud poskytovatel střídá koncové body, přeložte název dřív, než se zásada použije, a obnovujte to pravidlo ze stejného skriptu.

Zopakujte stejný tvar ve FORWARD pro provoz klientů a umístěte explicitní správcovské pravidlo nad odmítnutí. Držte toto správcovské pravidlo úzké, ale dostupné, a potvrďte ho otevřením druhé SSH relace, než zavřete první. Zamknout se během změny kill switch je dost běžné na to, aby se s tím počítalo. Na routeru s WireGuardem rozhodují allowed-ips protějšku o tom, co vstoupí do tunelu, zatímco tato pravidla rozhodují o tom, co smí odejít bez něj.

IPv6 potřebuje vlastní dveře

Vše výše je IPv4. Pokud má vaše LAN funkční IPv6 a tunel přenáší jen IPv4, každé pokryté zařízení má stále přímou cestu do internetu, kterou vaše nová pravidla nikdy nevidí. Notebook s duálním zásobníkem ji rád upřednostní a kill switch bude vypadat rozbitý jen tomu, kdo testuje s IPv4.

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

I zde záleží na pořadí: povolení loopback musí předcházet odmítnutí WAN, jinak lokální služby na routeru začnou podivně selhávat. Pokud síť IPv6 vůbec nepoužívá, je jednodušší ho vypnout na WAN a LAN a nezůstane nic k zapomenutí.

Někteří klienti VPN instalují výchozí trasu jen pro IPv4 a existující výchozí trasu IPv6 nechávají netknutou. Zkontrolujte směrovací tabulku poté, co se tunel připojí, místo abyste předpokládali, že to klient vyřešil.

Dokažte to s vypnutým tunelem

Zastavte tunel z routeru a testujte ze tří míst v tomto pořadí:

# 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

Vyhledání trasy vám řekne, kam by paket šel, a čítače vám řeknou, zda vaše pravidla někdy zasáhla. Pravidlo s nulovými pakety po neúspěšném testu nic nechrání a obvyklou příčinou je název rozhraní, který se liší od toho, co jste napsali. Testujte výslovně provoz generovaný routerem, protože test ze strany LAN nemůže procvičit OUTPUT.

O režimu selhání rozhodněte dřív, než ho budete potřebovat. Fail-closed drží klienty offline, dokud se tunel nevrátí; fail-open obnoví běžný přístup k WAN a zmaří účel pro provoz, na kterém vám záleželo. Blackhole trasa do poolu VPN s vysokou metrikou je užitečná druhá vrstva pro návrhy fail-closed, protože přežije, když trasa tunelu zmizí, místo aby se vrátila na výchozí.

Nastavení přijměte jen tehdy, když klient v LAN, požadavek generovaný routerem a požadavek IPv6 všechny selžou s vypnutým tunelem a všechny tři znovu fungují, jakmile se zvedne.