Kill Switch op die router wat FORWARD, OUTPUT en IPv6 dek

Jy meld by die router aan, plak ’n kill-switch-reëlstel uit ’n forumpos, en die LAN hou op om te blaai die oomblik wanneer die tonnel val. Twee dae later dateer die router steeds sy dinamiese DNS-rekord oor die gewone WAN op, en die gas-skootrekenaar bereik steeds IPv6-werwe. Beide gedrag is normaal, want die geplakte reëls het een ketting en een adresfamilie gedek, en nie een daarvan is die hele router nie. Om die pakkiepaaie in volgorde te stap wys presies wat gemis is.

Begin by die router, nie by die skootrekenaar nie

’n Beleid op routervlak is aantreklik vir ’n klein kantoor omdat elke toestel daarachter dieselfde gedrag erf en niemand kan vergeet om ’n kliëntskakelaar te aktiveer nie. Dit gee jou ook een plek om ná elke firmware-opdatering te toets. Wat dit nie gee nie, is outomatiese dekking van die router se eie verkeer of van ’n tweede adresfamilie, en dit is die twee gapings agter die meeste mislukte ontplooiings.

Voordat jy iets wysig, skryf drie feite op papier: die WAN-koppelvlaknaam, die LAN-brugnaam, en die VPN-eindpunt se adres en poort. Jy sal al drie in die reëls nodig hê, en om koppelvlakname te raai is die mees algemene rede waarom ’n korrek-lykende reëlstel niks doen nie.

Stap deur die drie paaie wat ’n pakkie kan volg

Verkeer van ’n skootrekenaar na die internet word aangestuur, so dit gaan deur die FORWARD-ketting. Verkeer wat die router self genereer, soos DNS-aansturing, NTP-navrae, DDNS-opdaterings en die VPN-beheerkanaal, gaan deur OUTPUT. Bestuursverkeer wat aan die router gerig is, kom deur INPUT binne.

’n Kill switch wat net in FORWARD gebou is, beskerm dus kliënte en niks anders nie. Die tabel wys waarom die lek in die openingstoneel voorspelbaar eerder as raaiselagtig is.

Jy het in die meeste ontwerpe nie ’n kill switch op INPUT nodig nie, maar jy moet wel bestuurstoegang aan die gang hou terwyl die tonnel af is. Anders ry jy die eerste keer wanneer die VPN faal met ’n konsolekabel kantoor toe.

Rangskik die reëls sodat die tonnel nog kan opkom

’n Werkende kill switch is ’n toelaatlys wat op ’n reject eindig, en die ordening is wat dit ’n kill switch maak eerder as ’n baksteen. Laat loopback, die VPN-eindpunt, antwoorde vir bestaande vloei en die tonnelkoppelvlak eerste toe; verwerp die res laaste.

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

Die eindpunt moet op hierdie punt ’n adres wees, nie ’n gasheernaam nie. Sodra die finale reject DNS blokkeer, kan ’n reël wat die diensverskaffer se gasheernaam noem, nie meer opgelos word nie, en die tonnel begin nooit weer ná ’n herlaai nie. As die verskaffer eindpunte roteer, los die naam op voordat die beleid toegepas word en verfris daardie reël uit dieselfde script.

Spieël die vorm in FORWARD vir kliëntverkeer, en plaas ’n eksplisiete bestuursreël bo die reject. Hou daardie bestuursreël smal maar bereikbaar, en bevestig dit deur ’n tweede SSH-sessie oop te maak voordat jy die eerste sluit. Om jouself tydens ’n kill-switch-verandering uit te sluit is algemeen genoeg om voor te beplan. Op ’n router wat WireGuard dra, besluit die allowed-ips van die eweknie wat die tonnel binnegaan, terwyl hierdie reëls besluit wat toegelaat word om sonder dit uit te gaan.

IPv6 het sy eie voordeur nodig

Alles hierbo is IPv4. As jou LAN werkende IPv6 het en die tonnel dra net IPv4, het elke gedekte toestel steeds ’n direkte roete na die internet wat jou nuwe reëls nooit sien nie. ’n Dual-stack-skootrekenaar sal dit geredelik verkies, en die kill switch sal net vir die persoon wat met IPv4 toets as stukkend lyk.

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

Orde maak hier ook saak: die loopback-toelating moet die WAN-verwerping voorafgaan, anders begin plaaslike dienste op die router op snaakse maniere faal. As die netwerk glad nie IPv6 gebruik nie, is dit eenvoudiger om dit op die WAN en LAN af te skakel en laat dit niks oor om te vergeet nie.

Sommige VPN-kliënte installeer ’n verstekroete net vir IPv4 en laat die bestaande IPv6-verstek ongeraak. Kontroleer die roetekaart nadat die tonnel verbind het eerder as om aan te neem die kliënt het dit hanteer.

Bewys dit met die tonnel af

Stop die tonnel vanaf die router en toets van drie plekke in hierdie volgorde:

# 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

Die roete-opsoek vertel jou waar ’n pakkie sou gaan, en die tellers vertel jou of jou reëls ooit gepas het. ’n Reël met nul pakkies ná ’n mislukte toets beskerm niks, en die gewone oorsaak is ’n koppelvlaknaam wat verskil van die een wat jy getik het. Toets router-gegenereerde verkeer eksplisiet, want ’n toets van die LAN-kant kan nie OUTPUT oefen nie.

Besluit die foutmodus voordat jy dit nodig het. Fail-closed hou kliënte vanlyn tot die tonnel terugkeer; fail-open herstel gewone WAN-toegang en verydel die doel vir die verkeer waaroor jy bekommerd was. ’n Blackhole-roete na die VPN-poel met ’n hoë metriek is ’n nuttige tweede laag vir fail-closed-ontwerpe, want dit oorleef wanneer die tonnelroete verdwyn in plaas daarvan om na die verstek terug te val.

Aanvaar die opstelling eers wanneer ’n LAN-kliënt, ’n router-gegenereerde versoek en ’n IPv6-versoek al drie faal met die tonnel af, en al drie weer werk sodra dit op is.