firewalld-Listener-Regel versus Weiterleitungsrichtlinie: was jede tut

Ein VPN, das sich verbindet, aber nichts erreicht, wird meist als Firewall-Problem beschrieben, und die Lösung, zu der man greift, ist, die Tunnel-Schnittstelle in eine vertrauenswürdige Zone zu legen. Das funktioniert in dem Sinn, dass Verkehr zu fließen beginnt, lässt aber auch weit mehr zu als den vorgesehenen Dienst. Die beiden beteiligten Richtlinien sind verschieden: Die eine lässt den äußeren Transport zu einem lauschenden Socket zu, die andere erlaubt entschlüsseltem Verkehr, eine bestimmte Ressource zu erreichen. Sie als eine Einstellung zu behandeln, verwandelt eine enge Freigabe in eine weite. Beide werden an verschiedenen Stellen entschieden, weshalb der Fehler so leicht zu machen ist.

Zwei Richtlinien, ein Tunnel

Die äußere Richtlinie beantwortet eine einfache Frage: Darf ein Paket aus dieser Quelle UDP 1194 auf diesem Host erreichen? Die innere Richtlinie beantwortet eine andere: Darf der authentifizierte Client hinter diesem Tunnel dieses Ziel erreichen, mit diesem Protokoll, auf diesem Port? Das eine betrifft einen Socket, das andere einen Pfad, und firewalld modelliert sie mit verschiedenen Objekten, weil sie an verschiedenen Punkten entschieden werden. Eines ist eine Eigenschaft eines Sockets auf diesem Host, das andere eines Pfades durch ihn hindurch.

Die praktische Folge ist, dass ein funktionierender Tunnel nichts über die zweite Richtlinie aussagt und eine korrekte zweite Richtlinie die erste nicht überflüssig macht.

Lassen Sie den tatsächlichen äußeren Listener zu

Beginnen Sie damit zu prüfen, was bereits zugewiesen ist, statt es anzunehmen. Lesen Sie die aktiven Zonen, listen Sie die Zone auf, die tatsächlich eingehenden Verkehr trägt, und prüfen Sie die installierte Dienstdefinition, denn ein Dienstname beschreibt eine Menge von Ports und sagt nichts darüber, ob der Listener dieses Servers dazu passt.

firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all
firewall-cmd --info-service=openvpn

Wenn der Listener tatsächlich UDP 1194 in dieser Zone ist, öffnen Sie gezielt diesen Port und Transport und machen Sie danach dieselbe konkrete Regel dauerhaft, nachdem Sie sie getestet haben. Prüfen Sie auch quellenbasierte Zuweisungen, denn eine an einen Quellbereich gebundene Zone kann den Verkehr abfangen, bevor die Schnittstellen-Zone ihn überhaupt sieht.

Autorisieren Sie das entschlüsselte Ziel separat

Eine Verbindung zu einem Dienst, der auf dem VPN-Server selbst läuft, ist Local-Input-Richtlinie. Eine Verbindung, die an einen anderen Host im LAN weitergeleitet wird, braucht Weiterleitungsrichtlinie, im Kernel aktivierte Weiterleitung und eine Antwortroute — drei getrennte Anforderungen, die Menschen oft zu einer zusammenfassen. Moderne firewalld-Policy-Objekte beschreiben gerichteten Verkehr zwischen einer Eingangs- und einer Ausgangszone, und dort ist der richtige Ort, auszudrücken, welche VPN-Quellen welche privaten Dienste erreichen dürfen.

Definieren Sie die erlaubten Quellen ausdrücklich und lassen Sie alles andere in eine Ablehnung fallen. Eine Freigabe für den äußeren Dienst ist nicht diese Richtlinie, so sehr das Zonenlayout auch danach aussehen mag.

Warum Vertrauen in die Schnittstelle die falsche Abkürzung ist

Die Tunnel-Schnittstelle in eine Zone zu legen, deren Ziel alles akzeptiert, lässt den gesamten entschlüsselten Verkehr zu jedem Dienst durch, den der Host anbietet, auch zu solchen, die Sie nicht geprüft haben. Die vertrauenswürdige Zone auf einer laufenden Maschine nachträglich restriktiv umzuwidmen ist schlimmer, weil andere Schnittstellen und Quellbereiche bereits von ihrer Bedeutung abhängen können und ihr Verhalten ändern, wenn Sie sie bearbeiten. Wenn Sie eine enge Richtlinie brauchen, legen Sie eine an; zweckentfremden Sie keine gemeinsam genutzte Zone.

Halten Sie außerdem die Zonenzuweisung des Tunnels über die Komponente stabil, die diese Konfiguration besitzt. Geht die Zuweisung beim Neustart verloren, entsteht ein Fehler, der wie ein Firewall-Regelproblem aussieht und in Wahrheit ein Persistenzproblem ist.

Prüfen Sie drei Dinge, darunter eine Ablehnung

Testen Sie die äußere Verbindung von außen, testen Sie einen autorisierten inneren Dienst von einem verbundenen Client und testen Sie einen Dienst, der unerreichbar bleiben soll. Der dritte Test ist der, der eine Richtlinie von einem Nebeneffekt unterscheidet, und genau ihn lassen Menschen aus, weil alles zu funktionieren scheint. Antwortet der abgelehnte Dienst, haben Sie eine Zone statt eines Dienstes zugelassen.

Notieren Sie Zone, Port, Transport und Policy-Objekt in den Notizen des Servers. Sonst beginnt die nächste Änderung an diesem Host bei derselben Vermutung.