Sollte Ihr OpenVPN-Client nobind oder einen festen Port verwenden?

Zwei Profile, die sich in einer einzigen Zeile unterscheiden, verhalten sich in dem Moment anders, in dem ein zweiter Client auf demselben Host startet. Das eine trägt nobind und nimmt jeden lokalen Port, den der Kernel vergibt; das andere reserviert 1194, und die zweite Instanz stirbt mit einer bereits verwendeten Adresse. Diese Zeile entscheidet, wer den Quellport wählt, was wiederum entscheidet, ob das Profil mit irgendetwas anderem auf dem Rechner koexistieren kann. Drei Fragen klären es, und die erste beantwortet die meisten Profile, bevor Sie die anderen beiden erreichen.

Was nobind tatsächlich überspringt

Standardmäßig bindet der Client vor dem Wählen einen lokalen Socket, und der lokale Port ist 1194, sofern das Profil nichts anderes sagt. nobind entfernt diese Reservierung, sodass der Stack beim Verbindungsaufbau einen unbenutzten Port zuweist. Es ist ein Opt-out und kein Standard, und ein Client ohne die Zeile hält 1194, weshalb eine nicht festgelegte zweite Instanz genau deshalb kollidiert. Die meisten ausgelieferten Clientprofile tragen die Direktive aus diesem Grund, und dass eine Beispieldatei etwas tut, ist nicht dasselbe, wie wenn der Mechanismus es standardmäßig täte.

Was sich nicht ändert, ist die Gegenseite. Der Server lauscht weiterhin dort, wo das Profil sagt, dass er lauscht, und der Zielport in der Konfiguration ist weiterhin der Zielport. Ein dynamischer Quellport ändert die Rücksendeadresse Ihres eigenen Sockets und nichts am Socket des Servers.

Er verbirgt auch nichts. Ihre öffentliche Adresse ist die, zu der der Pfad sie übersetzt, das Paket durchquert weiterhin das lokale Netz, und wer dieses Netz betreibt, sieht weiterhin einen Fluss. nobind ist weder ein Datenschutzmerkmal noch eine Firewall-Umgehung.

Drei Bedingungen, die es entscheiden

Eine Frage entscheidet die anderen beiden, also beantworten Sie sie, bevor Sie irgendetwas bearbeiten. Wenn der Peer nach außen wählt, verfeinern die übrigen Fragen nur eine bereits getroffene Entscheidung. Wenn er eingehende Verbindungen annimmt, macht keine Anpassung des lokalen Ports ihn erreichbar.

Geht die Verbindung von diesem Peer aus? Wenn er nach außen wählt, ist ein dynamischer Quellport harmlos und meist vorzuziehen, weil die Antwort demselben Fluss zurück folgt. Wenn er auf eingehende Verbindungen wartet, macht ein dynamischer Port ihn unerreichbar, es sei denn, etwas davor veröffentlicht den Port. Diese eine Antwort trennt jedes Clientprofil von jedem Serverprofil.

Filtert der Pfad auf den Quellport? Eine strenge Regel, die für einen bekannten Port geschrieben wurde, erzwingt einen ausdrücklichen lokalen Port, und das Profil sollte festhalten, welche Regel es erfüllt. Die meisten Netze filtern nur nach dem Ziel, daher ist diese Bedingung seltener als die erste. Wo sie gilt, überwiegt sie die Präferenz für einen dynamischen Port.

Teilen sich mehrere Instanzen den Host? Ein einzelner fester Port kann nicht zwei davon bedienen, und eine neu gestartete Instanz findet 1194 möglicherweise noch im Zustand des Schließens. Dynamische Ports beseitigen diesen Konflikt, ohne irgendetwas anderes zu ändern. Wenn Sie dies nicht sicher beantworten können, nehmen Sie Ja an und lassen Sie den Kernel wählen.

Wo ein fester Port die richtige Antwort ist

Manche Netze filtern sowohl nach dem Quellport als auch nach dem Ziel, sodass ein Betreiber eine Regel geschrieben haben könnte, die nur Verkehr von einem bekannten Port durchlässt. Den lokalen Port festzulegen ist dann richtig, und das Profil sollte einen Kommentar tragen, der die erfüllte Regel nennt. Festlegen aus Symmetrie zum Serverport ist kein Grund, denn die beiden Zahlen haben nichts miteinander zu tun. Wenn die Festlegung nur existiert, weil eine Vorlage sie hatte, löschen Sie sie.

Andernfalls kauft ein fester Port Ärger: zwei Clients auf einem Rechner können nicht beide 1194 halten, und der zweite scheitert mit einem Fehler, der auf den Port statt auf das Profil zeigt. Ein Container, der schnell neu startet, stößt an dieselbe Wand. Die Reparatur ist die Direktive, die die ausgelieferten Profile bereits enthielten.

Server und Client sind nicht symmetrisch

OpenVPN-2.6-Handbuch stellt nobind neben lport, was das Argument in einer Zeile ist: Eine Option sagt, der Kernel wählt, die andere sagt, Sie wählen. Ein dynamischer lokaler Port funktioniert nur für den Peer, der nach außen wählt, weil die antwortende Seite den Port nicht im Voraus kennen kann. Deshalb erzeugt das Kopieren eines Clientprofils auf einen Server einen Listener, den niemand erreichen kann.

Auf einem Host mit mehreren Netzwerkschnittstellen ist die Adresse eine vom Port getrennte Entscheidung. Eine bestimmte lokale Adresse zu binden und einen bestimmten Port zu binden sind zwei verschiedene Einstellungen, und ein Server mit zwei Uplinks legt meist beides fest. Ein Client, der beides festlegt, hat dieselbe Starrheit ohne jeden Nutzen übernommen.

Die Zusammenfassung handelt von Rollen, nicht von Sicherheit: Wer nach außen wählt, kann bei seiner eigenen Quelle flexibel sein, und wer antwortet, kann es nicht. Keine der beiden Wahlmöglichkeiten ändert, was die Gegenseite über Ihre Identität erfährt. Deshalb taucht die Direktive in Client-Beispielen auf und fast nie in Server-Beispielen.

Prüfen Sie den Port, den der Kernel gewählt hat

Lesen Sie nach dem Verbinden den Socket statt die Konfiguration, denn die Konfiguration nennt die Absicht und der Socket nennt, was geschehen ist. Die Fakten, die es festzuhalten lohnt, sind der lokale Port, der entfernte Endpunkt und ob noch etwas lauscht. Auf einem Linux-Host sind alle drei einen Befehl entfernt.

ss -unp | grep openvpn
ss -lunp | grep openvpn
sudo lsof -nP -i | grep openvpn

Ein Client mit nobind zeigt einen hohen lokalen Port und den konfigurierten Remote-Port, was die erwartete Form ist. Ein Server zeigt einen lauschenden Socket auf seinem konfigurierten Port, und wenn dieser Socket fehlt, ist das Profil entweder kein Listener oder konnte nicht binden. Wenn ein Fluss existiert, aber keine Pakete zurückkommen, vergleichen Sie den gewählten Quellport mit jedem Portfilter auf dem Pfad, bevor Sie das Profil bearbeiten. Ändern Sie eine Sache, verbinden Sie erneut, und lesen Sie den Socket wieder.