Ein OpenVPN-Gateway mit UFW-Regeln auf ein LAN begrenzen

Entscheiden Sie die Freigabe, bevor Sie eine Firewall-Datei öffnen: authentifizierte Clients dürfen Verbindungen zu genau einem bestimmten Subnetz öffnen, und das Gateway muss jeden anderen Transitweg ablehnen, selbst wenn ein Client zusätzliche Routen installiert. Dieser Satz ist das Design, und jede Regel unten existiert, um ihn durchzusetzen. Alles Breitere, etwa der gesamte private Adressraum, Internetausgang durch den Tunnel oder Peer-to-Peer-Verkehr, ist ein anderes Design, das eine eigene Entscheidung braucht. Die Regeln sind zudem bewusst langweilig, denn eine clevere Firewall ist eine, die später niemand prüfen kann.

Schreiben Sie zuerst die Topologie und die Freigabe auf

Das Beispiel verwendet einen Community-OpenVPN-Server mit einem TUN-Gerät im Userspace namens tun0, einen Client-Pool 10.77.0.0/24, und ein angeschlossenes Subnetz 192.168.60.0/24 auf lan0. IPv4-Weiterleitung funktioniert bereits, und das LAN hat schon eine Rückroute zum Pool, sodass hier nichts von Übersetzung zwischen beiden abhängt.

UFW besitzt die Firewall auf diesem Host, und weder ein Container-Regelsatz noch eine separate nftables-Tabelle darf einen früheren Annahmeweg einbauen. Eine Flow-Offload-Abkürzung, die den Filter überspringt, würde die Wächterketten zur Dekoration machen, bestätigen Sie also, dass keine aktiv ist. Lassen Sie die eigene client-to-client-Weiterleitung von OpenVPN deaktiviert, denn Peer-to-Peer-Verkehr, der den Filter des Betriebssystems nie durchquert lässt sich damit nicht begrenzen. Der externe Listener und die Administrationsregeln bleiben, wie sie sind, denn diese Änderung regelt entschlüsselten Tunnelverkehr, statt die Firewall zu ersetzen.

Setzen Sie die Wächter vor die frühen Akzeptanzen von UFW

Eine Routenfreigabe mit anschließender Ablehnung reicht für eine strikte Grenze nicht. Die Standard-before-Regeln akzeptieren etablierten Verkehr und ausgewählte ICMP, bevor irgendeine Benutzerregel herangezogen wird, sodass ein letzte Woche erlaubter Fluss allein deshalb außerhalb der neuen Zielbeschränkung bleiben kann, weil er noch Zustand hat. Sichern Sie die UFW-Dateien und halten Sie vor dem Bearbeiten eine Out-of-Band-Konsole offen.

Deklarieren Sie im Abschnitt *filter der Datei /etc/ufw/before.rules zwei Ketten neben den vorhandenen Deklarationen und vor jeder Regelnzeile.

:vpn-src-guard - [0:0]
:vpn-reply-guard - [0:0]

Springen Sie unmittelbar nach den Deklarationen und vor den Freigaben für Eingang und Weiterleitung hinein und definieren Sie, was sie zulassen.

-A ufw-before-input -i tun0 -j DROP
-A ufw-before-forward -i tun0 -j vpn-src-guard
-A ufw-before-forward -o tun0 -j vpn-reply-guard

-A vpn-src-guard -o lan0 -d 192.168.60.0/24 -s 10.77.0.0/24 -m conntrack --ctdir ORIGINAL -j RETURN
-A vpn-src-guard -j DROP

-A vpn-reply-guard -i lan0 -d 10.77.0.0/24 -s 192.168.60.0/24 -m conntrack --ctstate RELATED,ESTABLISHED --ctdir REPLY -j RETURN
-A vpn-reply-guard -j DROP

Behalten Sie den Rest des Abschnitts und seine COMMIT-Zeile. Eine zweite Filtertabelle einzufügen oder unzusammenhängende Regeln zu löschen, ist der Weg, auf dem eine Firewall-Änderung zum Ausfall wird, und die Datei ist einen Neustart davon entfernt, die einzige Kopie zu sein, auf die es ankommt.

Lesen Sie, was jeder Wächter zulässt und ablehnt

Die erste Kette setzt die Verarbeitung nur fort, wenn die Quelle im Pool liegt, das Ziel das eine Subnetz ist, die Ausgangsschnittstelle das LAN ist und das Paket in der ursprünglichen Richtung seines Flusses läuft. Alles andere, was aus dem Tunnel kommt, wird verworfen, einschließlich einer Quelle außerhalb des Pools und jedes Ziels jenseits des erlaubten Subnetzes.

Ein Peer-to-Peer-Paket kommt herein und verlässt tun0, es scheitert also am LAN-Schnittstellentest, bevor überhaupt eine Zielprüfung erreicht wird. Neue Verbindungen vom LAN zu Clients scheitern ebenfalls am Antwortrichtungstest, was den umgekehrten Rückrufpfad standardmäßig schließt.

Das Ziel RETURN hält die gewöhnliche UFW-Richtlinie im Spiel. Diese Ketten filtern, und die Routenfreigabe, die Sie als Nächstes hinzufügen, entscheidet weiterhin, ob ein überlebendes Paket angenommen wird. Genau diese Trennung erlaubt es Ihnen, das erlaubte Subnetz später an einer Stelle zu ändern. Würden die Wächter Pakete direkt annehmen, müsste jede künftige Regel zweimal eingetragen werden.

Erlauben Sie das Subnetz und schließen Sie die Seitentüren

Zeigen Sie zuerst die Routenfreigabe in der Vorschau an und entfernen Sie dann das Vorschauflag, um sie anzuwenden: sudo ufw --dry-run route allow in on tun0 out on lan0 from 10.77.0.0/24 to 192.168.60.0/24. Prüfen Sie danach die Reihenfolge der Benutzerregeln, denn eine frühere Ablehnung gewinnt weiterhin gegen eine spätere Freigabe. Eine Freigabe für das ganze Subnetz ist zudem die falsche Form, wenn nur der HTTPS-Port eines Hosts erreichbar sein soll.

Beachten Sie, was das Eingangs-Verwerfen bewirkt: Tunnelclients erreichen keinen Dienst auf dem Gateway selbst, auch keinen DNS-Listener, der an seine LAN-Adresse gebunden ist. DNS dort zu hosten erfordert eine bewusste Ausnahme vor dem Verwerfen und einen überarbeiteten Freigabevertrag. Wenn UFW IPv6 verwaltet, fügen Sie passende Verwerfungen für tun0 in before6.rules ebenfalls hinzu, denn eine IPv4-Zielliste sagt nichts über IPv6-Pakete aus.

Prüfen Sie die geladene Richtlinie, nicht die Vorschau

Zeigen Sie das Neuladen in der Vorschau an, wenden Sie es in einem Wartungsfenster an und lesen Sie den laufenden Regelsatz.

sudo ufw --dry-run reload
sudo ufw show raw

Bestätigen Sie, dass die Tunnelwächter vor den Standardfreigaben für Zustand und ICMP erscheinen. Ein einfaches ufw status zeigt handbearbeitete before-Regeln nicht an, deshalb schließen Betreiber, eine Regel fehle, während sie tatsächlich geladen ist. Lesen Sie die Rohliste von oben nach unten, statt nach einem Fragment zu suchen. Erscheinen die Wächter nach einer Zustandsfreigabe, tut die Grenze nicht, was die Datei nahelegt.

Testen Sie danach Verhalten statt Text. Öffnen Sie eine frische Verbindung zu einem erlaubten Host und beobachten Sie die Antwort, leiten Sie eine harmlose Anfrage an ein Ziel außerhalb des Subnetzes und bestätigen Sie, dass sie stirbt, probieren Sie eine Peer-to-Peer-Verbindung, probieren Sie einen gateway-lokalen Dienst und probieren Sie eine unaufgeforderte LAN-zu-Client-Verbindung. Beziehen Sie einen Fluss außerhalb des Geltungsbereichs ein, der vor der Änderung bestand, und löschen Sie nur diesen Fluss, statt die gesamte Tracking-Tabelle der Maschine zu leeren.

Notieren Sie die Grenzen neben den Regeln: dies begrenzt Transit und sonst nichts. Es hindert einen Client nicht daran, seine eigene Internetverbindung zu nutzen, hindert einen erlaubten LAN-Host nicht daran, Verkehr weiterzuleiten, und ersetzt nicht die Authentifizierung innerhalb der erlaubten Dienste.