Zwei Dienstadressen an einem OpenVPN-Client: iroute und lo

Die Anwendung antwortet auf ihrer Tunneladresse, und die Adresse, die Sie dafür dokumentiert haben, führt nirgendwohin. Nichts im OpenVPN-Protokoll beschwert sich, der Peer erscheint verbunden, und der Hub listet genau einen Client. Die Lücke besteht darin, dass eine zweite Adresse an einem Client zwei getrennte Tatsachen sind: Der Host muss sie besitzen, und der Hub muss wissen, welcher Peer sie besitzt. Behandeln Sie das eine ohne das andere, und der Verkehr stirbt entweder am Hub oder kommt ohne Route nach Hause an.

Das Alias ist lokal, der Besitz ist entfernt

Eine Tunneladresse wird ausgehandelt, sodass beide Seiten sie während des Handshakes lernen. Eine zusätzliche Dienstadresse wird überhaupt nicht ausgehandelt, weshalb ihr Hinzufügen am Hub für sich genommen nichts ändert. Der Client kann die Adresse sofort besitzen, und der Server schickt diesen Verkehr trotzdem auf seinen Standardpfad oder verwirft ihn. Es müssen zwei Datensätze an zwei verschiedenen Stellen angelegt werden.

Auf dem Client gehört die Adresse dem Host, und Loopback ist der natürliche Ort für eine Dienstidentität, die nie auf einer physischen Verbindung erscheinen sollte. Am Hub ist die Peer-zu-Präfix-Zuordnung eine separate Deklaration, die nur der Server liest. Keiner der Datensätze setzt den anderen voraus.

Halten Sie die beiden Bereiche auch in Ihren Notizen getrennt. Adressen in einem Beispiel sind Dokumentationswerte, und sie mit einem echten LAN zu überlappen ist der schnellste Weg, eine funktionierende Einrichtung kaputt aussehen zu lassen.

Fügen Sie die Adresse dauerhaft am Client hinzu

Legen Sie die Dienstadresse mit einem Host-Präfix auf Loopback, damit der Host sie als lokale Eingabe behandelt und nicht als Subnetz, das erreicht werden muss. ip address add 10.66.0.10/32 dev lo erledigt das für eine Adresse, und die Wiederholung des Befehls für eine zweite Adresse modelliert zwei Dienste.

Führen Sie das als einmaligen Test aus und verschieben Sie es dann in das, was die Netzwerkkonfiguration des Hosts besitzt, denn eine Ergänzung zur Laufzeit verschwindet beim Neustart, und Duplikate sammeln sich über Wiederverbindungen hinweg. Eine systemd-Unit, die nach dem Netzwerk geordnet ist, ist eine Option, ein Netzwerkmanager der Distribution eine andere. Was auch immer Sie wählen, die Adresse muss existieren, bevor die Anwendung bindet, sonst startet der Dienst auf dem falschen Socket. Prüfen Sie mit ip address show dev lo nach einem Neustart und nicht nach dem manuellen Befehl.

Binden ist eine von der Adressierung getrennte Entscheidung. Eine Anwendung, die auf jeder Adresse lauscht, nimmt Verkehr auf Schnittstellen an, die Sie nie beabsichtigt haben, also richten Sie sie auf die spezifische Dienstadresse. Dann hat die lokale Eingaberichtlinie etwas Genaues zum Abgleichen.

Fordern Sie sie in der CCD-Datei an, die der Hub tatsächlich liest

Auf dem Server geht die Besitzdeklaration in die Datei pro Client, die durch den authentifizierten Common Name ausgewählt wird, im Verzeichnis, das durch client-config-dir benannt ist. Die Zeile ist iroute 10.66.0.10 255.255.255.255, eine pro Adresse, und sie sagt dem Server, welcher Peer Verkehr für dieses Ziel erhalten soll.

Zwei Details brechen dies lautlos. Der Dateiname muss mit dem Namen übereinstimmen, den der Server tatsächlich verwendet, und der unterscheidet sich, wenn username-as-common-name im Spiel ist. Und iroute wirkt nur im TUN-Modus mit konfiguriertem Client-Konfigurationsverzeichnis, sodass dieselbe Zeile in einer gebrückten Bereitstellung nichts tut. Fügen Sie Zeilen zur vorhandenen Datei hinzu, statt sie zu ersetzen, da sie bereits eine feste Adresse oder Push-Optionen enthalten kann. Die OpenVPN-2.6-Referenz dokumentiert sowohl das Verzeichnis als auch die Besitzdirektive.

Auch der Kernel des Hubs braucht einen Weg zu diesen Zielen, damit lokal erzeugter Verkehr in den Tunnelprozess gelangt. route 10.66.0.10 255.255.255.255 in der Serverkonfiguration deckt Verkehr ab, den der Server selbst erzeugt, während andere Clients push "route 10.66.0.10 255.255.255.255" brauchen, um das Ziel selbst zu lernen.

Routing und Autorisierung bleiben getrennt. Eine gepushte Route sagt einem Client, wohin er Pakete senden soll, und gewährt nichts; der Dienst muss den Aufrufer weiterhin zu seinen eigenen Bedingungen akzeptieren.

Prüfen Sie Eingaberichtlinie und Rückweg

Ein an das Alias adressiertes Paket kommt am besitzenden Host als lokale Eingabe an, also ist die Frage, ob die lokale Firewall diese Quelle und diesen Port zulässt. Erlauben Sie den spezifischen Dienstport aus dem VPN-Quellbereich, statt die ganze Adresse zu öffnen.

Antworten brauchen einen Weg zurück zum Aufrufer. Für einen Aufrufer im normalen Tunnelpool existiert dieser Weg bereits, weil das Tunnelgerät ihn trägt. Ein Aufrufer hinter einem anderen gerouteten Netz braucht auch die Rückroute dieses Netzes, und hier verlieren asymmetrische Setups Pakete.

Achten Sie auf einen zweiten Listener am selben Port, der an eine andere Adresse gebunden ist, denn der Kernel liefert an den passenden Socket, und die Ergebnisse wirken zufällig. Prüfen Sie mit ss -lntp und bestätigen Sie, dass die gebundene Adresse das Dienstalias ist. Source-NAT ist hier nicht erforderlich, und es hinzuzufügen verbirgt die Aufruferidentität, auf die Ihre Protokolle angewiesen sind.

Testen Sie Adressen und Besitz getrennt

Testen Sie in zwei Schritten. Bestätigen Sie zuerst, dass der besitzende Host den Dienst über sein Alias von sich aus erreicht, was Bindungs- und Firewallprobleme vom Routing trennt. Testen Sie dann von einem echten VPN-Aufrufer mit der eigenen Authentifizierung der Anwendung. Wenn das erste gelingt und das zweite scheitert, liegt das fehlende Teil auf der Hub-Seite.

Prüfen Sie auch die Fehlermodi, die eine Verbindung überleben: Das Alias bleibt zugewiesen, wenn der Tunnel unten ist, und der Hub behält seine Route, wenn der Peer fehlt. Keines der Objekte allein beweist, dass der Dienst erreichbar ist, weshalb der Zwei-Schritt-Test einen einzelnen Ping vom Laptop schlägt.