Einen OpenVPN-Client aus dem LAN sperren, ohne den Tunnel zu stoppen

Ein Client auf Ihrem OpenVPN-Server muss den LAN-Zugriff verlieren, während alle anderen Tunnel bestehen bleiben. Suchen Sie danach, sagt die beste Antwort meist, der Daemon könne das nicht, was nur halb stimmt: OpenVPN hat keine Firewall pro Client, aber der Host, der den Tunnel beendet, filtert bereits Pakete. Die zwei Entscheidungen, auf die es ankommt, sind die Identität, die Sie sperren, und die Position der Regel. Machen Sie beides richtig, wird die Änderung eine Zeile, die Sie testen und entfernen können.

Den Client binden, bevor die Regel geschrieben wird

OpenVPN vergibt Tunneladressen aus einem Pool, 10.8.0.6 ist also ein Platz und keine Person. Endet die Sitzung, geht die Lease zurück und kann an die nächste Verbindung gehen, das heißt, eine gegen diese Adresse geschriebene Regel folgt dem Platz, nicht dem Benutzer. Entscheiden Sie deshalb zuerst, was Sie wirklich sperren: eine Adresse für ein kurzes Experiment oder ein Zertifikat für jemanden, den Sie draußen halten wollen.

Um die Adresse an das Zertifikat zu binden, legen Sie eine Datei in dem Verzeichnis an, das client-config-dir benennt, und geben Sie der Datei genau den common name des Zertifikats. Setzen Sie eine Direktive hinein, ifconfig-push 10.8.0.6 255.255.255.0, und dieser Client behält dieselbe Tunneladresse über Wiederverbindungen hinweg. Zwei Einstellungen müssen dafür existieren: client-config-dir muss in der Serverkonfiguration deklariert sein, und die gepushte Adresse muss in einem Subnetz liegen, das der Server routen kann. Fehlt eines, wird die Datei ohne Fehler ignoriert, was den nächsten Firewall-Test irreführend macht.

Eine vorübergehende Sperre kann eine Pool-Adresse verwenden, solange das Ticket festhält, welche Sitzung sie damals hielt.

Die Reihenfolge entscheidet, ob das Verwerfen läuft

Auf einem Linux-Gateway, das zwischen Tunnel und LAN weiterleitet, durchlaufen Pakete die Kette FORWARD. Lesen Sie den Befehl unten als Satz: am Kopf von FORWARD einfügen, Verkehr treffen, der von tun0 hereinkommt, von genau diesem Host, an das LAN-Subnetz adressiert, und verwerfen.

iptables -I FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP

Das -I ist es, was die Regel laufen lässt. Mit -A angehängt, landet sie unter jeder breiten Akzeptanz für das Tunnel-Subnetz und sieht nie ein Paket. Prüfen Sie die Position mit iptables -vnL FORWARD --line-numbers, und lesen Sie auch die Zähler: ein Verwerfen oben, das nichts zählt, bedeutet, dass der Verkehr über einen anderen Weg ankommt.

Die eigene LAN-Adresse des Gateways ist ein anderer Weg. Pakete an die Box selbst gehen an INPUT, nicht an FORWARD, ein Client kann also einen LAN-Host verlieren und trotzdem die Admin-Seite des Routers öffnen. Fügen Sie die passende INPUT-Regel hinzu, wenn das zählt.

Was der Filter nicht sieht

Gefiltert wird, wenn ein Paket bewertet wird, eine bestehende TCP-Sitzung kann also weiterlaufen, bis sie schließt oder zurückgesetzt wird. Muss die Sperre sofort greifen, löschen Sie die verfolgten Flows für diese Quelle mit conntrack -D -s 10.8.0.6, nachdem die Regel eingesetzt wurde. Sind ein paar Sekunden Überlappung akzeptabel, halten Sie diese Wahl fest, statt sie implizit zu lassen. So oder so muss die nächste Person wissen, ob die Regel laufenden Verkehr stoppt oder nur neue Verbindungen.

Peer-Verkehr berührt die Firewall des Hosts nie. Mit aktiviertem client-to-client leitet OpenVPN diese Pakete im Daemon weiter, sodass weder FORWARD noch INPUT sie sehen. Die einzigen Lösungen sind, client-to-client abzuschalten oder zu akzeptieren, dass Peers einander erreichen; eine iptables-Regel sieht diesen Verkehr nicht.

IPv6, Firmware und Überleben eines Neustarts

Eine IPv4-Regel sagt nichts über IPv6. Tragen Tunnel und LAN beide Familien, muss die entsprechende Regel in ip6tables existieren oder in dem nftables-Regelsatz, der die Policy auf diesem Host besitzt. Router-Firmware versteckt netfilter oft hinter ihrer eigenen Abstraktion, daher gelten aus einem Forum kopierte Syntax und Tabellennamen möglicherweise nicht.

Auf OpenWrt ist der dokumentierte Weg ein Firewall-Konfigurationseintrag und keine handgeschriebene iptables-Zeile, und eine handgeschriebene Zeile kann verschwinden, wenn die Firewall neu lädt. Andere Distributionen stellen Regeln über netfilter-persistent, eine Boot-Einheit oder einen Herstellerspeicher wieder her, und diese Mechanismen sind nicht austauschbar. Beweisen Sie den gewählten mit einem Neustart, denn ein Neuladen nutzt einen anderen Weg.

Nach Weg prüfen, dann sauber zurückrollen

Testen Sie jeden Weg einzeln, denn eine erfolgreiche Prüfung verdeckt die anderen. Ein gesperrter Client sollte weiter über den Tunnel ins Internet kommen, gegen einen LAN-Host aber scheitern, ein zweiter Client sollte denselben Host erreichen, und Gateway-Adresse sowie Peer-Weg brauchen je eigene Beobachtung. Schreiben Sie die Ergebnisse neben die Regel, damit die nächste Änderung eine Grundlage hat. Die Tabelle unten ist der Satz, der im Ticket bleiben sollte.

Zurückrollen ist ein Löschen nach Spezifikation, kein Flush: iptables -D FORWARD -i tun0 -s 10.8.0.6/32 -d 192.168.1.0/24 -j DROP entfernt genau diesen Eintrag und lässt den Rest der Kette unangetastet. Entfernen Sie dieselbe Zeile aus der Datei, die die Regeln beim Booten wiederherstellt, laden Sie sie neu und bestätigen Sie, dass der Client den LAN-Host wieder erreicht. Ein Flush von FORWARD würde auch Regeln rückgängig machen, die Sie nicht geschrieben haben, was ein Zurückrollen zu einem zweiten Vorfall macht.

Bevor Sie das Ticket schließen, bestätigen Sie drei Dinge: die gebundene Adresse passt zum Zertifikat, die Regel steht über den Akzeptanzen mit einem Zähler ungleich null, und die Persistenzdatei enthält dieselbe Regel, die Sie getestet haben. Fehlt eines davon, ist die Sperre eine Illusion in einer Shell-Sitzung.