Der Tunnel steht, das Protokoll meldet verbunden, und eine Anwendung erreicht trotzdem nichts. Auf einem Linux-Client heißt das meist, dass die Firewall der Distribution einen Pfad filtert, den der VPN-Client nie verwaltet hat. Zwei Verwaltungen können gleichzeitig aktiv sein, jede mit eigenen Vorstellungen von der Schnittstelle, der Zone und der Richtung des Verkehrs. Den Eigentümer zu bestimmen, bevor man etwas ändert, ist schneller, als Regeln zu probieren, bis etwas funktioniert.

Verwaltung und Backend ermitteln

Beginnen Sie mit dem, was tatsächlich geladen ist, nicht mit dem, was installiert ist. Eine Distribution kann firewalld, ufw und einen einfachen nftables-Dienst mitbringen, und nur einer davon besitzt den laufenden Regelsatz. Die Pakete koexistieren friedlich, und eine Regel, die über das falsche Frontend eingegeben wird, erreicht nie den Kernel. Lesen Sie den aktiven Dienst und dann den Regelsatz, den er erzeugt hat.

Das Backend ist genauso wichtig wie das Frontend. Eine firewalld-Installation kann je nach Version und Konfiguration nftables oder das alte iptables-Backend steuern, und beide liefern unterschiedliche Prüfausgaben. Schreiben Sie Distribution, Version und Backend ins Ticket, bevor Sie Ihr System mit irgendeiner Anleitung vergleichen.

Richtung und Schnittstelle abstimmen

Eine ausgehende Client-Anfrage, ein eingehender Listener und ein weitergeleitetes Paket durchlaufen verschiedene Hooks, und eine Regel für eines deckt die anderen nicht ab. Eine Zone, die das lokale LAN erlaubt, enthält oft nicht die Tunnelschnittstelle oder den VPN-Adresspool. Eine Tunnelschnittstelle landet normalerweise in der Standardzone, die häufig strenger ist als die Zone des physischen Adapters. Diese Diskrepanz erklärt, warum Surfen im LAN funktioniert und in dem Moment aufhört, in dem der Tunnel hochkommt.

Fragen Sie, welche Richtung fehlgeschlagen ist, bevor Sie eine Regel wählen. Eine Anwendung, die nicht nach außen verbinden kann, braucht den Ausgangspfad, während ein eingehender Dienst den Eingangspfad an der Tunnelschnittstelle braucht. Eine Regel in der falschen Kette erzeugt eine Änderung, die angewendet aussieht und überhaupt nichts bewirkt.

Halten Sie die Regeleigentümer im Einklang

Der Hook eines VPN-Clients, eine Container-Laufzeit und der Dienst der Distribution können alle das Netzwerk verändern, und sie koordinieren sich nicht miteinander. Von Hand eingegebene Regeln verschwinden beim nächsten Neuladen, und Regeln, die in die Kette einer Verwaltung eingefügt werden, können in einer Reihenfolge ausgewertet werden, die Sie nicht beabsichtigt haben. Verwenden Sie die dauerhafte Konfiguration der Verwaltung und prüfen Sie den resultierenden Regelsatz statt der Datei, die Sie geschrieben haben. Die ganze Firewall abzuschalten, weil ein Dienst nicht erreichbar ist, tauscht ein kleines Problem gegen ein großes.

Enge Zähler sind der billige Weg, den abgewiesenen Fluss zu finden. Eine Protokollregel, die auf ein Ziel und einen Port beschränkt ist, zeigt, ob das Verwerfen lokal geschieht, ohne fremden Verkehr mitzuschneiden. Entfernen Sie die Protokollregel, wenn die Untersuchung endet, denn sie ist Diagnose und keine Richtlinie, und die Zonendokumentation von firewalld erklärt, wie Schnittstellen und Dienste zusammenwirken.

Prüfen Sie die Korrektur, ohne die Abschottung zu verlieren

Prüfen Sie den angewendeten Zustand mit der Verwaltung, die ihn besitzt, und verwenden Sie Befehle, die zum notierten Backend passen. Die folgende Auflistung geht davon aus, dass firewalld zuständig ist; setzen Sie das Äquivalent für nftables oder ufw ein, statt alle auszuführen. Werkzeuge in einer Sitzung zu mischen, ist der Weg, auf dem eine Maschine mit zwei widersprüchlichen Regelsätzen endet.

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=trusted --list-all
sudo nft list ruleset | head -40

Der erste Befehl nennt die Zonen und die ihnen zugewiesenen Schnittstellen, was zeigt, wo der Tunnel tatsächlich gelandet ist. Der zweite gibt die Regeln und Dienste einer Zone aus, sodass Sie sehen, ob die VPN-Schnittstelle überhaupt abgedeckt ist. Die nftables-Auflistung ist die Grundwahrheit für das verwendete Backend, und eine Regel, die nur in einer Konfigurationsdatei existiert, erscheint dort nicht. Vergleichen Sie die drei Ausgaben mit der hinzugefügten Regel, und die Diskrepanz benennt sich meist selbst.

Wiederholen Sie dann die ursprüngliche Anfrage und das geforderte Fehlerverhalten. Eine neu funktionierende Website reicht nicht, wenn dieselbe Änderung die Abschottung des Clients entfernt hat, testen Sie also auch einen ungeschützten Pfad. Notieren Sie Verwaltung, Backend, Schnittstelle und Zweck der Regel, denn ein Paket-Update, das eine zweite Verwaltung wiederbelebt, baut sonst das ganze Durcheinander neu auf.

Ähnliche Artikel