OpenVPN: lokale Adresse gegen Tunneladresse – zwei verschiedene Sockets

Der Client weigert sich zu starten und beklagt, dass er keine lokale Adresse binden kann, und die naheliegende Lösung sieht so aus, als solle man ihn auf die Tunneladresse zeigen lassen, die er erwartet. Das kann nicht funktionieren, und der Grund lohnt sich zu verstehen: Bevor der Tunnel existiert, gibt es keine innere Adresse, und der Socket, der den Server kontaktiert, muss zuerst existieren. Es sind zwei verschiedene Adressen im Spiel, und nur eine davon lässt sich lokal wählen.

Der Bind-Fehler nennt eine lokale Adresse

Wenn OpenVPN meldet, dass es keine lokale Adresse binden kann, spricht es vom Transport-Socket: dem UDP- oder TCP-Endpunkt, der die verschlüsselte Verbindung zum Peer trägt.

Eine ausdrückliche local-Direktive fordert den Daemon auf, diesen Socket an eine bestimmte lokale Adresse zu binden. Die Adresse muss im Netzwerk-Namespace vorhanden sein, in dem der Prozess läuft, und sie muss in dem Moment zuweisbar sein, in dem der Client startet.

Eine öffentliche Adresse, die an einem Router oder am Cloud-Rand übersetzt wird, ist keine lokale Adresse, die der Daemon binden kann, auch wenn es die Adresse ist, die der Server sieht. Dieser Unterschied erklärt, warum ein Profil zu Hause funktioniert und auf einer Cloud-Instanz scheitert. Er erklärt auch, warum es nicht hilft, die öffentliche Adresse einer Loopback-Schnittstelle hinzuzufügen, denn dann käme der Transport von einer Adresse, an die das Netz nicht zurücksenden kann. Lies die Schnittstellenliste, bevor du das Profil bearbeitest.

Was local und remote tatsächlich auswählen

remote benennt den Peer, der kontaktiert werden soll. local bindet das nahe Ende desselben Sockets. nobind überlässt dem Betriebssystem die Wahl von lokaler Adresse und Port, weshalb Clients hinter Heimroutern normalerweise ohne beide Direktiven funktionieren.

Keine der beiden Direktiven hat etwas mit der Adresse im Tunnel zu tun.

In einem Container oder Netzwerk-Namespace gilt dieselbe Regel mit engeren Grenzen: Die Adressen des Hosts sind innen nicht vorhanden, eine aus der Host-Konfiguration kopierte local-Zeile scheitert also aus einem ganz anderen Grund als eine falsche Adresse.

ip -brief address show
ip route get 203.0.113.10

Die innere Adresse kommt vom Server

Die Adresse im Tunnel wird ausgehandelt oder zugewiesen, nachdem der Steuerkanal aufgebaut ist. Bei einem dynamischen Pool entscheidet der Server beim Verbinden darüber, bei client-spezifischer Konfiguration kann sie pro Identität fest sein.

local mit einer inneren Adresse zu schreiben, bittet den Server nicht, diese Adresse zu vergeben. Im besten Fall scheitert das Binden; im schlechtesten findet der Client eine unabhängige Host-Adresse mit demselben Wert und beginnt, sie für den Transport zu verwenden.

Auch die Schnittstellen, die man lesen muss, sind andere. ifconfig-Parameter und Pool-Konfiguration beschreiben das Innere, während remote, local, proto und nobind das Äußere beschreiben. Die beiden Listen getrennt zu halten erklärt fast jedes verwirrende Beispiel, das du in einem Forum findest. Das OpenVPN 2.6-Handbuch dokumentiert sie aus genau diesem Grund in getrennten Abschnitten.

Die Falle: ein voller Tunnel, der seinen eigenen Transport einfängt

Sobald der Tunnel steht und die Standardroute trägt, dürfen die Pakete, die ihn aufrechterhalten, nicht in ihn hineingeroutet werden. Das ist ein Routing- und kein Adressierungsproblem, und der Daemon löst es, indem er eine spezifischere Route zur eigenen Adresse des Servers über das ursprüngliche Gateway installiert.

Wenn du den Transport an eine bestimmte lokale Adresse bindest und später den Weg änderst, den diese Adresse nimmt, kann die äußere Verbindung sich verirren, während das Innere konfiguriert bleibt. Der Tunnel meldet weiterhin verbunden, weil das Innere in Ordnung ist. Nur der Transport ist kaputt, und deshalb lesen sich die Logs wie Widersprüche.

Die Symptome sehen dann aus wie ein Tunnel, der verbindet und einfriert, oder einer, der in einer Schleife ohne brauchbaren Fehler neu verbindet. Prüfe die Route zur Adresse des Peers, bevor du irgendetwas im Tunnel prüfst, und bestätige, dass die gebundene lokale Adresse noch zur erwarteten Schnittstelle gehört.

Eine Gewohnheit, die die Verwirrung vermeidet

Lies jede Adresse in einem Profil und entscheide vor dem Bearbeiten, zu welcher Schicht sie gehört.

Wenn sie das ferne Ende des Transports benennt oder sein nahes Ende bindet, ist sie eine äußere Adresse und muss vor dem Start existieren. Wenn sie beschreibt, was im Tunnel geschieht, stammt sie vom Server oder von der Topologie, und keine lokale Direktive kann sie ersetzen.

Schreib die beiden Listen in die Deployment-Notizen neben dem Profil. Die nächste Fehlersuche beginnt dann mit der Schicht statt mit einer Vermutung.