VPN-Port stumm? Listener, Bind-Adresse oder Host-Firewall

Das VPN antwortet auf seinem Port gar nicht, und die beiden möglichen Ursachen verlangen entgegengesetzte Reparaturen: Entweder hat kein Prozess den Socket geöffnet, oder der Socket existiert und etwas zwischen den Maschinen hält die Pakete auf. Ein einziger Befehl entscheidet die erste Hälfte dieser Frage, deshalb gehört er vor jede Firewall-Regel. Die Reihenfolge unten entfernt pro Schritt eine Erklärung, statt eine weitere Vermutung hinzuzufügen. Genau das Raten zwischen den beiden macht aus einer zehnminütigen Diagnose einen ganzen Abend.

Gehen Sie davon aus, dass Sie sich am Server anmelden können und dass der Client ein echtes Profil und kein Scanner ist. Beide Annahmen zählen, denn eine allgemeine Sonde kann eine protokollspezifische Frage nicht beantworten.

Existiert der Socket überhaupt

Beginnen Sie mit der Auskunft des Dienstes über sich selbst: ob er hochkam und, nützlicher, welcher Fehler beim ersten Start auftrat. Ein Parse-Fehler, ein fehlender Schlüssel oder ein Bind-Fehler verhindern, dass der Listener je entsteht, und der Prozess kann so leise beenden, dass eine Statuszeile mehrdeutig gelesen wird. Eine Unit, die aktiv meldet, ist für sich genommen kein Beweis, denn der Hauptprozess kann leben, während die Komponente, die den Port binden sollte, schon aufgegeben hat.

systemctl status openvpn-server@server --no-pager
journalctl -u openvpn-server@server -n 30 --no-pager
ss -lunp

Die Socket-Auflistung ist die Tatsache, auf der der Rest der Diagnose ruht. Lesen Sie die Spalte der lokalen Adresse statt nur den Port, denn in dieser Spalte zeigen sich Loopback-Bindungen und Bindungen an die falsche Schnittstelle. Ein Listener, der auf 127.0.0.1 existiert, läuft einwandfrei und bleibt für Ihr Notebook unsichtbar.

Auf welcher Adresse und Familie der Socket antwortet

Zwei Fehler sehen vom Client aus gleich aus und erklären die meisten Meldungen "nicht erreichbar". Ein Server, der an die Loopback-Adresse gebunden ist, nimmt nie Verkehr von einer anderen Maschine an, und ein Server, der nur an eine IPv4-Adresse gebunden ist, antwortet nie einem Client, der die IPv6-Adresse desselben Hosts wählt. Vergleichen Sie die Adresse in der Socket-Tabelle Zeichen für Zeichen mit der Adresse, die der Client tatsächlich wählt, bevor Sie etwas über Richtlinien annehmen.

Die Auflistung auf einen Port zu beschränken hält sie lesbar, wenn der Host mehrere Dienste betreibt. Der sport-Filter nimmt den Port zusammen mit dem Transport, den Sie testen:

ss -lun 'sport = :51820'
ss -ltnp 'sport = :1194'

Die Protokollspalte ändert die ganze Antwort

Die Socket-Tabelle schlüsselt sowohl nach Protokoll als auch nach Port, und das sind zwei unabhängige Einträge. Ein Dienst, der auf 1194 TCP antwortet, sagt nichts darüber aus, ob etwas auf UDP 1194 lauscht, und der Client nutzt immer nur eines von beiden. Bestätigen Sie, welchen Transport die Serverkonfiguration wählt und welchen das Clientprofil sendet, und suchen Sie dann genau diese Zeile.

UDP hat eine zweite Eigenheit: Eine nicht authentifizierte Sonde ist kein Fehler, den der Dienst beantworten muss. Ein Scan, der den Port als stumm meldet, hat die Zurückhaltung des Dienstes gemessen, nicht seine Erreichbarkeit, also testen Sie mit dem echten Client und Profil.

Ein Versuch, drei Stellen zum Nachsehen

Machen Sie von einem freigegebenen Client genau einen Versuch und notieren Sie die Uhrzeit sekundengenau. Lesen Sie dann drei Quellen für dieses Zeitfenster: die Netzwerkregel oder Konsole des Anbieters, die Firewall-Zähler oder das Protokoll des Hosts und das eigene Protokoll des Dienstes. Das einmal zu tun macht die drei Berichte vergleichbar, und es kostet weniger, als einen Versuch zu wiederholen, dessen Zeitstempel niemand notiert hat.

Die beiden Ergebnisse weisen in entgegengesetzte Richtungen. Wenn kein Paket den Host erreicht hat, verwirft der Pfad es, und der Listener ist irrelevant. Wenn das Paket am Socket ankam und der Dienst es ablehnte, ist der Pfad in Ordnung, und die Antwort liegt in Protokoll, Kryptografie oder Zugangsdaten. Einen Port für einen Dienst zu öffnen, der bereits eine Verbindung angenommen hat, macht die nächste Diagnose schwerer, nicht leichter.

Die Stufe benennen, bevor Sie eine Regel ändern

Eine Verhandlung, die beginnt, und eine Authentifizierung, die scheitert, sind ein Fehler, und ein Tunnel, der steht, während die Weiterleitung stockt, ist ein ganz anderer. Die Stufe zuerst zu benennen hält die Reparatur eng: Ein Zugangsdatenproblem wird nicht durch eine Firewall-Regel behoben, und ein Datenpfadproblem nicht durch einen Neustart.

Nutzen Sie die engste Diagnose, die die Frage beantwortet. Eine vorübergehende Paketbeobachtung auf einem Port unter Kontrolle eines Administrators ist ein vernünftiges Werkzeug; die gesamte Firewall abzuschalten nicht, weil das Ergebnis dann nicht mehr zuzuordnen ist. Die ss-Dokumentation deckt die oben verwendeten Filter ab, und das ist ein billigerer erster Schritt als jede Aufzeichnung. Notieren Sie, welchen der beiden Zweige Sie bewiesen haben, und der nächste Fall beginnt bei einer bekannten Antwort.