VPN mitten auf der Seite ausgefallen: gehen Hintergrundanfragen noch raus?

Der Tab zeigt noch das Dashboard von vor dem Ausfall des Tunnels. Statuszahlen frieren ein, ein kleiner Ladekreis dreht sich weiter, und die Adressleiste trägt noch die App, die Sie vor einer Stunde geöffnet haben. Sie haben nach dem Ausfall nichts angefasst, und doch versucht die Seite vielleicht weiterhin, ihren Server nach ihrem eigenen Zeitplan zu erreichen. Das ist der Punkt, den viele übersehen: Eine Seite, die nur sichtbar ist, und eine Seite, die noch Anfragen sendet, sehen von außen gleich aus, und nur eine von beiden taucht in einem Netzwerkprotokoll auf.

Arbeit, die eine Seite ohne Sie beginnt

Vier Mechanismen halten ein geladenes Dokument beschäftigt. Ein wiederholender Timer kann alle paar Sekunden einen Statusaufruf erneut ausführen. Ein Fetch kann ausgelöst werden, wenn der Tab nach Ihrem Zurückschalten wieder sichtbar wird. Ein Live-Kanal auf Basis von WebSocket oder Server-Sent Events kann nach seinem eigenen Backoff-Zeitplan einen Reconnect versuchen. Ein von der Website registrierter Service Worker kann für eine eingereihte Synchronisierung aufwachen, selbst wenn kein Tab vor Ihnen ist.

Nichts davon braucht einen Klick, und nichts davon lädt das Dokument neu. Adressleiste, Scrollposition und gerenderte Werte bleiben alle, wo sie waren. Geändert wird nur die Netzwerkseite: Jeder neue Versuch ist eine frische Entscheidung, die in dem Moment getroffen wird, in dem er beginnt.

Diese Unterscheidung ist wichtig, weil die sichtbare Seite lokal gespeichert ist. Bereits gezeichnete Pixel sagen nichts darüber aus, ob die nächste Anfrage erfolgreich war. Ein eingefrorenes Diagramm mit Ladekreis ist das gewöhnliche Aussehen einer Seite, deren Anfragen jetzt scheitern. Den Bildschirm zu lesen sagt Ihnen, was der Server vor Minuten gesagt hat, nicht was der Browser jetzt tut.

Warum das frühere Laden der Seite keine Route hält

Nichts im Laden der Seite bindet das Dokument an den Tunnel. Routing wird pro Paket zum Sendezeitpunkt aus der Tabelle aufgelöst, die existiert, wenn das Paket das Gerät verlässt. Wenn die Tunnel-Schnittstelle verschwindet, passt diese Suche nicht mehr zur Tunnelroute. Sie fällt entweder auf den physischen Adapter durch oder findet gar nichts, je nachdem, was der Client zurückgelassen hat.

Wiederholende Callbacks sind gewöhnliche geplante Aufgaben. Der Timer-Abschnitt des HTML-Standards beschreibt, wie sie eingereiht werden, und behandelt das Intervall als Mindestverzögerung statt als Versprechen exakter Taktung, sodass ein Hintergrund-Tab weit seltener abfragen kann, als sein Code verlangt. Weniger Versuche sind nicht dasselbe wie keine Versuche, und einen Tab wieder in den Vordergrund zu holen ist ein häufiger Moment für einen Schwall davon.

Wo die Fehlerrichtlinie landet

Die Sperre des Clients wird bewertet, wenn eine Verbindung versucht wird, nicht wenn die Seite abgerufen wurde. Ist gewöhnlicher Zugriff noch erlaubt, kann der Wiederholungsversuch über die physische Verbindung im Klartext hinausgehen. Hält die Richtlinie diesen Verkehr zurück, bis der Tunnel zurückkehrt, scheitert der Versuch im Verbindungsmoment, und die Seite zeigt einen Fehler, den sie wenige Sekunden später erneut versuchen kann.

Zwei Details entscheiden, welches von beidem Sie bekommen. Das erste ist der Durchsetzungsumfang, den der Client unterstützt: eine Sperre für das ganze Gerät, eine auf den Tunneladapter begrenzte Sperre oder ein Regelsatz mit Ausnahmen. Das zweite ist, ob das Ziel in eine Ausnahme fällt, die Sie früher für einen lokalen Drucker, ein Captive Portal oder einen Streamingdienst hinzugefügt haben.

Verschlüsselung auf Anwendungsebene ändert daran nichts. HTTPS schützt die Bytes zwischen Browser und Server; es sagt nichts darüber aus, welche Schnittstelle sie transportiert. Eine Seite kann perfekt verschlüsselt sein und trotzdem über den falschen Weg hinausgehen, und genau das erlaubt eine enge Sperre.

Eine kontrollierte Prüfung mit einer Wegwerfseite

Verwenden Sie einen Host, den Sie kontrollieren, und eine Seite, die nichts anderes tut, als ihn aufzurufen, damit keine echten Daten im Spiel sind. Nehmen Sie von einem Terminal aus den Pfad vor und nach dem Ausfall ab:

curl -sS --max-time 5 -o /dev/null -w '%{http_code} %{remote_ip}\n' https://probe.example.net/ping

Führen Sie das bei aktivem Tunnel aus, bringen Sie dann den Tunnel herunter und führen Sie es erneut aus. Eine Antwort von einer öffentlichen Adresse bei heruntergefahrenem Tunnel sagt Ihnen, dass der direkte Pfad offen ist. Eine Zeitüberschreitung oder eine abgelehnte Verbindung sagt Ihnen, dass die Richtlinie hält. Wiederholen Sie es noch einmal, nachdem der Client sich wieder verbunden hat, damit Sie den Tunnelpfad zurückkommen sehen, statt es anzunehmen.

Im Browser trennt das Netzwerk-Panel die beiden Fragen. Filtern Sie auf Fetch/XHR und lesen Sie dann die Spalte Initiator: Ein Eintrag, den ein Timer oder ein Skript gestartet hat, ohne vorher aufgezeichnete Navigation, ist ein Hintergrundversuch und kein Neuladen. Vergleichen Sie seine Startzeit mit dem Moment, in dem der Tunnel ausgefallen ist. Steht der Eintrag noch aus, während der Tunnel weg ist, wartet die Anfrage auf einen Pfad, der nicht mehr existiert.

Belege auf der Serverseite sind stärker als alles, was der Browser zeigt. Ein Anfrageprotokoll mit Zeitstempel und Quelladresse beweist, dass das Paket angekommen ist. Browser-Einträge können Cookies, Tokens und vollständige URLs tragen, also behalten Sie nur die Felder, die Ihre Frage braucht, und schwärzen Sie den Rest, bevor Sie sie irgendwo einfügen.

Was mit der Antwort zu tun ist

Wenn Hintergrundversuche weiter erfolgreich sind, während der Tunnel unten ist, ist die Sperre enger, als Sie angenommen haben, und diese Lücke sollte geschlossen werden, bevor Sie dem Client sensible Arbeit anvertrauen. Scheitern sie, tut die Richtlinie ihre Arbeit, und die eingefrorene Seite ist kosmetisch. So oder so ist das Schließen eines Tabs keine geräteweite Kontrolle: Andere Tabs, andere Browser und andere Anwendungen planen jeweils ihre eigene Arbeit.

Nächste Schritte, die sich lohnen: Listen Sie auf, welche Ausnahmen Sie hinzugefügt haben und warum, bestätigen Sie, ob der Client nur tunnelgebundenen Verkehr oder den gesamten Verkehr blockiert, und beobachten Sie eine Hintergrundanfrage von Anfang bis Ende mit geöffnetem Serverprotokoll. Diese drei Antworten decken das meiste ab, was ein Bericht „das VPN ist ausgefallen und etwas ist noch verbunden“ tatsächlich enthält.