Server oder Client: welche OpenVPN-Unit auf einem Pi mit Doppelrolle

Zwei OpenVPN-Instanzen teilen sich einen Pi: Eine nimmt Roaming-Nutzer auf, die andere wählt sich beim Upstream-Anbieter ein. Lesen Sie Unit-Namen und Verzeichnis, bevor Sie eine der beiden neu starten.

Zwei OpenVPN-Prozesse laufen auf einem Pi, der zugleich Roaming-Nutzer aufnimmt und einen Upstream-Anbieter erreicht, und sie teilen außer der Hardware fast nichts. Der eine lauscht auf eingehende Tunnel, während der andere nach außen wählt. Jeder liest sein eigenes Verzeichnis, und jeder hat seinen eigenen Fehlermodus. Die falsche Unit neu zu starten ist der häufigste Weg, auf dem eine Client-Korrektur stattdessen den Listener aus dem Tritt bringt.

Ordnen Sie den Unit-Namen dem Verzeichnis zu, das er lädt

Upstream 2.6 liefert zwei Template-Units, [email protected] und [email protected]. Das Server-Template startet in /etc/openvpn/server und lädt von dort %i.conf. Das Client-Template startet in /etc/openvpn/client. Eine Instanz namens roaming kann an beiden Stellen gleichzeitig existieren, als Server und als Client, mit zwei unabhängigen Konfigurationen und keiner Verbindung zwischen ihnen außer der Zeichenkette.

Fragen Sie systemd statt das Dateisystem, weil Paketbauer Drop-ins hinzufügen, die das Arbeitsverzeichnis oder die Argumente ändern können, die die Binärdatei erhält.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

Der erste Befehl listet jede instanziierte Unit auf, auch die, die fehlgeschlagen und geladen geblieben sind. Der zweite gibt die Unit-Datei samt jeder Überschreibung aus. Der dritte ist der schnellste Weg, die zwei Fakten zu sehen, die die Frage entscheiden: das Verzeichnis, in dem der Prozess startet, und der Konfigurationspfad, der ihm übergeben wurde.

Entscheiden Sie nach Paketrichtung, nicht nach Interface-Namen

Eine Server-Instanz besitzt einen lauschenden Socket und nimmt Verbindungen an. Ihr verschlüsselter Transport ist lokaler Eingang und lokaler Ausgang auf dem Pi, während der Verkehr, den sie für Nutzer weiterleitet, dem Weiterleitungspfad folgt und einer anderen Regelmenge gehorcht. Eine Client-Instanz besitzt in diesem Sinne keinen Listener: Sie wählt einen Peer, deshalb ist ihr verschlüsselter Transport lokaler Ausgang zum Underlay.

Dieser Unterschied sagt Ihnen, wohin eine Regel gehört. Eine Regel, die auf ein Interface innerhalb einer Forward-Kette passt, erlaubt nur Verkehr, den das Routing bereits ausgewählt hat; sie wählt die Route nie aus. Wenn die Pakete eines Roaming-Nutzers über den falschen Weg hinausgehen, ist die zu prüfende Kette forward, nicht output.

Sehen Sie sich die Sockets an, bevor Sie theoretisieren. Ein an udp/1194 gebundener Server zeigt einen lauschenden Socket. Der Client zeigt eine Zuordnung zur Adresse des Anbieters und nichts, was lauscht.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

Die Standardroute der einen Instanz kann die Antworten der anderen abfangen

Ein redirect-gateway, das der Upstream-Client schiebt, installiert eine Standardroute, die mit allem anderen auf der Maschine konkurriert, einschließlich der Antworten, die der Server an Roaming-Nutzer sendet. OpenVPN legt eine Ausnahme für die eigene Peer-Adresse an, damit der Tunnel erreichbar bleibt, aber diese Ausnahme sagt nichts über ein Telefon in einem Hotelnetz aus.

Das Symptom ist meist asymmetrisch. Der Handshake wird abgeschlossen, der Client meldet verbunden, und der Verkehr stirbt nach dem ersten Antwortpaket. Quellbasiertes Policy-Routing oder eine Paketmarkierung, die mit --mark auf der Server-Instanz gesetzt wird, hält die beiden Ströme getrennt; keines von beiden ist für sich ein vollständiges Regelwerk, und beide brauchen gültige Routen in der Tabelle, die sie auswählen.

Prüfen Sie die lokale Entscheidung statt den Tunnelzustand, weil der Kernel Quelle und Interface auswählt, bevor OpenVPN das Paket sieht.

ip route get 203.0.113.44
ip rule show

Starten Sie eine Rolle neu und beweisen Sie, dass die andere überlebt hat

Die Reihenfolge zählt, wenn beide Rollen vom selben Underlay abhängen. Starten Sie den Client zuerst neu, wenn die Upstream-Route existieren muss, bevor Nutzerverkehr weitergeleitet werden kann, und starten Sie den Server zuerst neu, wenn Sie nur seinen Listener oder seinen Pool ändern. Bestätigen Sie anschließend so oder so beide Units, denn ein fehlgeschlagener Neustart kann die andere Rolle mit veraltetem Zustand weiterlaufen lassen.

Schreiben Sie die Abbruchbedingung vor der Änderung auf: Blockiert der Verlust des Upstream-Tunnels die Roaming-Nutzer, oder fällt er auf den eigenen Uplink des Pi zurück? Auch DNS und IPv6 brauchen eine ausdrückliche Antwort, denn ein geschobener Resolver überlebt oft die Route, die ihn nützlich gemacht hat.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

Akzeptieren Sie die Änderung nur, wenn drei Dinge gleichzeitig gelten: Eine neue eingehende Verbindung wird abgeschlossen, eine weitergeleitete Anwendung erreicht ihr Ziel über den vorgesehenen Ausgang, und beide Prozesse melden noch immer ihren erwarteten Peer. Wenn eines der drei scheitert, haben Sie die falsche Instanz oder die falsche Route geändert, und der nächste Schritt ist, die Unit erneut zu lesen, statt irgendetwas anderes neu zu starten.

Ähnliche Artikel