Warum nftables den OpenVPN-Verkehr zwischen Clients nicht sieht

Zwei Clients auf einem Server tauschen Dateien aus, die Übertragung gelingt, und jede Forward-Regel, die Sie auf den Tunnel richten, meldet null Pakete. Die Regeln sind nicht kaputt, und die Kette liegt nicht falsch. Ist die Weiterleitung zwischen Peers aktiviert, wird das Paket innerhalb des Serverprozesses zugestellt, und der Host-Stack wird nie zum Router, also hat die Kernel-Firewall nichts zu zählen. Diesen Unterschied zu verstehen entscheidet, ob Sie die Abkürzung behalten oder den Weg durch den Kernel neu bauen.

Ein Paket durch den Server verfolgen

In einem gerouteten Tunnel übergibt der Daemon das entschlüsselte Paket jedes Clients an das Tunnelgerät. Von dort routet der Host es, der Forward-Hook läuft, und eine Regel, die auf das Tunnelgerät passt, kann den Verkehr zählen oder verwerfen. Das ist der Weg, den die meisten Firewall-Beispiele annehmen.

Die Abkürzung nimmt den Host aus der Mitte. Das entschlüsselte Paket einer Sitzung wird innerhalb des Daemons an eine andere Sitzung übergeben, und das innere Paket wird nie auf dem Tunnelgerät ausgegeben oder vom Host geroutet. Gekapselter Verkehr überquert weiterhin die physische Schnittstelle, also sieht ein äußerer Mitschnitt beschäftigt aus, während die inneren Regeln still bleiben. Ein Mitschnitt auf dem Tunnelgerät zeigt überhaupt nichts, was jeden überrascht, der die Übertragung dort beobachten will. Diese Asymmetrie ist der schnellste Weg, die Abkürzung von außerhalb des Daemons zu erkennen.

Der Zählertest, der klärt, welcher Weg lief

Hängen Sie einen Zähler an die Regel, die greifen sollte, führen Sie eine Übertragung zwischen zwei Clients aus, die diese Regel blockieren müsste, und lesen Sie den Zähler danach ab.

sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward

Gelingt die Übertragung und bleibt der Zähler auf null, hat der Kernel diese Pakete nie behandelt, und kein Regelumbau ändert das. Wiederholen Sie denselben Test gegen einen Dienst auf dem Server selbst, denn dieser Fluss durchläuft tatsächlich den Host-Stack, und sein Zähler bewegt sich. Der Vergleich der beiden Ergebnisse liefert die Antwort.

Zwei Details verhindern eine Fehlmessung. Ein in ein Kettenlabel geschriebener Schnittstellenname filtert für sich genommen nichts, weil der Abgleich über Schnittstellenfelder in den Regeln läuft. Und ein gebrücktes Layer-2-Design verhält sich noch einmal anders: Dort teilen die Clients eine Broadcast-Domain, also ist Peer-Erkennung zu erwarten und kein Routing-Fehler.

Ein Switch ist keine Zugriffsliste

Das ist der Teil, der einen Nachmittag kostet. Weiterleitung zwischen Peers ist eine einzige Ein-oder-Aus-Einstellung, und solange sie an ist, ist der Daemon der einzige Weiterleitungspunkt. Die Host-Firewall kann nicht ausdrücken, wer wen erreichen darf, und Dateien pro Client machen den Schalter nicht zur Richtlinienmatrix.

Brauchen Sie Regeln pro Peer, bleibt die Wahl zwischen dem Verzicht auf die Abkürzung und dem Verzicht auf die Host-Firewall als Steuerung. Sie abzuschalten stellt die Kernel-Weiterleitung wieder her, was IP-Weiterleitung auf dem Server und ausdrückliche Regeln für die gewünschten Flüsse erfordert. Sie anzulassen heißt, die Richtlinie lebt in der Konfiguration des Daemons, was praktisch alle Peers oder keine Peers bedeutet.

Getrennte Serverprozesse mit eigenen Adresspools und Ports sind der gangbare Mittelweg. Jeder Prozess trägt genau eine Zugriffsentscheidung, also können zwei Gruppen unterschiedliche Regeln haben, ohne eine Richtlinienmatrix. Der Host kann zwischen den Pools routen, wenn das beabsichtigt ist, und dann sieht die Firewall diese Flüsse, weil sie den Host überqueren. Der Preis sind zusätzliche Ports, zusätzliche Zertifikate und ein Profil pro Gruppe.

Den Weiterleitungspunkt wählen

Wählen Sie Kernel-Weiterleitung, wenn die Firewall die Richtlinienmaschine ist, wenn Sie Protokollierung pro Fluss brauchen oder wenn Abrechnung zählt. Der Preis ist Durchsatz durch den Host-Stack und mehr Regeln zu pflegen. Der Vorteil ist, dass jedes vorhandene Werkzeug, von Zählern bis Fluss-Exporteuren, den Verkehr wieder beschreibt. Auf einem kleinen Server ist dieser Preis unsichtbar; auf einem ausgelasteten Relay nicht.

Wählen Sie Weiterleitung im Prozess, wenn Peer-Verkehr entweder ganz erlaubt oder ganz verboten ist und der Server dafür dimensioniert ist. Der Preis ist, dass Zähler, Warteschlangendisziplinen und Verbindungsverfolgung die inneren Flüsse nicht mehr beschreiben; das ist nur akzeptabel, wenn sich später niemand darauf verlässt.

Was auch immer Sie wählen, schreiben Sie es neben die Firewall-Regeln. Ein Regelsatz, der Peer-Verkehr zu erlauben scheint, während der Daemon ohnehin entscheidet, führt den Nächsten in die Irre, der eine fehlgeschlagene Übertragung debuggt. Wer nur die Regeln liest, wird annehmen, der Kernel sei das Tor.

Was vor Regeländerungen zu prüfen ist

Lesen Sie die Konfiguration, die der Server tatsächlich geladen hat, nicht die Datei, von der Sie glauben, sie bearbeitet zu haben, und prüfen Sie, ob die Peer-Option vorhanden ist. Haben Sie sie geändert, stellen Sie sicher, dass der Dienst neu geladen und nicht nur eine Datei auf der Platte neu geschrieben hat.

Wiederholen Sie dann den Test mit einem Fluss von Client zu Server, um zu belegen, dass die Regel überhaupt greift, und prüfen Sie die gepushten Routen, denn eine fehlende Route sieht von der Clientseite genau wie eine Firewall-Sperre aus. Ändern Sie die Regelreihenfolge erst, wenn Sie wissen, welcher Weiterleitungspunkt die Entscheidung besitzt.