Le VPN se déconnecte sans cesse ? Procédez dans cet ordre

Avant de réinstaller le client, notez trois choses : combien de temps le tunnel est resté actif, ce que le client a dit au moment de la coupure et si la machine a dormi ou changé de réseau entre-temps. Cette note est la seule preuve dont vous disposerez ensuite, et une réinstallation l’efface généralement. Une coupure à intervalle répétable est un minuteur ou une expiration d’état ; une coupure à un moment aléatoire est un problème de chemin. L’ordre ci-dessous vous évite de changer trois choses à la fois et de n’apprendre rien.

Première étape : relever l’intervalle et le texte de l’erreur

Commencez par le journal du client lui-même plutôt que par le tableau de bord du fournisseur. Sur un client Linux, le journal du service et l’état du tunnel en direct couvrent l’essentiel :

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

Notez les horodatages de la dernière poignée de main réussie et le moment où le trafic s’est arrêté, pas seulement le moment où l’icône a changé de couleur. Un client graphique qui annonce la déconnexion après coup rapporte peut-être un état que le noyau a atteint quelques secondes plus tôt.

Conservez la formulation de l’erreur. Un délai dépassé, un refus d’authentification et une erreur d’adaptateur ou de pilote désignent trois couches différentes, et l’essentiel du temps perdu sur ce problème vient de les traiter comme une seule. Copiez la ligne mot pour mot dans votre note.

Deuxième étape : changer une variable, pas le profil

Gardez l’appareil et le profil fixes et déplacez la machine vers un autre réseau d’accès, comme un partage de connexion mobile. C’est le test le moins coûteux qui sépare le client du chemin. Faites-le durer assez longtemps pour couvrir l’intervalle de panne d’origine ; deux minutes stables ne prouvent rien sur une coupure qui survient à la trentième minute.

Un ordinateur portable doté d’un port Ethernet offre une seconde comparaison qui écarte totalement le Wi-Fi. Si le tunnel tient sur les deux solutions, le réseau d’accès d’origine mérite l’attention : itinérance entre points d’accès, un routeur domestique dont la table de traduction expire ou un lien amont qui réinitialise les flux de longue durée.

Notez quelle variable vous avez changée. Une comparaison ne compte que si tout le reste est resté identique, y compris le point de terminaison du serveur et l’heure de la journée.

Troisième étape : rattacher l’intervalle à une couche

La durée d’une bonne session est le nombre unique le plus informatif dont vous disposez. Lisez-la à la lumière de cette liste avant de toucher aux minuteurs :

• Coupure après veille ou reprise : l’état du tunnel a survécu à la suspension, mais pas l’interface. Vérifiez le comportement de reconnexion du client à la reprise et si le service redémarre le tunnel ou attend du trafic.
• Coupure uniquement au repos : quelque chose au milieu a laissé le flux expirer. C’est précisément le cas pour lequel les keepalive existent.
• Coupure à un âge de session fixe : un événement de réauthentification ou de renouvellement de clé, pas une défaillance de chemin. Un refus explicite dans le journal exactement à cet intervalle est le signe.
• Coupure pendant de gros transferts ou de grandes pages : soupçonnez le MTU et la fragmentation, pas un minuteur d’inactivité.

Pour le cas du repos, les réglages sont propres au protocole et les deux extrémités comptent. Le keepalive 10 60 d’OpenVPN côté serveur envoie un ping toutes les 10 secondes et relance la liaison après 60 secondes sans ping ; les clients WireGuard derrière un NAT utilisent PersistentKeepalive = 25 dans le bloc de pair. OpenVPN renégocie aussi le canal de données selon un minuteur, reneg-sec, qui vaut 3600 secondes par défaut en 2.x.

Ne copiez pas des valeurs agressives depuis le guide d’un autre fournisseur. Un délai court sur une liaison mobile avec pertes produit précisément les déconnexions qu’il devait éviter, et les valeurs poussées par le serveur écrasent celles que vous réglez dans le profil du client.

Quatrième étape : comparer une seule alternative prise en charge

Si l’opérateur publie à la fois un profil UDP et un profil TCP, testez le même appareil et le même réseau sur l’autre. Utilisez le fichier correspondant réel plutôt que de modifier le transport dans un profil copié. Un profil TCP stable sur un chemin où l’UDP est réinitialisé circonscrit le problème à ce chemin ; cela ne prouve pas que TCP soit le meilleur transport partout.

La même logique vaut pour les points de terminaison. Essayez un autre serveur et gardez le résultat d’origine à côté. Si une seule sortie réinitialise les sessions, c’est une preuve concernant ce point de terminaison, pas une raison de reconstruire chaque adaptateur du portable.

Après chaque changement, reproduisez le déclencheur d’origine et confirmez où va réellement le trafic. Un accès internet retrouvé n’est pas le même résultat qu’un trafic à l’intérieur du tunnel, et un client retombé silencieusement sur une route directe semble sain depuis le navigateur.

Vérifiez la correction et conservez le retour arrière

Une correction se vérifie en reproduisant le déclencheur d’origine, pas par une connexion réussie. Laissez le tunnel inactif au-delà de l’ancien intervalle de panne, suspendez et reprenez une fois, puis vérifiez l’âge de la poignée de main et l’adresse de sortie :

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

Conservez le profil précédent et les valeurs de minuteur précédentes jusqu’à ce que le nouveau comportement survive à une journée de travail complète. Si les coupures reviennent, restaurez la sauvegarde, puis réappliquez les changements un par un afin que la seconde tentative parte d’un état connu.

Si le journal reste propre et que le tunnel se coupe encore à intervalle répétable, l’étape suivante est le côté serveur pour cette session. Emportez l’identifiant de session du client et l’heure exacte de la coupure, car c’est ce couple qui rend un journal serveur exploitable en recherche. Les options de liaison du protocole sont documentées dans le manuel OpenVPN 2.6 lorsque vous avez besoin du sens exact d’une valeur.