Kill switch op de router die FORWARD, OUTPUT en IPv6 dekt

U logt in op de router, plakt een kill switch-regelset uit een forumbericht, en het LAN stopt met browsen op het moment dat de tunnel wegvalt. Twee dagen later werkt de router nog steeds zijn dynamische DNS-record bij via de gewone WAN, en de gastlaptop bereikt nog steeds IPv6-sites. Beide gedragingen zijn normaal, want de geplakte regels dekten één keten en één adresfamilie, en geen van beide is de hele router. De pakketpaden op volgorde langslopen laat precies zien wat er gemist is.

Begin bij de router, niet bij de laptop

Een beleid op routerniveau is aantrekkelijk voor een klein kantoor omdat elk apparaat erachter hetzelfde gedrag erft en niemand kan vergeten een clientschakelaar in te schakelen. Het geeft u ook één plek om te testen na elke firmware-update. Wat het niet geeft, is automatische dekking van het eigen verkeer van de router of van een tweede adresfamilie, en dat zijn de twee gaten achter de meeste mislukte uitrol.

Noteer voordat u iets aanpast drie feiten op papier: de naam van de WAN-interface, de naam van de LAN-brug en het adres en de poort van het VPN-eindpunt. U hebt alle drie nodig in de regels, en het raden van interfacenamen is de meest voorkomende reden dat een correct uitziende regelset niets doet.

Loop de drie paden langs die een pakket kan nemen

Verkeer van een laptop naar internet wordt doorgestuurd, dus het gaat door de FORWARD-keten. Verkeer dat de router zelf genereert, zoals DNS-doorsluizing, NTP-query’s, DDNS-updates en het VPN-controlekanaal, gaat door OUTPUT. Beheerverkeer dat aan de router is gericht, komt binnen via INPUT.

Een kill switch die alleen in FORWARD is gebouwd, beschermt dus clients en niets anders. De tabel laat zien waarom het lek in de openingsscène voorspelbaar is en niet mysterieus.

In de meeste ontwerpen hebt u geen kill switch op INPUT nodig, maar u moet de beheertoegang werkend houden terwijl de tunnel neerligt. Anders rijdt u bij de eerste VPN-storing met een consolekabel naar kantoor.

Orden de regels zodat de tunnel nog omhoog kan

Een werkende kill switch is een toelatingslijst die eindigt in een afwijzing, en de volgorde maakt hem een kill switch in plaats van een baksteen. Sta eerst loopback, het VPN-eindpunt, antwoorden voor bestaande stromen en de tunnelinterface toe; wijs de rest als laatste af.

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

Het eindpunt moet op dit punt een adres zijn, geen hostnaam. Zodra de laatste afwijzing DNS blokkeert, kan een regel die de hostnaam van de provider noemt niet meer worden opgelost, en de tunnel start na een herstart nooit meer. Als de provider eindpunten wisselt, los de naam op voordat het beleid wordt toegepast en ververs die regel vanuit hetzelfde script.

Spiegel de vorm in FORWARD voor clientverkeer, en plaats een expliciete beheerregel boven de afwijzing. Houd die beheerregel smal maar bereikbaar, en bevestig hem door een tweede SSH-sessie te openen voordat u de eerste sluit. Jezelf buitensluiten tijdens een kill switch-wijziging is gewoon genoeg om op te plannen. Op een router met WireGuard bepalen de allowed-ips van de peer wat de tunnel in gaat, terwijl deze regels bepalen wat er zonder de tunnel uit mag.

IPv6 heeft een eigen voordeur nodig

Alles hierboven is IPv4. Als uw LAN werkend IPv6 heeft en de tunnel alleen IPv4 vervoert, heeft elk gedekt apparaat nog steeds een directe route naar internet die uw nieuwe regels nooit zien. Een dual-stack-laptop zal die graag verkiezen, en de kill switch lijkt alleen kapot voor wie met IPv4 test.

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

Ook hier is de volgorde belangrijk: de loopback-toestemming moet vóór de WAN-afwijzing komen, anders beginnen lokale diensten op de router op vreemde manieren te falen. Als het netwerk helemaal geen IPv6 gebruikt, is het uitschakelen ervan op de WAN en het LAN eenvoudiger en blijft er niets te vergeten.

Sommige VPN-clients installeren alleen voor IPv4 een standaardroute en laten de bestaande IPv6-standaardroute ongemoeid. Controleer de routingtabel nadat de tunnel is verbonden in plaats van aan te nemen dat de client het heeft afgehandeld.

Bewijs het met de tunnel neer

Stop de tunnel vanaf de router en test vanaf drie plaatsen in deze 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

De routeopzoeking vertelt u waar een pakket heen zou gaan, en de tellers vertellen u of uw regels ooit hebben gematcht. Een regel met nul pakketten na een mislukte test beschermt niets, en de gebruikelijke oorzaak is een interfacenaam die afwijkt van wat u hebt getypt. Test router-gegenereerd verkeer expliciet, want een test vanaf de LAN-kant kan OUTPUT niet uitoefenen.

Bepaal de faalmodus voordat u die nodig hebt. Fail-closed houdt clients offline tot de tunnel terugkomt; fail-open herstelt gewone WAN-toegang en ondermijnt het doel voor het verkeer waar u om gaf. Een blackhole-route naar de VPN-pool met een hoge metriek is een nuttige tweede laag voor fail-closed-ontwerpen, omdat die overleeft wanneer de tunnelroute verdwijnt in plaats van terug te vallen op de standaardroute.

Accepteer de opzet pas wanneer een LAN-client, een door de router gegenereerd verzoek en een IPv6-verzoek allemaal falen met de tunnel neer, en alle drie weer werken zodra hij op is.