VPN coupé en pleine page : les requêtes d’arrière-plan sortent-elles encore ?

L’onglet affiche toujours le tableau de bord d’avant la mort du tunnel. Les chiffres d’état se figent, un petit indicateur continue de tourner, et la barre d’adresse porte encore l’application que vous avez ouverte il y a une heure. Vous n’avez touché à rien après la coupure, et pourtant la page essaie peut-être encore de joindre son serveur selon son propre calendrier. C’est la partie que les gens manquent : une page simplement visible et une page qui envoie encore des requêtes se ressemblent de l’extérieur, et une seule des deux apparaît dans un journal réseau.

Le travail qu’une page commence sans vous

Quatre mécanismes maintiennent un document chargé occupé. Un minuteur répétitif peut relancer un appel d’état toutes les quelques secondes. Un fetch peut se déclencher quand l’onglet redevient visible après que vous y revenez. Un canal en direct bâti sur WebSocket ou sur des événements envoyés par le serveur peut tenter une reconnexion selon son propre calendrier de repli. Un service worker enregistré par le site peut se réveiller pour une synchronisation en file d’attente même quand aucun onglet n’est devant vous.

Aucun de ces mécanismes n’a besoin d’un clic, et aucun ne recharge le document. La barre d’adresse, la position de défilement et les valeurs affichées restent toutes où elles étaient. Seul le côté réseau change : chaque nouvelle tentative est une décision fraîche prise au moment où elle commence.

Cette distinction compte parce que la page visible est stockée localement. Les pixels déjà peints ne disent rien du succès de la requête suivante. Un graphique figé avec un indicateur est l’aspect ordinaire d’une page dont les requêtes échouent désormais. Lire l’écran vous dit ce que le serveur a dit il y a quelques minutes, pas ce que fait le navigateur maintenant.

Pourquoi le chargement antérieur de la page ne tient pas de route

Rien dans le chargement de la page ne lie le document au tunnel. Le routage est résolu paquet par paquet, au moment de l’envoi, à partir de la table qui existe quand le paquet part. Quand l’interface du tunnel disparaît, cette recherche ne correspond plus à la route du tunnel. Elle retombe soit sur l’adaptateur physique, soit ne trouve rien du tout, selon ce que le client a laissé derrière lui.

Les rappels répétés sont des tâches planifiées ordinaires. La section sur les minuteurs de la norme HTML décrit comment ils sont mis en file et traite l’intervalle comme un délai minimal plutôt que comme une promesse de cadence exacte, si bien qu’un onglet en arrière-plan peut interroger bien moins souvent que son code ne le demande. Moins de tentatives n’est pas la même chose qu’aucune tentative, et ramener un onglet au premier plan est un moment courant pour une rafale de celles-ci.

Où atterrit la politique d’échec

Le blocage du client est évalué quand une connexion est tentée, pas quand la page a été récupérée. Si l’accès ordinaire est encore autorisé, la nouvelle tentative peut sortir par le lien physique en clair. Si la politique retient ce trafic jusqu’au retour du tunnel, la tentative échoue au moment de la connexion et la page affiche une erreur qu’elle peut réessayer quelques secondes plus tard.

Deux détails décident lequel de ces cas vous obtenez. Le premier est la portée d’application que le client prend en charge : un blocage pour tout l’appareil, un blocage limité à l’adaptateur du tunnel, ou un jeu de règles avec des exclusions. Le second est de savoir si la destination tombe dans une exclusion que vous avez ajoutée plus tôt pour une imprimante locale, un portail captif ou un service de streaming.

Le chiffrement au niveau de l’application ne change rien à cela. HTTPS protège les octets entre le navigateur et le serveur ; il ne dit rien de l’interface qui les transporte. Une page peut être parfaitement chiffrée et sortir quand même par le mauvais chemin, et c’est exactement ce qu’un blocage étroit permet.

Un contrôle maîtrisé avec une page jetable

Utilisez un hôte que vous contrôlez et une page qui ne fait rien d’autre que l’appeler, pour qu’aucune donnée réelle ne soit en jeu. Depuis un terminal, échantillonnez le chemin avant et après la coupure :

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

Exécutez-le avec le tunnel monté, puis coupez le tunnel et exécutez-le de nouveau. Une réponse venue d’une adresse publique alors que le tunnel est coupé vous dit que le chemin direct est ouvert. Un délai dépassé ou une connexion refusée vous dit que la politique tient. Répétez une fois de plus après la reconnexion du client, pour voir le chemin du tunnel revenir au lieu de le supposer.

Dans le navigateur, le panneau Réseau sépare les deux questions. Filtrez sur Fetch/XHR, puis lisez la colonne de l’initiateur : une entrée lancée par un minuteur ou un script, sans navigation enregistrée avant elle, est une tentative d’arrière-plan et non un rechargement. Comparez son heure de début avec le moment où le tunnel est tombé. Si l’entrée est encore en attente quand le tunnel a disparu, la requête attend un chemin qui n’existe plus.

Les preuves côté serveur sont plus fortes que tout ce que le navigateur montre. Un journal de requêtes avec un horodatage et une adresse source prouve que le paquet est arrivé. Les entrées du navigateur peuvent porter des cookies, des jetons et des URL complètes, alors ne conservez que les champs dont votre question a besoin et masquez le reste avant de les coller où que ce soit.

Que faire de la réponse

Si les tentatives d’arrière-plan continuent de réussir alors que le tunnel est coupé, le blocage est plus étroit que vous ne le pensiez, et cette faille mérite d’être fermée avant de confier au client un travail sensible. Si elles échouent, la politique fait son travail et la page figée est cosmétique. Dans tous les cas, fermer un onglet n’est pas un contrôle à l’échelle de l’appareil : les autres onglets, les autres navigateurs et les autres applications planifient chacun leur propre travail.

Des étapes suivantes qui valent la peine : listez les exclusions que vous avez ajoutées et pourquoi, confirmez si le client ne bloque que le trafic propre au tunnel ou tout le trafic, et observez une requête d’arrière-plan de bout en bout avec le journal du serveur ouvert. Ces trois réponses couvrent l’essentiel de ce que contient réellement un rapport du type « le VPN a sauté et quelque chose est encore connecté ».