Ein Pi, zwei OpenVPN-Instanzen: was jede Unit liest
Zwei OpenVPN-Daemons auf einem Pi lesen unterschiedliche Konfigurationsdateien und verlassen das System über unterschiedliche Hooks. Ordnen Sie jede Instanz zu und testen Sie dann den Nutzlastpfad getrennt.
Zählen Sie die OpenVPN-Prozesse, bevor Sie ein Profil anfassen. Ein Pi, das Roaming-Nutzer aufnimmt und zugleich einen Upstream-Dienst anwählt, betreibt zwei Daemons, und jeder liest eine Konfigurationsdatei, die durch den von Ihnen eingegebenen Instanznamen gewählt wird. Die paketierten Vorlagen geben jedem Daemon dann sein eigenes Arbeitsverzeichnis, seine eigene Laufzeit-Statusdatei und sein eigenes Tunnelgerät. Machen Sie diese Trennung falsch, verbringen Sie einen Abend damit, eine korrekte Einstellung in einer Datei zu ändern, die der laufende Prozess nie öffnet.
Jeder Instanzname wählt seine eigene Datei
In den mit OpenVPN 2.6 ausgelieferten Unit-Dateien tragen die Startargumente einen Instanz-Platzhalter, der aus dem Text nach dem @-Zeichen gefüllt wird. Die Server-Vorlage läuft aus dem Server-Konfigurationsverzeichnis und löst ihr Argument gegen %i.conf dort auf, während die Client-Vorlage dasselbe aus dem Client-Verzeichnis tut. Also [email protected] liest admits.conf im Server-Verzeichnis, und [email protected] liest uplink.conf im Client-Verzeichnis, und keiner der beiden Namen hat in dem anderen Verzeichnis eine Bedeutung.
Bestätigen Sie die Zuordnung auf der Maschine, statt anzunehmen, dass das Paket die Upstream-Standardwerte behalten hat. Ein Distributions-Drop-in darf das Arbeitsverzeichnis oder das Konfigurationsargument direkt ersetzen.
systemctl cat [email protected]
systemctl cat [email protected]Lesen Sie die Zeile WorkingDirectory und das Konfigurationsargument in dieser Ausgabe, denn die aktivierte Unit ist das Einzige, was entscheidet, welche Datei geladen wird. Ein Drop-in, das --config an ExecStart anhängt, gewinnt gegen die Vorlage, selbst wenn der Vorlagenpfad richtig aussieht. Fragen Sie nach den Fragment- und Drop-in-Pfaden, wenn Sie wissen wollen, ob eine lokale Überschreibung im Spiel ist. Wenn beide Rollen auf eine Datei auflösen, haben Sie einen einzigen Prozess, der sowohl Server als auch Client sein will, und die spätere Option in dieser Datei gewinnt still.
Lokaler Transport und weitergeleitete Nutzlast treffen verschiedene Hooks
Die verschlüsselte Verbindung des Servers zu jedem Roaming-Nutzer entsteht auf dem Pi selbst, daher verlassen seine äußeren Antworten den lokalen Ausgabe-Hook. Die Verbindung des Clients zu seinem Upstream-Peer ist ebenfalls lokal erzeugte Ausgabe, auch wenn sie ein entferntes Netz erreicht. Weitergeleitete Nutzlast ist eine dritte Kategorie, und der Kernel ordnet sie erst zu, nachdem er bereits ein Ausgabegerät für das Paket gewählt hat.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
Eine Regel, die eine ausgehende Schnittstelle innerhalb einer Weiterleitungskette trifft, kann ein Paket erlauben oder verwerfen, das das Routing dieser Schnittstelle bereits zugewiesen hat, aber sie wählt die Schnittstelle nie aus. Wenn ein Host einen Tunnel beendet und einen anderen aufbaut, sind die Richtlinie, die Nutzlast in den Upstream-Tunnel schickt, und die Richtlinie, die die eigenen verschlüsselten Antworten des Pi schützt, getrennte Entscheidungen. Sie landen zufällig auf derselben physischen Netzwerkkarte, weshalb sie verwechselt werden.
Diese Unterscheidung erklärt einen häufigen Halbfehler. Nutzer verbinden sich, der Handshake schließt ab, und ihr Verkehr geht trotzdem den falschen Weg hinaus, weil der Handshake lokal war und die Nutzlast weitergeleitet wurde und nur eines von beidem jemals getestet wurde.
Eine importierte Route kann Antworten an Ihre Nutzer verschlucken
Die Sicherheitseinstellung des Client-Profils entscheidet, was der Upstream in die Routing-Tabelle des Pi schieben darf, und eine breite Umleitung ist die Option, die einen funktionierenden Host mit zwei Rollen zu einem kaputten macht. Wenn die geschobene Route die öffentlichen Adressen der Roaming-Nutzer abdeckt, können die Antworten, die der Server an sie erzeugt, der neuen Route in den Upstream-Tunnel folgen, statt über das Underlay zu verlassen. Leute bestätigen oft, dass der Tunnel zum Anbieter noch funktioniert, und hören dort auf, weil dieser Verkehr der eigene Transport des Tunnels ist und weiterfließt, während sich alles andere falsch verhält.
Quell- oder markierungsbasierte Richtlinien sind der Weg, auf dem die beiden Ströme getrennt bleiben. OpenVPNs Linux-Markierungsoption versieht die eigenen verschlüsselten Pakete eines Daemons mit einer Firewall-Markierung, die eine Routingregel dann in eine eigene Tabelle schicken kann. Quelladressen funktionieren genauso gut, wenn die äußeren Antworten des Servers immer von einer Underlay-Adresse ausgehen. Beide Ansätze brauchen gültige Routen in der gewählten Tabelle und eine Ausnahme für den Endpunkt des Anbieters, sonst kommt der Tunnel selbst nicht mehr hoch.
Fragen Sie den Kernel nach dem Weg, den eine Antwort tatsächlich nehmen würde, bevor Sie irgendeine Regel schreiben. Die folgenden Adressen sind Platzhalter für eine Underlay-Adresse des Pi und die öffentliche Adresse eines Roaming-Nutzers.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Prüfen Sie die Trennung und stoppen Sie dann eine Rolle nach der anderen
Testen Sie drei Ströme getrennt, denn ein funktionierender Handshake beweist nichts über die anderen zwei. Nehmen Sie eine neue eingehende Verbindung an, schicken Sie eine erlaubte Anwendung durch den Upstream-Ausgang und bestätigen Sie, dass beide Prozesse ihre eigenen Peers weiterhin erreichen.
Stoppen Sie dann die Client-Rolle und beobachten Sie, was die Server-Rolle behält. Das ist der billigste Weg, eine Routing- oder Markierungsregel zu finden, die für eine Instanz gedacht war und auf beide angewendet wurde.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerWas Sie sehen wollen, ist der noch gebundene Listener, das weiterhin vorhandene Tunnelgerät und ein Protokoll ohne neue Fehler, während die Client-Rolle aus ist. Wenn das Stoppen des Clients auch die Antworten des Servers an bestehende Nutzer abschneidet, teilen die beiden Rollen etwas, das auf eine von ihnen hätte begrenzt werden müssen. Notieren Sie, welche Instanz, welche Konfigurationsdatei und welcher Flow-Eigentümer von jeder Änderung betroffen war, weil die nächste Person, die diesen Host debuggt, sonst dieselbe Entdeckung von Null wiederholt.