Downscript of firewallregel: welke stopt het lek?

Twee ontwerpen beloven hetzelfde: wanneer de tunnel valt, gaat er niets onversleuteld naar buiten. Het ene draait een script bij het afbreken en knipt interfaces door. Het andere laat een firewallregel van kracht en vraagt de VPN-client niets. Ze verschillen in wie de bevoegdheid heeft om te handelen, wat er tijdens het gat gebeurt en hoe de machine daarna weer online komt. Ze op die drie punten vergelijken is nuttiger dan discussiëren over welke strenger is.

Hetzelfde werk via twee mechanismen

De client kan hooks draaien wanneer de tunnel opkomt en wanneer hij wordt afgebroken, mits het profiel scriptuitvoering toestaat. Die hook draait binnen de levenscyclus van de client, op het moment dat de verbinding sluit. Een firewallregel daarentegen is eigendom van het systeem en trekt zich er niets van aan of de client draait, is gecrasht of werd gedood.

Die tabel is het hele argument. Een script dat alleen bij een nette afsluiting draait, dekt het geval waarover u zich het minst zorgen maakte; het geval dat telt is de crash of het netwerk dat verdwijnt, en geen van beide levert een schone afbraak.

Wat de afbreekhook wel en niet kan

Het gedocumenteerde patroon loopt de netwerkinterfaces langs en haalt alles neer behalve loopback. Met het fysieke apparaat neer kan niets buiten de tunnel ontsnappen, en dat is precies de bedoeling.

#!/bin/sh
for dev in /sys/class/net/*; do
  name=$(basename "$dev")
  [ "$name" = lo ] || ip link set dev "$name" down
done

Het haalt ook het lokale netwerk neer, elke dienst die de machine host, en het pad dat u zou gebruiken om het probleem op te lossen. Op een laptop moet het draadloze apparaat daarna soms met de hand worden omgezet, zodat een korte storing een reparatiesessie wordt. Erger nog, de hook mag dat misschien allemaal niet doen: wanneer de client rechten afstaat, draait het afbreekscript onder het niet-geprivilegieerde account, en elke interfacewijziging mislukt met een rechtenfout die wordt geschreven op het moment dat niemand het log leest.

Controleer hoe de client wordt gestart voordat u de hook vertrouwt. Een script dat werkt als u het met de hand als root draait, bewijst niets over de dienst die bij het opstarten begint.

Wat de firewallregel anders doet

Een regel die alleen tunnelverkeer toestaat, blijft werken wanneer het clientproces weg is, omdat de kernel niet van dat proces afhangt. De regel is ook smaller: hij blokkeert precies de stromen waarop hij past en laat loopback, het lokale subnet en het herstelpad met rust, waardoor hij de machine niet vastzet.

De prijs is dat de regel geschreven en onderhouden moet worden door wie de firewall van de host bezit, en hij moet het tunnelapparaat benoemen dat de client werkelijk aanmaakt. Dat betekent dat de regel en het profiel samen onderhouden moeten worden; een hernoemde interface laat een firewall achter die alles blokkeert en niets uitlegt.

Geen van beide mechanismen maakt het andere overbodig. Een firewallregel die na een wijziging nooit opnieuw wordt geladen, is even fictief als een script dat nooit draait.

persist-tun bepaalt of er een gat is

Wanneer het tunnelapparaat een verbreking overleeft, overleven de routes erheen ook. Verkeer wordt dan weggegooid in plaats van omgeleid, zodat de standaardroute niet terugvalt op de fysieke gateway. Dat is het gedrag dat een lek onwaarschijnlijk maakt nog voordat enige firewallregel in het spel is.

Zonder die instelling wordt het apparaat verwijderd en de routes ermee, en kan de standaardroute weer naar de fysieke gateway wijzen. Of dat gebeurt, hangt af van het platform en de client, en juist daarom moet de toestand worden waargenomen in plaats van aangenomen. Behandel de instelling als onderdeel van de kill switch, niet als een prestatieoptie.

Houd het herverbindingspad in leven en test dan vier toestanden

Een strikte blokkade kan de client ook beletten opnieuw te verbinden, omdat de client nog steeds een route naar de server via de fysieke gateway nodig heeft terwijl al het andere wordt geweigerd. Installeer een hostroute voor dat ene adres voordat de tunnel opkomt, en los eerst de naam op, want DNS kan op het moment dat u het nodig hebt al geblokkeerd zijn.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Controleer dan de toestanden in plaats van het label. Doorloop vier momenten bewust: een koude start zonder tunnel, een gezonde sessie, een breuk die niemand vroeg en de sessie nadat die herstelt. Lees op elk moment de standaardroute en doe één verzoek waarvan het uitgangsadres zichtbaar is. Een toepassing die opgeeft terwijl de tunnel neer is, zegt niets over een mailclient of een updater, dus herhaal de laatste controle met één achtergrondtoepassing. Schrijf de regel, de interfacenamen en de herstelstappen op, want een kill switch die niemand kan verifiëren is een gerucht.