Down-Skript oder Firewall-Regel: Was stoppt das Leck?

Zwei Entwürfe versprechen dasselbe: Wenn der Tunnel fällt, verlässt nichts das Gerät im Klartext. Der eine führt beim Abbau ein Skript aus und kappt Schnittstellen. Der andere lässt eine Firewall-Regel in Kraft und verlangt vom VPN-Client nichts. Sie unterscheiden sich darin, wer die Berechtigung zum Handeln hat, was während der Lücke geschieht und wie das Gerät danach wieder online kommt. Ein Vergleich auf diesen drei Punkten ist nützlicher als der Streit darüber, welcher Ansatz strenger sei.

Dieselbe Aufgabe über zwei Mechanismen

Der Client kann Hooks ausführen, wenn der Tunnel aufgebaut wird und wenn er abgebaut wird, sofern das Profil die Skriptausführung erlaubt. Dieser Hook läuft innerhalb des Lebenszyklus des Clients, in dem Moment, in dem die Verbindung endet. Eine Firewall-Regel dagegen gehört dem System und kümmert sich nicht darum, ob der Client läuft, abgestürzt oder beendet wurde.

Diese Tabelle ist das ganze Argument. Ein Skript, das nur beim sauberen Herunterfahren läuft, deckt den Fall ab, der Ihnen am wenigsten Sorgen gemacht hat; der wichtige Fall ist der Absturz oder das verschwindende Netz, und keiner von beiden erzeugt einen sauberen Abbau.

Was der Abbau-Hook kann und was nicht

Das dokumentierte Muster geht die Netzwerkschnittstellen durch und schaltet alles außer Loopback ab. Ist das physische Gerät abgeschaltet, kann nichts außerhalb des Tunnels entweichen, und genau das ist beabsichtigt.

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

Es schaltet auch das lokale Netz ab, jeden Dienst, den das Gerät bereitstellt, und den Weg, auf dem Sie das Problem beheben würden. Auf einem Laptop muss das Funkgerät danach manchmal von Hand umgeschaltet werden, sodass eine kurze Störung zu einer Reparatursitzung wird. Schlimmer noch: Vielleicht darf der Hook nichts davon tun, denn wenn der Client Rechte abgibt, läuft das Abbau-Skript unter dem unprivilegierten Konto, und jede Schnittstellenänderung scheitert mit einem Berechtigungsfehler, der in dem Moment geschrieben wird, in dem niemand das Protokoll liest.

Prüfen Sie, wie der Client gestartet wird, bevor Sie dem Hook vertrauen. Ein Skript, das beim manuellen Lauf als root funktioniert, beweist nichts über den Dienst, der beim Booten startet.

Was die Firewall-Regel anders macht

Eine Regel, die nur Tunnelverkehr erlaubt, wirkt weiter, wenn der Clientprozess verschwunden ist, weil der Kernel nicht von diesem Prozess abhängt. Die Regel ist außerdem enger: Sie blockiert genau die Ströme, auf die sie passt, und lässt Loopback, das lokale Subnetz und den Reparaturweg in Ruhe, weshalb sie das Gerät nicht stranden lässt.

Der Preis ist, dass die Regel von demjenigen geschrieben und gepflegt werden muss, der die Host-Firewall besitzt, und sie muss das Tunnelgerät benennen, das der Client tatsächlich anlegt. Das heißt, Regel und Profil müssen gemeinsam gepflegt werden; eine umbenannte Schnittstelle hinterlässt eine Firewall, die alles blockiert und nichts erklärt.

Keiner der Mechanismen macht den anderen überflüssig. Eine Firewall-Regel, die nach einer Änderung nie neu geladen wird, ist so fiktiv wie ein Skript, das nie läuft.

persist-tun entscheidet, ob es eine Lücke gibt

Wenn das Tunnelgerät eine Trennung übersteht, überstehen auch die Routen, die hineinzeigen. Der Verkehr wird dann verworfen statt umgeleitet, sodass die Standardroute nicht auf das physische Gateway zurückfällt. Dieses Verhalten macht ein Leck unwahrscheinlich, noch bevor irgendeine Firewall-Regel im Spiel ist.

Ohne diese Einstellung wird das Gerät entfernt und die Routen mit ihm, und die Standardroute kann wieder auf das physische Gateway zeigen. Ob sie es tut, hängt von Plattform und Client ab, und genau deshalb muss der Zustand beobachtet statt angenommen werden. Behandeln Sie die Einstellung als Teil des Kill Switch, nicht als Leistungsoption.

Halten Sie den Wiederverbindungsweg offen, dann testen Sie vier Zustände

Eine strenge Sperre kann den Client auch an der Wiederverbindung hindern, weil er weiterhin eine Route zum Server über das physische Gateway braucht, während alles andere verweigert wird. Legen Sie eine Host-Route für diese eine Adresse an, bevor der Tunnel aufgebaut wird, und lösen Sie zuerst den Namen auf, denn DNS kann zu dem Zeitpunkt, an dem Sie es brauchen, bereits blockiert sein.

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

Prüfen Sie dann die Zustände statt das Etikett. Üben Sie vier Momente bewusst: einen Kaltstart ohne Tunnel, eine gesunde Sitzung, einen Abbruch, den niemand angefordert hat, und die Sitzung nach der Erholung. Lesen Sie in jedem Moment die Standardroute und stellen Sie eine Anfrage, deren Ausgangsadresse sichtbar ist. Eine Anwendung, die aufgibt, während der Tunnel unten ist, sagt nichts über einen Mailclient oder ein Update aus, also wiederholen Sie die letzte Prüfung mit einer Hintergrundanwendung. Schreiben Sie die Regel, die Schnittstellennamen und die Wiederherstellungsschritte auf, denn ein Kill Switch, den niemand prüfen kann, ist ein Gerücht.