Le VPN tombe quand l’écran s’éteint : quel cycle de vie ?

Le transfert s’arrête à l’instant où l’écran s’éteint, et le badge suit quelques secondes plus tard. Trois choses différentes produisent cette image : le processus client est restreint, le chemin passe au repos et perd sa correspondance, ou l’application perd une session que le tunnel n’a jamais remarquée. Chacune a ses propres preuves, et chaque correctif relève d’une couche différente. L’ordre ci-dessous les sépare avec un seul test contrôlé au lieu d’un balayage de tous les réglages.

Trois pannes qui se ressemblent

Un processus en arrière-plan restreint cesse d’envoyer des keepalives, et le pair finit par déclarer le tunnel mort. Une correspondance inactive sur le chemin peut expirer pendant que l’appareil dort, si bien que le trafic de retour n’atteint jamais un client encore parfaitement vivant. Une application peut perdre sa propre connexion alors que le tunnel reste debout, ce qui produit une boîte d’erreur avec un badge VPN sain derrière. Du point de vue de l’utilisateur, les trois se lisent comme le VPN tombé à l’extinction de l’écran.

La distinction compte parce que les remèdes se contredisent en pratique. Exempter le client des restrictions d’énergie corrige le premier cas et ne fait rien pour une correspondance expirée. Allonger les keepalives corrige le second et gaspille la batterie dans le troisième, où rien de réseau n’était fautif au départ.

Comparez actif et inactif sous contrôle

Gardez tout constant : même appareil, même réseau, même point de terminaison, même application. Verrouillez l’écran pendant un court intervalle fixe et notez trois observations : si le client signale une déconnexion, si une nouvelle requête fonctionne au déverrouillage, et si le transfert existant a repris. Répétez ensuite avec un keepalive ou une requête périodique en marche et comparez les deux exécutions. Une variable changée entre deux exécutions vaut mieux qu’une semaine de rapports anecdotiques.

Le moment appartient au dossier. Une chute après quatre-vingt-dix secondes sent la correspondance ou l’intervalle de keepalive, tandis qu’une chute à l’instant du verrouillage pointe vers une suspension du processus. Notez à la fois le déclencheur et l’intervalle, car la prochaine tentative aura besoin d’un point de comparaison.

Lisez la politique d’arrière-plan de la plateforme

Sous Android, le cycle de vie du service VPN fait partie de la plateforme, et always-on et block-without-VPN sont des commutateurs distincts aux effets distincts. Un client qui n’est pas always-on peut être arrêté quand le système récupère des ressources, et aucun réglage dans l’application ne change cela. iOS applique ses propres limites d’arrière-plan au fournisseur de tunnel, et le comportement documenté diffère d’un démon de bureau qui continue simplement de tourner. Lisez la documentation de la plateforme pour le composant concerné, pas un guide générique d’optimisation de batterie.

Les appareils gérés ajoutent une couche. Une politique peut supplanter un réglage personnel, si bien qu’un changement qui semble marcher revient à la prochaine actualisation de la politique. Utilisez le processus d’exception pris en charge par l’organisation si l’exigence est réelle, et notez pourquoi l’exception existe.

Ce que fait l’appareil après le réveil

La reconnexion automatique n’est pas la même chose que le blocage du trafic pendant le trou. Vérifiez les deux : si le tunnel revient, et si une application qui a tenté d’envoyer pendant le trou est sortie sans protection. Un client qui se reconnecte en deux secondes mais laisse fuir une requête DNS dans la première a la mauvaise politique de panne pour un appareil de travail. Testez avec des requêtes inoffensives et une destination que vous contrôlez.

La récupération de l’application est la troisième question. Un tunnel qui revient ne répare pas une session SSH arrivée à expiration, et les utilisateurs signalent souvent cette perte de session comme la panne du VPN. Gardez ensemble dans le rapport le déclencheur, la version du client et le moment exact, car cette combinaison sépare un cycle de vie prévisible d’extinction d’écran d’un serveur qui échoue indépendamment de l’appareil.