Kill switch na routeri, ktorý pokrýva FORWARD, OUTPUT a IPv6

Prihlásite sa do routera, vložíte sadu pravidiel kill switch z príspevku na fóre a LAN prestane prehliadať v okamihu, keď tunel spadne. O dva dni neskôr router stále aktualizuje svoj záznam dynamického DNS cez bežné WAN a hostujúci notebook sa stále dostane na stránky IPv6. Obe správania sú normálne, pretože vložené pravidlá pokrývali jeden reťazec a jednu adresnú rodinu a ani jedno z toho nie je celý router. Prejdenie ciest paketov v poradí presne ukáže, čo sa vynechalo.

Začnite pri routeri, nie pri notebooku

Zásada na úrovni routera je pre malú kanceláriu atraktívna, pretože každé zariadenie za ním zdedí rovnaké správanie a nikto nemôže zabudnúť zapnúť prepínač v klientovi. Dáva vám aj jedno miesto na testovanie po každej aktualizácii firmvéru. Čo vám nedáva, je automatické pokrytie vlastnej prevádzky routera alebo druhej adresnej rodiny, a to sú dve medzery za väčšinou neúspešných nasadení.

Predtým než čokoľvek upravíte, poznamenajte si na papier tri údaje: názov rozhrania WAN, názov mosta LAN a adresu a port koncového bodu VPN. Všetky tri budete v pravidlách potrebovať a hádanie názvov rozhraní je najčastejším dôvodom, prečo sada pravidiel, ktorá vyzerá správne, nič nerobí.

Prejdite tri cesty, ktorými môže paket ísť

Prevádzka z notebooku do internetu sa preposiela, takže prechádza reťazcom FORWARD. Prevádzka, ktorú generuje samotný router, napríklad preposielanie DNS, dopyty NTP, aktualizácie DDNS a riadiaci kanál VPN, prechádza cez OUTPUT. Riadiaca prevádzka adresovaná routeru prichádza cez INPUT.

Kill switch postavený len vo FORWARD teda chráni klientov a nič iné. Tabuľka ukazuje, prečo je únik z úvodnej scény predvídateľný a nie záhadný.

Vo väčšine návrhov nepotrebujete kill switch na INPUT, ale musíte udržať funkčný správcovský prístup, kým je tunel dole. Inak pri prvom výpadku VPN idete do kancelárie s konzolovým káblom.

Zoraďte pravidlá tak, aby sa tunel ešte zdvihol

Funkčný kill switch je zoznam povolení, ktorý končí odmietnutím, a poradie z neho robí kill switch a nie tehlu. Najprv povoľte loopback, koncový bod VPN, odpovede pre nadviazané toky a rozhranie tunela; zvyšok odmietnite nakoniec.

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 musí byť v tomto bode adresa, nie názov hostiteľa. Keď záverečné odmietnutie zablokuje DNS, pravidlo, ktoré uvádza názov hostiteľa poskytovateľa, už nemožno preložiť, a tunel po reštarte už nikdy nenabehne. Ak poskytovateľ strieda koncové body, preložte názov pred použitím zásady a obnovujte to pravidlo z toho istého skriptu.

Zopakujte rovnaký tvar vo FORWARD pre prevádzku klientov a umiestnite explicitné správcovské pravidlo nad odmietnutie. Držte toto správcovské pravidlo úzke, ale dostupné, a potvrďte ho otvorením druhej SSH relácie pred zatvorením prvej. Zamknúť sa počas zmeny kill switch je dosť bežné na to, aby sa s tým počítalo. Na routeri s WireGuardom rozhodujú allowed-ips partnera o tom, čo vstúpi do tunela, zatiaľ čo tieto pravidlá rozhodujú o tom, čo smie odísť bez neho.

IPv6 potrebuje vlastné dvere

Všetko vyššie je IPv4. Ak má vaša LAN funkčný IPv6 a tunel prenáša iba IPv4, každé pokryté zariadenie má stále priamu cestu do internetu, ktorú vaše nové pravidlá nikdy nevidia. Notebook s duálnym zásobníkom ju rád uprednostní a kill switch bude vyzerať pokazený len tomu, kto 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

Aj tu záleží na poradí: povolenie loopback musí predchádzať odmietnutiu WAN, inak lokálne služby na routeri začnú zvláštne zlyhávať. Ak sieť IPv6 vôbec nepoužíva, je jednoduchšie ho vypnúť na WAN a LAN a nezostane nič na zabudnutie.

Niektorí klienti VPN inštalujú predvolenú trasu len pre IPv4 a existujúcu predvolenú trasu IPv6 nechávajú nedotknutú. Skontrolujte smerovaciu tabuľku po pripojení tunela, namiesto toho, aby ste predpokladali, že to klient vyriešil.

Dokážte to s vypnutým tunelom

Zastavte tunel z routera a testujte z troch miest v tomto poradí:

# 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

Vyhľadanie trasy vám povie, kam by paket išiel, a počítadlá vám povedia, či vaše pravidlá niekedy zasiahli. Pravidlo s nulovými paketmi po neúspešnom teste nič nechráni a obvyklou príčinou je názov rozhrania, ktorý sa líši od toho, čo ste napísali. Testujte výslovne prevádzku generovanú routerom, pretože test zo strany LAN nemôže precvičiť OUTPUT.

O režime zlyhania rozhodnite skôr, než ho budete potrebovať. Fail-closed drží klientov offline, kým sa tunel nevráti; fail-open obnoví bežný prístup k WAN a zmárni účel pre prevádzku, na ktorej vám záležalo. Blackhole trasa do poolu VPN s vysokou metrikou je užitočná druhá vrstva pre návrhy fail-closed, pretože prežije, keď trasa tunela zmizne, namiesto návratu na predvolenú.

Nastavenie prijmite len vtedy, keď klient v LAN, požiadavka generovaná routerom a požiadavka IPv6 všetky zlyhajú s vypnutým tunelom a všetky tri znova fungujú, keď sa zdvihne.