Welche openvpn-Binärdatei läuft? Den Startpfad prüfen

Ein alter Workaround verschob die OpenVPN-Binärdatei an einen anderen Ort und ließ am ursprünglichen Pfad einen Shell-Wrapper zurück. Monate später landet ein Upgrade, und das Rückgängigmachen des Workarounds wird zum Rätselraten darüber, welche Datei wirklich der Client ist. Der Befehlsname, die im Dienst konfigurierte Binärdatei und das eigene Dateiverzeichnis des Pakets können alle auf verschiedene Objekte zeigen, und eines davon ohne die anderen zu reparieren, erzeugt einen Host, der repariert aussieht und sich schlechter verhält.

Beginnen Sie mit dem Pfad, den der Dienst startet

Ein Terminal und eine systemd-Unit lösen Binärdateien nicht gleich auf. Die Shell durchsucht einen PATH; die Unit benennt einen Pfad, und Drop-in-Overrides können ihn ersetzen, ohne die Datei anzufassen, die Sie gerade lesen. Dieser Unterschied erklärt den größten Teil der Verwirrung in dieser Aufgabe. Er entscheidet auch, auf welche Datei Ihre Reparatur zielen muss.

Fragen Sie die Unit, was sie ausführt, einschließlich der Drop-ins, die sie ändern, und lesen Sie die resultierende ExecStart-Zeile statt des Fragments, das Sie für maßgeblich halten. Folgen Sie dann diesem Pfad über jeden symbolischen Link bis zur endgültigen Datei. Ein Wrapper, der mit einem exec in ein verstecktes Verzeichnis endet, ist eine übliche Konstruktion aus diesen alten Korrekturen.

Notieren Sie den aufgelösten Pfad, bevor Sie etwas ändern.

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

Vergleichen Sie den Befehlsnamen mit dem Dienstpfad

Die beiden Antworten unterscheiden sich häufig, und dieser Unterschied ist nicht automatisch ein Fehler. Ein NetworkManager-Plugin kann seinen eigenen Pfad starten, und ein Container kann einen weiteren einbinden.

Entscheidend ist zu wissen, welcher Eigentümer den Prozess startet, der den Verkehr bedient. Wenn die Unit /usr/local/sbin/openvpn-wrapper ausführt, während Ihre Shell /usr/sbin/openvpn auflöst, ändert die Reparatur der zweiten Datei nichts am Dienst.

Fragen Sie, welchem Paket jeder Kandidat gehört, und entscheiden Sie dann, ob die Datei paketverwaltet oder lokal abgelegt ist. Eine Datei ohne besitzendes Paket ist eine Datei, die jemand absichtlich dorthin gelegt hat, und sie verdient einen Namen, einen Eigentümer und einen Grund, bevor sie gelöscht wird. Der umgekehrte Fehler ist ebenfalls verbreitet: eine Paketdatei mit einer alten gespeicherten Binärdatei überschreiben, weil ein Forumsbeitrag dasselbe Verzeichnis verwendete.

Lassen Sie die Paketdatenbank für Paketdateien sprechen

Wenn die Software aus einem Debian-Paket stammt, kann die Paketdatenbank sagen, ob ihre Dateien noch mit dem Installierten übereinstimmen. Das ist eine enge Integritätsfrage, kein Sicherheitsurteil, und der Unterschied zählt, wenn Sie entscheiden, was zu reparieren ist. Eine Abweichung bedeutet, dass die Datei nach der Installation geändert wurde, was Ihr alter Workaround oder eine legitime lokale Änderung sein könnte. Die Ausgabe entscheidet nicht, welches von beiden, lesen Sie sie also als Hinweis und nicht als Schlussfolgerung.

Führen Sie die Prüfung aus und lesen Sie die Ausgabe, statt ein leeres Ergebnis als Beweis für irgendetwas zu behandeln.

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

Das dpkg-Handbuch dokumentiert, dass die Prüfung installierte Dateien mit lokal aufgezeichneten Metadaten vergleicht und dabei gespeicherte Prüfsummen verwendet, wo sie vorhanden sind. Sie bemerkt eine geänderte Paketdatei und kann Ihnen nicht sagen, ob stattdessen eine andere Binärdatei gestartet wird.

Halten Sie den Zustand vor der Reparatur fest

Sammeln Sie den aufgelösten Startpfad, die Paketbeziehung der Datei, den Ort des Wrappers und den Änderungsdatensatz, der ihn eingeführt hat. Kopieren Sie den Wrapper an einen geschützten Ort, wenn er Integrationsarbeit enthält, die später gebraucht wird.

Fügen Sie den Inhalt des Wrappers nicht in einen Support-Thread ein, bevor Sie ihn gelesen haben, denn diese Skripte enthalten manchmal Zugangsdaten oder Gateway-Details.

Notieren Sie, welche Profile der Dienst verwendet und wer verbunden ist, während Sie arbeiten, denn ein Neustart des Tunnels kann die Sitzung unterbrechen, mit der Sie den Host administrieren.

Prüfen Sie den Start und entfernen Sie dann den Wrapper

Starten Sie nach der Reparatur den Dienst und bestätigen Sie, dass der Prozess den beabsichtigten Pfad ausführt. Eine von Hand ausgeführte Versionsabfrage beweist, dass die Datei funktioniert; sie beweist nicht, dass die Unit sie verwendet.

Verbinden Sie dann einen Client erneut und prüfen Sie, ob das Profil noch authentifiziert, denn ein Binärtausch, der die ursprünglichen Optionen ignoriert, wird auf eine Weise fehlschlagen, die wie ein Zertifikatsproblem aussieht.

Entfernen Sie den verdrängten Wrapper über denselben Änderungsdatensatz, der ihn eingeführt hat. Die abgeschlossene Reparatur nennt die laufende Binärdatei, den Grund und die entfernte Datei; einen Dateinamen wiederherstellen und zu hoffen ist nicht dasselbe.