vpn.persistent versucht es weiter, hält dich aber nicht verbunden
Die Eigenschaft bittet den VPN-Dienst, den Tunnel über Linkänderungen hinweg zu halten. Aktivierung, Lebendigkeit, Absicht und Kill-Switch-Verhalten bleiben getrennte Fragen.
NetworkManager stellt eine Eigenschaft bereit, vpn.persistent, und Menschen verlangen von ihr, vier verschiedene Fragen auf einmal zu beantworten. Die Upstream-Dokumentation ist sorgfältig: Persistenz gilt, wenn der VPN-Dienst sie unterstützt und das Profil sie aktiviert, und die Verbindung wird dann gebeten, Linkänderungen und Ausfälle bis zu einer ausdrücklichen Trennung zu überstehen. Dieselbe Dokumentation zeigt auch, dass die Eigenschaft standardmäßig false ist, was die meisten Wiederherstellungspläne nicht annehmen. Lies sie als Bitte um einen Versuch, nicht als Versprechen eines Ergebnisses.
Wozu die Einstellung tatsächlich verpflichtet
Ein im Profil gespeicherter Wert ist eine Anweisung an den Manager, und der Manager muss diese Anweisung an ein VPN-Plugin weitergeben, das weiß, was damit zu tun ist. Ignoriert das installierte Plugin die Eigenschaft, wird das Profil trotzdem aktiviert und das Protokoll bleibt still, was für jeden, der später debuggt, das Schlimmste aus beiden Welten ist. Nichts in einem Profil kann ein Plugin zwingen, ein Verhalten zu implementieren, das es nicht hat, also ist das einzige sichtbare Ergebnis eine Abwesenheit.
Deshalb ist die Bedingung in der Dokumentation wichtiger als der Schalter. Prüfe, welches Plugin und welche Version du tatsächlich hast, und schreibe die Version neben die Verbindungsbeschreibung, damit die nächste Person sie nicht neu entdecken muss. Eine Wiederherstellungsrichtlinie, die auf einem nicht implementierten Flag aufbaut, scheitert in der Produktion genau einmal und immer im ungünstigsten Moment.
Die Eigenschaft als Versuch zu behandeln setzt auch die richtige Erwartung an Tests. Du prüfst nicht, ob das Flag gesetzt ist; du prüfst, ob etwas passiert ist, als der Link ausfiel. Das sind verschiedene Experimente, und nur eines davon ist einen Nachmittag wert.
Vier Fragen, die zu einer verschmelzen
Aktivierung fragt, was das VPN überhaupt hochbringt. Ein NetworkManager-Profil kann an eine Basisverbindung gebunden sein, ein separat verwalteter OpenVPN-Dienst besitzt seinen eigenen Start, und einen dritten Starter zu dieser Anordnung hinzuzufügen gibt dir zwei Eigentümer mit unterschiedlichen Vorstellungen davon, wer das Sagen hat. Entscheide, welche Komponente den Start besitzt, bevor du einen weiteren Auslöser hinzufügst.
Wiederherstellung fragt, was passiert, wenn sich der Link ändert oder verschwindet, und das ist die enge Frage, die vpn.persistent adressiert. Lebendigkeit fragt, ob der Client erkennen kann, dass die Gegenseite aufgehört hat zu antworten, und das beantwortet stattdessen das Keepalive- oder Neustartverhalten von OpenVPN; die beiden Mechanismen werden oft mit demselben Wort beschrieben und an verschiedenen Stellen implementiert. Teste sie getrennt, mit verschiedenen Werkzeugen, sonst schreibst du das eine Verhalten dem anderen zu.
Absicht fragt, ob eine Wiederverbindung überhaupt gewünscht ist, und das ist die Frage, die Statusabfragen nicht beantworten können. Ein bewusstes Stoppen und ein Ausfall erzeugen denselben inaktiven Zustand, also rät alles, was bei Abwesenheit neu verbindet, über eine menschliche Entscheidung. Raten ist in Ordnung bis zu dem Moment, in dem es jemanden übergeht.
Eine Checkliste, die sie getrennt hält
Führe die Ereignisse der Reihe nach aus, statt die Konfiguration zu lesen und über sie nachzudenken, und halte mit einem Zeitstempel fest, was jedes einzelne zeigt.
Erstens: Aktiviere die vorgesehene Basisverbindung und bestätige, dass das VPN über den erwarteten Auslöser hochkam und nicht über einen Mechanismus, von dem du vergessen hattest, dass er installiert ist. Zweitens: Vergleiche während einer genehmigten Unterbrechung die VPN-Ereignisse des Managers, den Wiederherstellungszustand des besitzenden Clients und eine frische Anfrage an eine private Ressource. Drittens: Trenne bewusst, warte und bestätige, dass nichts das Profil hinter deinem Rücken neu startet.
Der dritte Schritt ist der, den Leute überspringen, und er findet am häufigsten den echten Defekt. Ein Watchdog, der nach einem aktiven Profil pollt und sich neu verbindet, wenn es fehlt, macht die absichtliche Trennung eines Nutzers munter rückgängig. Aus Sicht des Nutzers ist das keine Resilienz; es ist eine Maschine, die nicht gehorcht. Frag sie, bevor du eine hinzufügst.
Schreibe die Ergebnisse in dasselbe Dokument wie die Verbindungsbeschreibung. Eine Wiederherstellungsrichtlinie ist nur so gut wie das letzte Mal, als jemand sie absichtlich scheitern sah. Zeitstempel machen den Unterschied für jeden sichtbar, der die Notizen als Nächstes liest.
Authentifizierung gehört zur Wiederherstellung
Wiederverbinden ist kein rein netzwerkbezogener Vorgang. Wenn der genehmigte Ablauf eine neue Abfrage, einen Einmalcode oder ein Geheimnis benötigt, das der Aktivierungskontext nicht erreichen kann, kann keine Persistenzeinstellung es aus dem Nichts erzeugen.
Das erklärt ein vertrautes Muster: Die Verbindung wird auf einer Maschine mit entsperrtem Schlüsselbund wiederhergestellt und scheitert auf derselben Maschine nach einem Neustart. Die Netzwerkschicht tat genau das, worum gebeten wurde, und die Anmeldedatenschicht hatte nichts anzubieten.
Repariere den Anmeldedaten-Workflow, statt das Wiederholungsintervall zu verkürzen. Schnellere Wiederholungen gegen eine Abfrage, die niemand beantworten kann, erzeugen Protokollrauschen und den falschen Eindruck, es werde etwas versucht.
Persistenz ist kein Kill Switch
Die Eigenschaft versucht, die VPN-Beziehung zu erhalten oder wiederherzustellen. Sie entscheidet nicht, was Anwendungen tun dürfen, während das VPN aus ist, und sie blockiert von sich aus nichts.
Wenn die Anforderung lautet, dass kein Datenverkehr den Tunnel verlässt, ist das eine separate Richtlinie mit eigenem Mechanismus, eigenen Tests und eigenen Fehlermodi. Die Annahme, Persistenz decke das ab, macht aus einer Sicherheitsentscheidung einen Unfall.
Halte beide Hälften in den Wiederherstellungsnotizen fest: was das VPN versucht hat und welcher Anwendungsverkehr erlaubt war, während der Versuch lief.