Port 1194 bereits belegt: Wem gehört dieser OpenVPN-Socket?

Starten Sie dasselbe Serverprofil zweimal, und der zweite Prozess endet mit einem Adress-belegt-Fehler für Port 1194. Im üblichen Fall hat der Diagnosestart den Konflikt erzeugt, und die ursprüngliche Instanz bedient die Clients weiterhin einwandfrei. Diese Geschichte erklärt einen großen Teil dieser Meldungen, und es lohnt sich, sie zu erkennen, bevor irgendetwas neu gestartet wird. Sie ist auch die billigste Variante der Lösung.

Der Fehler beschreibt eine lokale Bindung und nichts darüber hinaus. Er ist kein Beweis dafür, dass ein Anbieter den Port blockiert, dass ein Client das falsche Passwort gesendet hat oder dass die Zertifikatskette beschädigt ist.

Lesen Sie den genauen Bindefehler

Zwei Fehler aus dieser Familie bedeuten unterschiedliche Dinge, und ihre Verwechslung schickt Sie auf die falsche Ebene. „Adresse bereits in Verwendung“ bedeutet, dass ein anderer Socket den angeforderten Endpunkt hält. „Adresse nicht verfügbar“ bedeutet, dass die angeforderte Adresse auf diesem Host noch nicht existiert, was ein Bereitschaftsproblem und kein Duplikat ist.

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

Kopieren Sie den Fehlertext, bevor Sie etwas ändern, einschließlich der genannten Adresse und des Ports. Ein Dienst, der auf das Erscheinen einer Schnittstelle wartet, protokolliert den zweiten Fehler wiederholt und bindet dann erfolgreich, sobald die Adresse existiert; ein Dienst, der den ersten Fehler protokolliert, wird nie erfolgreich sein, bis das Duplikat behoben ist. Zu notieren, welchen der beiden Sie gesehen haben, kostet nichts und erspart eine vergeudete Schnittstellensuche.

Erfassen Sie den Socket, nicht den Port

Eine Portnummer ist ein unvollständiges Inventar. Der Endpunkt besteht aus einem Transport, einer Adressfamilie, einer lokalen Adresse und einem Port, alles innerhalb eines einzigen Netzwerk-Namespace. Ein UDP-Listener und ein TCP-Listener auf derselben Nummer sind verschiedene Sockets, und zwei Prozesse auf derselben Nummer in verschiedenen Namespaces treffen nie aufeinander.

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

Führen Sie zuerst den Transport aus, den das Profil tatsächlich verwendet. Schauen Sie dann auf die Spalte der lokalen Adresse statt nur auf die Nummer: Eine Wildcard-Bindung deckt jede lokale Adresse ab, sodass ein zweiter Prozess, der eine bestimmte Adresse anfordert, damit kollidieren kann, obwohl die ausgegebenen Zeichenfolgen unterschiedlich sind. Socket-Wiederverwendungsoptionen und Plattformregeln entscheiden über das genaue Ergebnis, weshalb dies eine Beobachtung und keine Regel sein sollte, die Sie auf jede Bereitstellung anwenden.

Finden Sie heraus, welcher Prozess ihn besitzt

Numerische Endpunkte plus Prozessinformationen identifizieren den Besitzer, wenn Ihre Rechte es erlauben, und der Besitzer ist das, was Sie brauchen, nicht der Programmname. Zwei OpenVPN-Prozesse können unterschiedliche Profile ausführen, und derjenige, der den Listener hält, kann derjenige sein, den Sie am wenigsten vermuten.

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

Vergleichen Sie Ihre Funde mit dem Dienstmanager, einer Container-Laufzeit oder einem Terminalprozess, der von einem früheren Test übrig geblieben ist. Das Fehlen von Prozessdetails ist kein Beweis dafür, dass der Socket keinen Besitzer hat; es bedeutet meist, dass die Abfrage ohne ausreichende Berechtigung lief. Ebenso entkräftet eine reine TCP-Auflistung keinen UDP-Konflikt, prüfen Sie also den im Fehler genannten Transport. Ein Prozessname allein verrät nie, welches Profil geladen wurde, und das Profil entscheidet über den Endpunkt.

Ein Besitzer oder zwei geplante Instanzen

Wenn die Bereitstellung einen Server vorsieht, halten Sie einen Lebenszyklus-Besitzer und lesen das Journal dieser Instanz oder das konfigurierte Protokoll, statt eine zweite Kopie zu starten, um sie zu beobachten. Wenn ein kontrollierter Vordergrundlauf wirklich nötig ist, stoppen Sie die verwaltete Instanz bewusst und berücksichtigen Sie vorher die Clients, die sie bedient.

Wenn zwei Instanzen beabsichtigt sind, geben Sie ihnen getrennte Listener und getrennt alles andere: Adresspools, virtuelle Schnittstellen, Routing-Richtlinie und Konfigurationsverantwortung. Ein anderer Port allein trennt nur den Socket, und die beiden Server streiten weiterhin um denselben Pool und dieselben Routen.

Drei Abkürzungen verdienen es, genannt zu werden, weil sie in jedem Thread zu diesem Fehler auftauchen. Töten Sie keine beliebige PID, die wie der Übeltäter aussieht. Aktivieren Sie keine Socket-Freigabe, um die Meldung zum Schweigen zu bringen. Stellen Sie ein Serverprofil nicht auf eine clientartige ungebundene Konfiguration um, weil dadurch der Bindefehler verschwindet; der Server wird dann auf eine Weise unerreichbar, die schwerer zu diagnostizieren ist als der ursprüngliche Konflikt.

Das Ändern des Ports ist nur dann eine legitime Antwort, wenn der neue Listener Teil eines genehmigten Designs ist, das die Weiterleitungsregel und den Client-Endpunkt einschließt. Wenn diese nicht aktualisiert wurden, haben Sie den Konflikt an einen Ort verschoben, an dem ihn niemand findet.

Überprüfen Sie die Bindung vor allem anderen

Bestätigen Sie nach der begrenzten Korrektur, dass die vorgesehene Instanz aktiv ist, dass ihr Listener auf dem erwarteten Transport erscheint und dass ein Client sich verbinden kann. Eine erfolgreiche Bindung schließt nur die lokale Socket-Phase ab; sie bescheinigt nichts über die Authentifizierung oder über den Datenverkehr, nachdem der Tunnel steht.

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

Wenn der Socket vorhanden ist und der Client weiterhin scheitert, liegt das verbleibende Problem stromabwärts und der Bindefehler ist jetzt Geschichte. Diese Trennung ist der ganze Sinn davon, zuerst die genaue Meldung zu lesen: ein Fehler, eine Ebene, ein Besitzer. Lesen Sie es so, und das nächste Symptom beginnt bei einem bekannten Zustand statt bei einer Vermutung.