VPN bricht ab, wenn der Bildschirm dunkel wird: Sperre, Leerlauf oder Standby?

Wenn jemand sagt, die VPN sei gestorben, als der Bildschirm dunkel wurde, ist die erste nützliche Frage, welches der drei Ereignisse tatsächlich eingetreten ist: Die Sitzung wurde gesperrt, das Panel wurde abgeschaltet, oder der ganze Rechner ging in den Ruhezustand. Das sind getrennte Mechanismen mit getrennten Timern, und nur einer davon kann verhindern, dass ein Prozess überhaupt eingeplant wird. Gehen Sie die Prüfungen unten der Reihe nach durch. Halten Sie bei der ersten an, die die Frage beantwortet, denn jede Prüfung danach beantwortet etwas anderes.

Prüfung eins: Trennen Sie die Sperre vom Leerlauf und vom Standby

Eine Sperre ändert, wer die Sitzung benutzen darf; der Compositor zeichnet weiter, der Netzwerk-Stack läuft weiter, und der VPN-Client merkt nichts. Der Leerlauf des Bildschirms schaltet das Panel nach einem Untätigkeitsintervall ab und lässt den Rechner völlig wach. Standby hält die CPUs an, was bedeutet, dass kein Prozess im Userspace eingeplant wird, sodass kein Keepalive ausgelöst werden kann, egal wie kurz Sie das Intervall setzen.

Diese Tabelle ist der Grund, warum „der Bildschirm wurde dunkel“ keine Diagnose ist. Ein Desktop, der nach fünf Minuten in den Leerlauf und nach dreißig in den Standby geht, zeigt in der sechsten Minute einen dunklen Bildschirm bei völlig gesundem Tunnel. Der Ausfall in der dreißigsten Minute ist ein anderes Ereignis mit einer anderen Lösung, und beide sehen von der anderen Seite des Raums gleich aus.

Prüfung zwei: Legen Sie Energie- und Netzwerkereignisse auf eine Zeitachse

Lesen Sie das Journal für ein begrenztes Zeitfenster statt für den gesamten Start, und schließen Sie sowohl den Anmeldemanager als auch den Eigentümer der Verbindung ein:

journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list

Der erste Befehl zeigt Schlafanforderungen, das Aufwachen und die Netzwerkübergänge, die darauf folgten. Der zweite zeigt, was gerade eine Inhibitor-Sperre hält, was Ihnen sagt, ob etwas den Schlaf absichtlich blockiert und welches Programm es ist. Passen Sie die Unit-Namen an, wenn der Eigentümer Ihrer Verbindung nicht NetworkManager ist, und denken Sie daran, dass das Lesen einer fremden User-Unit oder des Systemjournals von der lokalen Richtlinie abhängt.

Eine fehlende Zeile ist kein negatives Ergebnis. Wenn das Journal der ausgewählten Unit für Ihr Konto nicht sichtbar ist, beweist das Fehlen eines Standby-Eintrags nichts, und aus einem leeren Filter zu schließen, „er hat nie geschlafen“, ist der Weg, auf dem Leute eine Woche lang Keepalives optimieren.

Prüfung drei: Wenn er in den Standby ging, entscheiden Sie, ob das beabsichtigt war

Sobald ein Schlafübergang auf der Zeitachse steht, ändert sich die Frage von „warum ist die VPN kaputtgegangen“ zu „hätte der Rechner überhaupt schlafen sollen“. Auf einem Laptop ist die Antwort oft ja, und der Tunnelausfall ist erwartetes Verhalten, von dem sich der Client beim Aufwachen erholen sollte. Auf einer Workstation, die erreichbar bleiben soll, ist die Standby-Richtlinie das, was geändert werden muss. Zu entscheiden, welchen dieser beiden Rechner Sie vor sich haben, braucht eine Frage, und es ist keine Frage, die das Journal für Sie beantworten kann.

Ändern Sie sie über die Bedienelemente, die zur angemeldeten Sitzung gehören, oder über einen vom Administrator unterstützten Mechanismus, wenn die Anforderung für den ganzen Rechner gilt. Eine Einstellung des Anzeigemanagers zu bearbeiten, während Sie als ein anderes Konto angemeldet sind, ist nicht dieselbe Handlung und wird so aussehen, als hätte sie funktioniert, bis die nächste Sitzung beginnt. Die Energieverwaltung ganz abzuschalten ist eine breite erste Reaktion, die Akkulaufzeit kostet und die eigentliche Richtlinienfrage verdeckt.

Prüfung vier: Wenn er wach blieb, schauen Sie auf Netzwerk und Client

Ein wacher Rechner, der seinen Tunnel verloren hat, hat eine von drei Geschichten: Das Zugangsnetz ist ausgefallen, der VPN-Client wurde gestoppt oder neu gestartet, oder die Serverseite hat die Assoziation verfallen lassen, während der Client weiterhin glaubte, verbunden zu sein. Vergleichen Sie die Zeitstempel des zugrunde liegenden Linkereignisses mit dem Tunnelereignis und seien Sie genau dabei, welches zuerst kam.

Testen Sie dann den Wiederherstellungspfad getrennt von der ursprünglichen Sitzung. Eine neue Anfrage durch den wiederhergestellten Tunnel kann gelingen, während die langlebige Anwendungssitzung, die vor dem Ausfall geöffnet wurde, kaputt bleibt, weil die Anwendung einen veralteten Socket oder eine zwischengespeicherte Adresse hält. Das ist ein Anwendungsproblem, kein Beweis dafür, dass der Tunnel nicht zurückkam.

Was ein nützlicher Bericht enthält

Schreiben Sie die Abfolge mit Zeitstempeln und Eigentümern auf: wann die Sitzung gesperrt wurde, wann der Bildschirm leer wurde, ob eine Schlafanforderung protokolliert wurde, wann der Link ausfiel und zurückkam, wann der Tunnel den Zustand änderte und was die Anwendung tatsächlich getan hat. Jeder Punkt hat einen Eigentümer, also kann jeder Punkt an die richtige Person gehen, statt zu einer allgemeinen Beschwerde über Linux zu werden.

Wenn eine dieser Zeilen fehlt, ist das die nächste Sache, die gemessen werden muss, und nicht die nächste, die geändert werden muss. Eine Zeitachse mit einer Lücke ist informativer als eine Einstellungsänderung auf Verdacht.