Vorgefertigtes tun unter OpenVPN: die beiden Eigentumsmodelle im Vergleich

Jemand hat tun1 vorab angelegt, das Profil sagt dev tun1, und die Verbindung baut trotzdem nicht auf. Der Name, der auf dem Host existiert, sagt fast nichts aus, denn das Anhängen hängt vom Namespace, vom Gerätetyp, davon, wer den Link besitzt, und davon ab, was der Daemon tun darf. Die Wiederverwendung eines Geräts erzwingt außerdem eine Entscheidung, die die Standardkonfiguration verbirgt: welche Komponente die Adressen und Routen schreibt. Die Fehlermodi der beiden Anordnungen unterscheiden sich weit stärker als die Konfigurationszeilen, also entscheiden Sie, bevor Sie ein Profil bearbeiten.

Ein Name ist keine Anbindung

dev tun1 verlangt von OpenVPN diese benannte Schnittstelle, und traditionelle Userspace-Builds werden versuchen, sie zu öffnen. Folgt der Name nicht dem üblichen tun- oder tap-Muster, braucht das Profil zusätzlich ein passendes dev-type, denn der Typ wird nie aus einer Zeichenkette abgeleitet. Ein TAP-Gerät ist kein TUN-Gerät mit anderem Etikett: Das falsche anzuhängen schlägt entweder ganz fehl oder erzeugt einen Link, der Frames überträgt, die niemand erwartet. Prüfen Sie den Typ vor allem anderen, denn jede spätere Prüfung setzt voraus, dass beide Seiten darin übereinstimmen. Bestätigen Sie danach, dass der Prozess das Gerät tatsächlich öffnen kann und es nicht nur sieht.

dev tun1
dev-type tun

Die Netzwerkschnittstelle und /dev/net/tun sind verschiedene Objekte: Das eine ist ein Link innerhalb eines Namespace, das andere das Zeichengerät, das ein Userspace-Programm zum Anhängen verwendet. Linux-TUN/TAP-Dokumentation beschreibt diesen Anhangpfad und die Eigentumsregeln für persistente Geräte. Eine Root-Shell, die ip link ausführen kann, beweist nur, dass die Shell Privilegien hat, nicht dass der Daemon sie hat. Der Besitz des Geräteknotens, das Fähigkeitsset des Dienstes und der Benutzer, unter dem er läuft müssen alle zusammenpassen, bevor das Öffnen gelingt.

Ein Gerät, das existiert und sich nicht öffnen lässt, ist ein Eigentumsproblem, kein Routingproblem. Behandeln Sie es bei der Fehlersuche als solches, sonst geht der Nachmittag für Routingtabellen drauf, die nie das Problem waren.

Wer den Link konfiguriert: zwei Eigentumsmodelle

Im ersten Modell konfiguriert OpenVPN Adressen und Routen, während es die Verbindung aufbaut. Das ist das Standardverhalten und das am leichtesten nachvollziehbare, weil eine einzige Komponente den Zustand erzeugt und wieder entfernt. Im zweiten Modell besitzt ein externer Manager die Schnittstelle, und ifconfig-noexec hindert OpenVPN daran, seine Adresskonfigurationsbefehle auszuführen, und übergibt die Parameter stattdessen an Skripte. Der Manager muss dann die korrekte lokale und Peer-Konfiguration selbst anwenden, was mehr Arbeit ist, als der Optionsname vermuten lässt. Die Wahl zwischen beiden ist eine Frage dessen, wer den Link ändern darf, während er aktiv ist.

ifconfig-noexec deckt nur Adressen ab: Die Routing-Tabelle bleibt unberührt, und die Routenkonfiguration gehört zu route-noexec. Behandeln Sie die beiden Direktiven als getrennte Steuerungen mit getrennten Eigentümern, denn eine zu setzen und die andere anzunehmen ist eine häufige Ursache halb konfigurierter Links. Wählen Sie genau einen Eigentümer pro Ebene, Adressen an einer Stelle und Routen an einer Stelle. Ein Netzwerkmanager und ein VPN-Helfer, die beide Adressen schreiben, führen dazu, dass ein Trennen Zustand löscht, auf den die andere Seite noch angewiesen ist.

Prüfen Sie das Gerät aus dem Namespace, auf den es ankommt

Prüfen Sie das Gerät aus dem Namespace, in dem der VPN-Prozess läuft, nicht aus dem, in dem sich Ihre Shell zufällig befindet. Die beiden folgenden Befehle beantworten verschiedene Fragen, und der Unterschied zeigt sich, wenn ein Host eine Schnittstelle sieht, die ein Container nicht sehen kann. Führen Sie sie in der angegebenen Reihenfolge aus, denn der zweite ergibt erst Sinn, wenn Sie wissen, ob der Link überhaupt existiert.

ip -details link show dev tun1
ip tuntap show

Der erste Befehl gibt den Link so aus, wie der Kernel ihn sieht, einschließlich Flags und Schnittstellentyp, und so bestätigen Sie, dass dies das gemeinte Gerät ist. Der zweite listet persistente tun/tap-Einträge auf, die existieren, ohne dass ein Prozess sie hält. Eine Schnittstelle, die auf ihren vorgesehenen Eigentümer wartet, ist eine andere Situation als ein laufender Tunnel, der an ein anderes VPN angebunden ist, und nur die zweite erklärt, warum Ihr eigener Anhang fehlschlägt. Finden Sie den Prozess, der das Gerät hält, bevor Sie etwas ändern, denn ein persistenter Eintrag und eine belegte Schnittstelle haben verschiedene Lösungen.

Multiqueue-Unterstützung ist eine bestimmte Treiberanordnung mit eigenen Anforderungen, keine Erlaubnis für unabhängige Prozesse, eine Schnittstelle gemeinsam zu nutzen. Die laufende Sitzung eines anderen Eigentümers ist ein Koordinationsproblem, und keine Profilbearbeitung löst es.

Zwei verschiedene Arten von Persistenz

Kernel-Persistenz und persist-tun beschreiben Lebensdauern, die man leicht verwechselt und teuer verwechselt. Ein persistentes Gerät existiert unabhängig von jedem Prozess, übersteht also ein Stoppen und kann beim nächsten Start wiederverwendet werden. persist-tun hält Ressourcen über unterstützte weiche Resets innerhalb eines OpenVPN-Prozesses hinweg, ein viel kürzerer Horizont. Keines von beiden verspricht, dass das Stoppen des Dienstes Routen und Adressen an Ort und Stelle lässt, und eine Schnittstelle, die sichtbar bleibt, ist kein Beweis für eine funktionierende verschlüsselte Sitzung.

Bestätigen Sie auch das Backend, denn eine vorgefertigte Schnittstelle sagt nichts darüber, welche Implementierung sie öffnen wird. Community-Builds mit dem direkten Datenpfad werden versuchen, sie zu verwenden, sofern das Design nichts anderes sagt. Wo eine Version den Schalter unterstützt, disable-dco wählt sie stattdessen den Userspace-Pfad; ältere Engines und andere Clients haben keine solche Direktive, also halten Sie die Versionsbedingung neben der Option, statt anzunehmen, dass sie gilt.

Was bricht, wenn nur der Start getestet wird

Eine Eigentumsvereinbarung kann den ersten Test bestehen und den letzten nicht, was den Start allein zu einer schlechten Prüfung macht. Beobachten Sie stattdessen zwei Übergänge: einen weichen Reset und ein vollständiges Stoppen, gefolgt von einem Start.

systemctl status openvpn-client@lab
ip -details link show dev tun1

Der Start ist der leichte Fall: Die Unit kommt hoch, der Link erscheint, und die Statusausgabe nennt das geladene Profil. Die Anbindung ist der Moment, in dem der Daemon das Gerät öffnet, also führen Sie die Linkprüfung aus, nachdem die Unit als aktiv meldet, nicht davor. Existiert der Link, während der Status noch aktiviert, sehen Sie ein persistentes Gerät, an das noch niemand angehängt hat, keinen funktionierenden Tunnel. Schicken Sie echten Verkehr durch den Link, bevor Sie weitermachen, denn eine angebundene Schnittstelle ohne nutzbare Route ist immer noch ein Fehler.

kill -SIGHUP $(pidof openvpn)
journalctl -u openvpn-client@lab -n 40
systemctl stop openvpn-client@lab
ip -details link show dev tun1

Ein weicher Reset sollte die Sitzung nutzbar und die Ressourcen intakt lassen, und das ist die Aufgabe, die persist-tun erledigt. Ein vollständiges Stoppen ist der Punkt, an dem sich ein externer Manager zeigt: Überleben der Link oder seine Adressen das Stoppen, besitzt sie jemand anderes, und das ist entweder der dokumentierte Zustand oder der Fehler, den Sie gerade gefunden haben. Notieren Sie beide Beobachtungen neben dem Profil, damit die nächste Änderung von Belegen ausgeht und nicht von einem Diagramm.