Warum Ihre VPN-Schnittstelle ihre firewalld-Zone immer wieder verlässt

Sie fügen tun0 der richtigen Zone hinzu, die Anwendung beginnt zu funktionieren, und beim nächsten Neuverbinden verdampft die Korrektur. Derselbe Befehl erneut ausgeführt funktioniert, was es so aussehen lässt, als hätte firewalld es vergessen. Es hat nichts vergessen; etwas mit einem stärkeren Anspruch auf diese Schnittstelle hat sie neu zugewiesen.

Die Zone hält, bis die Schnittstelle neu erzeugt wird

Eine firewalld-Zonenzuweisung für eine Schnittstelle ist eine Bindung, und Bindungen hängen an dem Schnittstellenobjekt, wie es jetzt existiert. Ein VPN-Client, der das Gerät abbaut und neu erzeugt, erzeugt ein neues Objekt, und das neue beginnt mit dem, was die zuweisende Komponente sagt. Deshalb wiederholt sich das Symptom bei jedem Neuverbinden und nicht bei jedem Paket.

Dieselbe Logik erklärt das Verhalten beim Neustart: Laufzeitbindungen überleben keinen Neustart, und dauerhafte Bindungen gelten nur für Geräte, die firewalld für sein Eigentum hält.

Bevor Sie etwas ändern, finden Sie heraus, welche Komponente die Zone zuweist.

Lesen Sie drei Dinge, bevor Sie etwas ändern

Notieren Sie die Zone, die die Schnittstelle derzeit hat, die aktiven Zonen mit ihren Schnittstellen und die dauerhafte Schnittstellenliste für die Zone, die Sie beabsichtigen. Führen Sie diese Abfragen vor der Änderung, nach einem Neuverbinden und nach einem Neustart aus. Der Vergleich der drei Ergebnisse sagt Ihnen, ob die Bindung ersetzt, ignoriert oder nur verspätet angewendet wird. Wenn die dauerhafte Liste das Gerät bereits nennt, während die Laufzeitzone widerspricht, überschreibt etwas Ihre Änderung.

Notieren Sie bei jedem Schritt auch den tatsächlichen Gerätenamen, denn ein Tunnel, der heute auf tun0 landet, kann morgen auf tun1 landen.

Eine gespeicherte Bindung an einen generischen Namen ist keine Identitätsprüfung, und zwei Minuten Aufzeichnung sparen eine Stunde Raten.

Wenn NetworkManager die Verbindung besitzt

Wenn NetworkManager die VPN-Verbindung verwaltet, trägt ihr Profil die Zone und übergibt sie an firewalld, wenn die Verbindung aktiviert wird. Eine dauerhafte firewalld-Schnittstellenbindung für dasselbe Gerät kann dann ignoriert werden, weil NetworkManager der Eigentümer ist. Setzen Sie die Zone auf der Verbindung, und bestätigen Sie, dass Sie das VPN-Profil bearbeiten und nicht eine unabhängige physische Verbindung oder einen temporären Eintrag.

Das Ändern dieser Eigenschaft kann eine aktive Verbindung sofort beeinflussen.

Halten Sie einen Verwaltungspfad verfügbar und lesen Sie die Richtlinie der Zielzone, bevor Sie sie anwenden. Das Bearbeiten des ZONE-Felds einer ifcfg-Datei ist nur dort korrekt, wo diese Datei noch die Konfigurationsquelle ist.

Wenn firewalld die Bindung besitzt

Für einen eigenständigen Tunnel mit bewusst stabilem Schnittstellennamen ist eine dauerhafte Schnittstellenänderung das richtige Werkzeug. Wenden Sie sie über das Neuladen oder den Lebenszyklus an, den Ihr Deployment nutzt, und prüfen Sie dann den Laufzeitzustand, weil eine nur dauerhafte Bearbeitung die Absicht beschreibt und nicht das, was aktiv ist. Beide können so lange auseinanderfallen, wie das Neuladen dauert.

Wenn der Schnittstellenname dynamisch ist, pflegen Sie die Zuweisung über den Lebenszyklus der Verbindung, statt mit dem Tunnel zu rennen, der den Namen zuerst beansprucht.

Stecken Sie die Schnittstelle nicht in trusted, nur damit die Anwendung funktioniert.

Testen Sie das Neuladen, das Neuverbinden und den Neustart

Eine Änderung ist erst fertig, wenn sie alle drei übersteht.

Laden Sie zuerst neu, denn dort verschwinden Bearbeitungen, die nur zur Laufzeit gelten. Verbinden Sie dann den Tunnel neu, denn dort verliert eine ersetzte Schnittstelle ihre Bindung. Starten Sie dann neu, denn dort zeigt sich endlich eine Eigentümerabweichung. Notieren Sie die Zone in jeder Phase und vergleichen Sie sie mit der Absicht, die Sie notiert haben, und vermerken Sie, welcher Schritt den Unterschied erzeugt hat.

Wenn die Zone korrekt ist und die Anwendung trotzdem scheitert, liegt das Problem in den Regeln der Zone oder in einer quellbasierten Klassifizierung und nicht in der Zugehörigkeit. Die firewalld-Dokumentation zu Verbindungen und Schnittstellen ist die Referenz dafür, wie Eigentum funktionieren soll.

Schreiben Sie den Eigentümer, den Wert und das erwartete Ergebnis ins Runbook, und die nächste Neuzuweisung wird erklärbar sein.