OpenVPN verbindet, aber nichts fließt: Finden Sie die Schicht, an der das Paket fällt

OpenVPN meldet verbunden, und es fließt kein Verkehr, ein Satz, der mindestens fünf unabhängige Fehler abdeckt. Firewall-Regeln zu ändern, bevor Sie wissen, welche Schicht versagt, vervielfacht die Unbekannten und hinterlässt dem nächsten Techniker ein Durcheinander. Arbeiten Sie stattdessen vom Prozess nach außen, denn jeder Schritt unten räumt entweder eine Stufe ab oder verengt, wo das Paket stirbt. Die Reihenfolge zählt hier: Ein Mitschnitt, der entnommen wird, bevor Sie wissen, welche Adresse gebunden ist, beweist etwas, nur nicht das, was Sie brauchen.

Der Socket ist entweder gebunden oder nicht

Ein Dienst, der aktiv meldet, kann trotzdem an eine Adresse oder einen Transport gebunden sein, den Sie nie beabsichtigt haben. Fragen Sie den Socket selbst: ss -lunp listet UDP-Listener auf und ss -ltnp TCP, und die Spalte, die sich zu lesen lohnt, ist die lokale Adresse, nicht der Zustand.

Eine leere Antwort bedeutet meist eines von drei Dingen: Der Prozess hat nach dem Start beendet, er hat eine andere Konfigurationsdatei geladen, oder er lauscht auf einer anderen Adresse als der, die gewählt wird.

ss -lunp | grep 1194
ss -ltnp | grep 1194

Eine local-Direktive nagelt den Listener auf eine einzige Adresse fest, sodass ein Client, der anderswo auf demselben Host zielt, abgelehnt wird, während der Dienst von außen noch gesund aussieht. Ein Instanzname kann auch auf eine Datei zeigen, die Sie nie bearbeitet haben, was auf Hosts mit zwei parallel laufenden Profilen vorkommt.

Fangen Sie das äußere Paket ab, nicht den Tunnel

Filtern Sie auf der physischen Schnittstelle und dem echten Port, mit Ihrer eigenen Schnittstelle eingesetzt: tcpdump -ni eth0 udp port 1194. Ausgehende Pakete, auf die nichts zurückkommt, deuten auf das hin, was oberhalb sitzt: Anbieterfilterung, ein NAT-Gerät oder eine Gegenstelle, die nicht die ist, die Sie denken. Stille in beide Richtungen deutet auf Client-Routing oder eine lokale Firewall hin. Antworten, die ohne Tunnel-Fortschritt ankommen, deuten auf den Steuerkanal hin, also eine Schlüssel- oder Cipher-Abweichung, nicht auf Filterung.

Fangen Sie beide Richtungen ab und halten Sie die Datei kurz. Ein langer Mitschnitt begräbt die interessanten drei Sekunden, und die Antwort liegt fast immer im ersten Austausch.

Zähler zuerst, Trace nur wenn sie lügen

Beginnen Sie mit den Zählern, denn sie kosten nichts. Entweder nft list ruleset oder iptables -L -n -v beantwortet die einzige Frage, die hier zählt: Hat die Regel gepasst? Die Reihenfolge entscheidet das Ergebnis, denn der erste Treffer gewinnt, weshalb ein breites DROP vor einem späteren ACCEPT dieses ACCEPT tot lässt und weshalb das Anhängen einer Regel so selten etwas repariert.

Auch die Zuständigkeit bringt Leute ins Stolpern. Der Kernel schreibt lokal erzeugte Pakete dem Prozess zu, der den Socket geöffnet hat, und OpenVPN läuft normalerweise als root, sodass eine Regel, die auf eine gewöhnliche Benutzer-ID zielt, den Verkehr des Tunnels selbst nie sieht. Prüfen Sie die besitzende UID, bevor Sie entscheiden, dass die Regel falsch ist.

Nur wenn die Zähler mehrdeutig bleiben, ist ein Log den Lärm wert, und dann nur für einen schmalen Ausschnitt: eine iptables-Regel, die die Rate begrenzt und ihren Logzeilen ein Präfix gibt, oder eine nftables-Regel mit meta nftrace set 1, während nft monitor trace läuft. Ein Trace benennt die Kette und die Regel, die das Paket angenommen oder verworfen hat. Entfernen Sie beides danach und halten Sie Payload-Logging heraus.

Prüfen Sie auch den Transport. Ein auf TCP beschränkter Firewall-Dienst sagt nichts über einen UDP-Listener auf dieser Nummer, sodass eine korrekt gelesene Regel trotzdem jedes Paket verwerfen kann.

Routing und der Weg zurück

Ein angenommenes Paket, das trotzdem verschwindet, braucht eine Untersuchung seines Zielpfads. ip route get meldet die für eine Adresse gewählte Route, und Reverse-Path-Filterung kann eine Antwort verwerfen, die über eine Schnittstelle ankommt, die die Haupttabelle nie wählen würde. Das Symptom sieht genau wie ein Firewall-Drop aus, weshalb diese Prüfung vor einer weiteren NAT-Regel kommt.

Prüfen Sie auf einem Gateway die Weiterleitung und die forward-Kette statt der input-Kette. Bestätigen Sie dann, dass die Gegenseite weiß, wie sie die Quelladresse erreicht, denn ein funktionierender ausgehender Pfad, auf dem nichts zurückkommt, ist in beiden Fällen Stille.

Was die Aufzeichnung sagen muss

Notieren Sie für jede Änderung die getestete Stufe, den gelesenen Beleg und den Zählerwert auf beiden Seiten davon. Diese Notiz macht "es funktioniert jetzt" bei der nächsten Überprüfung überlebensfähig.

Zwei Abkürzungen halten die Notiz ehrlich. Ein Paket, das den Host nie verlassen hat, kann nicht von einer Regel anderswo verworfen worden sein, so überzeugend die Konfiguration der Gegenseite auch aussieht. Ein Paket, das hinausging und zurückkam, verschiebt die Frage über die Netzwerkschicht, wo Firewall-Zähler Ihnen nichts mehr zu sagen haben.