Le VPN tombe quand l’écran s’éteint : verrouillage, extinction de l’écran ou suspension ?

Quand quelqu’un dit que le VPN est mort au moment où l’écran s’est éteint, la première question utile est lequel des trois événements s’est réellement produit : la session s’est verrouillée, le panneau s’est éteint, ou la machine entière est passée en veille. Ce sont des mécanismes distincts sur des minuteries distinctes, et un seul d’entre eux peut empêcher complètement un processus d’être ordonnancé. Parcourez les vérifications ci-dessous dans l’ordre. Arrêtez-vous à la première qui répond à la question, car chaque vérification suivante répond à autre chose.

Première vérification : séparez le verrouillage de l’extinction de l’écran et de la veille

Le verrouillage change qui est autorisé à utiliser la session ; le compositeur continue de dessiner, la pile réseau continue de fonctionner et le client VPN ne remarque rien. L’extinction de l’écran éteint le panneau après un intervalle d’inactivité et laisse la machine pleinement éveillée. La suspension arrête les processeurs, ce qui signifie qu’aucun processus en espace utilisateur n’est ordonnancé, donc aucun maintien de connexion ne peut se déclencher, quelle que soit la brièveté de l’intervalle.

C’est ce tableau qui fait que « l’écran s’est éteint » n’est pas un diagnostic. Un poste de bureau réglé pour s’éteindre à cinq minutes et se suspendre à trente affichera un écran noir à la sixième minute avec un tunnel parfaitement sain. La panne à la trentième minute est un autre événement avec une autre solution, et les deux se ressemblent depuis l’autre bout de la pièce.

Deuxième vérification : placez les événements d’alimentation et de réseau sur une seule chronologie

Lisez le journal sur une fenêtre bornée plutôt que sur tout le démarrage, et incluez à la fois le gestionnaire de connexion et le propriétaire de la connexion :

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

La première commande montre les demandes de veille, la reprise et les transitions réseau qui les ont suivies. La seconde montre ce qui détient actuellement un verrou inhibiteur, ce qui vous dit si quelque chose bloque délibérément la veille et quel programme c’est. Ajustez les noms d’unité si le propriétaire de votre connexion n’est pas NetworkManager, et rappelez-vous que la lecture de l’unité d’un autre utilisateur ou du journal système dépend de la politique locale.

Une ligne manquante n’est pas un résultat négatif. Si le journal de l’unité choisie n’est pas visible pour votre compte, l’absence d’un enregistrement de veille ne prouve rien, et conclure « il n’a jamais dormi » à partir d’un filtre vide est la façon dont les gens finissent par régler des maintiens de connexion pendant une semaine.

Troisième vérification : si la machine s’est suspendue, décidez si c’était voulu

Une fois qu’une transition de veille figure sur la chronologie, la question passe de « pourquoi le VPN a cassé » à « la machine aurait-elle dû dormir ». Sur un ordinateur portable, la réponse est souvent oui, et la coupure du tunnel est un comportement attendu dont le client doit se remettre à la reprise. Sur une station de travail censée rester joignable, c’est la politique de veille qu’il faut changer. Décider à laquelle de ces deux machines vous avez affaire demande une question, et ce n’est pas une question à laquelle le journal peut répondre à votre place.

Changez-la via les contrôles qui appartiennent à la session connectée, ou via un mécanisme pris en charge par l’administrateur si l’exigence concerne toute la machine. Modifier un réglage du gestionnaire d’affichage alors que vous êtes connecté avec un autre compte n’est pas la même action et semblera avoir fonctionné jusqu’au début de la session suivante. Désactiver entièrement la gestion de l’alimentation est une première réaction large qui coûte de l’autonomie et masque la vraie question de politique.

Quatrième vérification : si elle est restée éveillée, regardez le réseau et le client

Une machine éveillée qui a perdu son tunnel relève de l’une de trois histoires : le réseau d’accès est tombé, le client VPN s’est arrêté ou a redémarré, ou le côté serveur a laissé expirer l’association pendant que le client continuait de croire qu’il était connecté. Comparez les horodatages de l’événement de liaison sous-jacent avec l’événement du tunnel, et soyez précis sur lequel est venu en premier.

Testez ensuite le chemin de récupération séparément de la session d’origine. Une nouvelle requête via le tunnel rétabli peut réussir alors que la session applicative de longue durée ouverte avant la coupure reste cassée, parce que l’application détient une socket obsolète ou une adresse en cache. C’est un problème applicatif, pas la preuve que le tunnel n’est pas revenu.

Ce que contient un rapport utile

Écrivez la séquence avec les horodatages et les responsables : quand la session s’est verrouillée, quand l’écran s’est éteint, si une demande de veille a été enregistrée, quand la liaison est tombée et revenue, quand le tunnel a changé d’état et ce que l’application a réellement fait. Chaque élément a un responsable, donc chaque élément peut être confié à la bonne personne au lieu de devenir une plainte générale sur Linux.

Si l’une de ces lignes manque, c’est la prochaine chose à mesurer plutôt que la prochaine chose à changer. Une chronologie avec un trou est plus instructive qu’un changement de réglage fait au feeling.