Corriger les coupures VPN en veille : une liste de vérification pour l'économie d'énergie Wi-Fi

Passez les coupures VPN en veille dans l'ordre : confirmez le moment, séparez la radio du tunnel, lisez l'état réel d'économie d'énergie, puis changez un réglage et retestez.

Votre tunnel meurt après que l'ordinateur portable est resté un moment sans être touché, et il revient à l'instant où vous touchez le trackpad. Ce schéma indique que la liaison sans fil entre en économie d'énergie, et non que la passerelle VPN rejette vos identifiants. Un matin chargé sur le même profil est l'indice : le tunnel survit tant que le trafic circule et tombe dès que la radio se tait. Faites les vérifications ci-dessous dans l'ordre, arrêtez-vous à la première qui échoue, et ne changez un réglage qu'ensuite.

Vérification un : la coupure suit-elle l'inactivité ?

Commencez par prouver la corrélation au lieu de la supposer. Notez l'heure de l'horloge murale du dernier paquet envoyé, l'heure à laquelle le client a signalé le tunnel en panne, et si l'écran s'est éteint entre-temps. Si l'écart est le même à chaque fois, vous avez un problème sur le chemin d'inactivité ; si les coupures surviennent au hasard pendant un usage actif, passez à la vérification cinq.

Un test bon marché qui ne coûte rien à annuler : envoyez un ping régulier à faible débit vers votre passerelle pendant vingt minutes et laissez la machine tranquille. Si le tunnel tient toute la durée, le petit trafic constant masque le symptôme au lieu de le corriger, ce qui reste une preuve utile. Je garde la sortie de ce ping dans un terminal de brouillon et je la compare ensuite au journal du client, car les deux horloges s'accordent rarement.

Vérification deux : est-ce uniquement le trafic VPN ?

Avant d'accuser le tunnel, déterminez si la liaison elle-même est encore utilisable. Pendant que le tunnel est mort mais que l'écran est encore éteint, essayez de joindre l'adresse du point d'accès et un hôte public par IP. Si le ping ordinaire échoue aussi, la radio ou le point d'accès vous ont lâché, et le client VPN n'est qu'un spectateur.

Si le trafic ordinaire circule alors que le tunnel reste silencieux, la liaison est saine et le problème se situe dans les minuteries du tunnel lui-même ou dans la façon dont le client gère une reprise. Ce sont deux corrections différentes, alors ne sautez pas cette étape. Sur un portable avec Wi-Fi et Ethernet à la fois, débranchez le câble et refaites le test d'inactivité : une coupure d'inactivité qui disparaît sur Ethernet filaire est une preuve solide pour la couche sans fil.

Vérification trois : lisez l'état d'économie d'énergie

La plupart des bureaux vous donnent une case à cocher, mais la case n'est pas l'état dans lequel se trouve le pilote. Lisez d'abord le rapport du pilote lui-même, puis décidez. Sous Linux avec mac80211, l'interface répond directement :

iw dev wlan0 get power_save          # on or off, per interface
sudo iw dev wlan0 set power_save off # diagnostic only, lost on reconnect

La seconde commande est un test, pas une correction. Elle ne survit ni à une déconnexion, ni à une mise en veille, ni à un redémarrage, ce qui en fait un moyen propre de vérifier l'hypothèse sans laisser de changements permanents.

Sous Windows powercfg /q SCHEME_CURRENT imprime le schéma actif, et la sous-arborescence de l'adaptateur sans fil indique si l'on peut demander à l'adaptateur d'économiser l'énergie ; le même choix se trouve aussi dans le Gestionnaire de périphériques, sous l'onglet de gestion de l'alimentation de l'adaptateur. Sous macOS, l'économie d'énergie 802.11 par interface ne vous est pas exposée, alors regardez plutôt pmset -g pour le comportement de veille et de mise en attente. Là, la panne s'avère généralement être le chemin de veille et de réveil plutôt que le comportement d'inactivité de la radio.

Vérification quatre : changez une chose, puis retestez

Changez exactement une variable par essai et répétez la même charge. Si le tunnel tient désormais une heure d'inactivité avec l'économie d'énergie désactivée, vous avez appris quelque chose de réel. S'il tombe encore, revenez en arrière avant de tester l'idée suivante, sinon vous vous retrouvez avec trois réglages qui se chevauchent et aucune idée de celui qui compte.

Le maintien de connexion est l'autre variable indépendante et il est constamment confondu avec l'économie d'énergie. Le PersistentKeepalive = 25 de WireGuard garde une correspondance NAT au chaud ;OpenVPN utilise keepalive et ping-restart aux deux extrémités. Les deux génèrent du trafic sur un tunnel autrement silencieux, si bien qu'un maintien de connexion qui semble corriger la coupure peut masquer un problème radio plutôt que le résoudre. Testez-les séparément, un à la fois :

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
PersistentKeepalive = 25

Vérification cinq : quand la radio est innocente

Si les coupures d'inactivité persistent avec l'économie d'énergie désactivée et un maintien de connexion actif, regardez hors du portable. Les points d'accès et les routeurs domestiques expirent les entrées NAT ou de session inactives selon leur propre calendrier, et un serveur VPN peut abandonner une session sans trafic.L'itinérance entre points d'accès qui partagent un même SSID peut aussi réinitialiser la liaison sans que le client le dise clairement.

Comparez ensuite avec un second appareil sur le même réseau qui fait le même test d'inactivité. Deux appareils qui tombent au même intervalle racontent une histoire de chemin ou de serveur ; un seul appareil qui tombe raconte une histoire de pilote ou d'énergie locale. Cette comparaison coûte dix minutes et vous évite de réécrire la mauvaise configuration.

Avant de le rendre permanent

Décidez ce que vous êtes prêt à garder. Un script par profil qui désactive l'économie d'énergie uniquement sur les réseaux où vous avez vu la coupure est défendable. Un réglage global qui désactive tout, payé en autonomie sur chaque réseau, ne l'est généralement pas.

  • Notez la valeur d'économie d'énergie d'origine à côté du script pour qu'elle puisse être rétablie.
  • Refaites le test d'inactivité après chaque mise à jour de pilote ou de client ; les valeurs par défaut changent.
  • Gardez le journal de ping et le journal du client ensemble lorsque vous signalez le problème.
  • Si la deuxième étape a échoué, arrêtez de modifier les réglages VPN et traitez cela comme une panne locale de la liaison.

Si vous ne faites qu'une seule chose, faites la vérification deux. C'est elle qui décide si le reste de cette liste vous concerne, et c'est l'étape que les gens sautent une fois qu'ils ont déjà décidé que la réponse est l'économie d'énergie.

Articles similaires