Linux ausgangsseitig sperren, damit beim VPN-Ausfall nichts entweicht

Stellen Sie sich eine Media-Box am Heimanschluss vor, die das Internet nur über einen Tunnel erreichen soll. Fällt der Tunnel aus, soll die Anwendung stocken, statt still über die physische Schnittstelle weiterzulaufen. Dieses Verhalten ist ein Firewall- und kein Routing-Problem, und der Unterschied zählt, weil eine Route durch einen Neustart des Daemons ersetzt werden kann, während ein Filter dort bleibt, wo man ihn abgelegt hat. Im Folgenden geht es darum, wie der Paketpfad tatsächlich entscheidet und wie man anschließend die Ausnahmen begrenzt, die den Tunnel wieder verbinden lassen.

Lokaler Output ist ein anderer Hook als Forwarding

Ein Paket, das eine Anwendung auf dem Rechner verlässt, durchläuft den Output-Hook; ein Paket, das der Rechner für einen anderen Host weiterleitet, durchläuft Forward. Eine Policy, die nur forward nennt, beschränkt den zweiten Fall und lässt den ersten weit offen – deshalb sehen so viele Egress-Sperren richtig aus und bewirken nichts. Die Schnittstellenprüfung gehört in dieselbe Regel: oifname "tun0" accept lässt Verkehr durch, der bereits über den Tunnel geroutet wurde. Routing und Filterung bleiben ebenfalls getrennte Entscheidungen, sodass eine Uplink-Route existieren kann, während der Filter das Paket ablehnt. Auf diese Trennung verlassen Sie sich.

Ein Gateway, das für andere Geräte weiterleitet, braucht beide Hooks. Wer nur den Output sperrt, schützt den Rechner selbst und lässt jedem nachgelagerten Client freien Lauf zum Leck.

Die Ausnahmeliste vom Endpunkt nach außen schreiben

Beginnen Sie beim Tunnel-Endpunkt: eine Zieladresse oder eine kleine freigegebene Menge, das Transportprotokoll und der Zielport, zum Beispiel udp dport 1194 ip daddr 203.0.113.7 accept. Löst der Client einen Hostnamen auf, braucht der Bootstrap-DNS-Austausch eine eigene Regel, begrenzt auf den Resolver und auf Port 53, nicht eine pauschale Erlaubnis an dessen Adresse. Jede Ausnahme sollte den Grund benennen, aus dem es sie gibt. Eine Freigabe für den gesamten UDP-Verkehr zum VPN-Port deckt weit mehr ab als der eine authentifizierte Dienst, den Sie im Sinn hatten.

Die Bootstrap-Auflösung ist die Stelle, an der Sperren meist verrotten. Eine Adressmenge, die per Timer aktualisiert wird, braucht ein definiertes Verhalten, wenn die Aktualisierung scheitert, und dieses Verhalten darf nicht darin bestehen, den Uplink zu öffnen, bis es klappt. Aktualisieren Sie über den Tunnel, solange er steht, und fallen Sie andernfalls auf den letzten bekannten guten Endpunkt zurück.

Die lokale Administration braucht dieselbe Behandlung. Ein Management-Subnetz ist nicht vertrauenswürdig, nur weil seine Adressen privat sind, und eine Regel, die ihm vertraut, lädt einen zweiten Pfad um die Sperre herum ein.

Schnittstellen-Matching ist kein Beweis für einen gesunden Tunnel

Regeln, die alles akzeptieren, was tun0 verlässt, gehen davon aus, dass ein Paket auf dieser Schnittstelle aus dem Tunnel kam. Schnittstellennamen werden neu erzeugt, und ein Name ist keine kryptografische Identität. Der Peer kann auch weg sein, während die Schnittstelle oben bleibt, was die Regel zu einem sehr überzeugenden No-op macht.

Connection Tracking fügt eine verwandte Falle hinzu. Eine breite Regel für bestehende Verbindungen spielt die Erlaubnis zurück, die ein Flow früher erhalten hat, sodass eine Sitzung, die vor dem Tunnelausfall begann, danach weiterläuft. Beschränken Sie zustandsbehaftete Akzeptanz auf die Schnittstellen und Adressen, die Sie wirklich meinen, sonst haben Sie eine Sperre gebaut, die sich selbst öffnet. Input- und Output-Regeln beantworten zudem unterschiedliche Fragen, und wenn man nur eine härtet, bleibt der Rechner in der nicht bedachten Richtung erreichbar.

Was einen Daemon-Absturz übersteht

Ein Filter, den ein Skript installiert, das nach dem Hochfahren des Tunnels läuft, verschwindet mit dem Tunnel – genau in dem Moment, in dem er gebraucht wurde. Laden Sie die Sperre beim Booten und lassen Sie den Daemon nur seine Ausnahmen verwalten.

Das Löschen der Default-Route ist ebenfalls kein Ersatz. Die Route ist Zustand, den der Daemon besitzt und umschreibt, und ihr Entfernen kann den Pfad wegnehmen, der zum Wiederverbinden nötig ist. IPv6 braucht einen eigenen Plan, weil Neighbour Discovery und Router Advertisements Link-Dienste sind, die weiter funktionieren müssen, während normaler Verkehr blockiert ist. DHCP gehört in dieselbe Kategorie. Schreiben Sie diese Dinge als Ausnahmen mit Zweck auf, statt sie später als Ausfälle zu entdecken.

Der Wiederherstellungspfad vor dem Einsatz

Testen Sie die Sperre so, wie sie versagen wird: booten ohne Tunnel, den Daemon killen, den Endpunkt wechseln und wiederverbinden. Jeder Fall sollte die Anwendungen stocken lassen und den Wiederherstellungskanal funktionsfähig halten. Tun Sie das an einer Konsole, denn eine Remote-Shell ist die Sitzung, die am ehesten durch Ihre eigene Regel ausgesperrt wird.

Prüfen Sie dann, was eine gewöhnliche Anwendung noch erreicht, mit einem harmlosen Ziel und einer Anfrage, die Sie verifizieren können. Das Ergebnis, das Sie wollen, ist eine Ablehnung am Uplink und ein Erfolg durch den Tunnel, nicht ein mehrdeutiger Timeout, der beides bedeuten könnte. Halten Sie das Regelwerk unter demselben Eigentümer wie den Rest der Firewall, statt die ganze Tabelle aus einem Shell-Skript zu ersetzen. Eine Policy, in der jede Freigabe sich selbst begründen kann, ist mehr wert als ein langes Regelwerk, das niemand erklären kann.