Le VPN se déconnecte sans cesse : testez la radio avant le serveur

Une déconnexion VPN peut commencer bien avant qu'un quelconque trafic n'atteigne le serveur. La perte du Wi-Fi, un passage du Wi-Fi au réseau mobile, la congestion du point d'accès local et un téléphone qui se met en veille peuvent tous interrompre le chemin extérieur tandis que le logiciel du tunnel signale un échec propre. Progressez du terminal vers l'extérieur : d'abord la liaison, puis les événements du client lui-même, puis une comparaison contrôlée, et seulement ensuite le serveur. Cet ordre vous évite de changer de nœud de sortie pour un problème qui vit dans la pièce.

Observez la liaison, pas l'icône de signal

Cherchez les transitions de liaison plutôt que les barres. Un appareil peut afficher un signal fort alors que le point d'accès est saturé, qu'un passage en itinérance est en cours ou qu'une politique d'économie d'énergie met la radio en veille écran éteint.

Relevez l'état de l'interface, la passerelle actuelle et l'heure de chaque changement. Vérifiez ensuite si la déconnexion coïncide avec la transition. Une coupure qui survient chaque fois que le téléphone passe d'une pièce à l'autre est un problème de liaison jusqu'à preuve du contraire, quel que soit le serveur affiché par l'application.

Lisez les événements de reconnexion du client

La plupart des clients journalisent une raison de la déconnexion et un horodatage pour la tentative suivante. Un tunnel qui renégocie en quelques secondes puis fonctionne est un événement différent de celui qui reste coupé jusqu'à ce que vous le réactiviez à la main.

Les reconnexions brèves répétées pointent vers le chemin extérieur, car le client ne cesse d'atteindre le serveur et de perdre la session. Un tunnel qui reste coupé pointe vers l'authentification, un changement de point de sortie ou une politique, car le client n'arrive pas assez loin pour perdre quoi que ce soit. Lisez les deux motifs séparément avant de toucher à la configuration.

Comparez un second point de sortie avec prudence

Un second point de sortie est une comparaison utile et n'est pas, à lui seul, une expérience contrôlée. Il change la route, l'infrastructure et souvent le pays, donc une différence entre deux points de sortie ne prouve pas que le premier serveur est défectueux.

Gardez l'appareil, le réseau d'accès et la charge de travail fixes et notez ce qui a changé d'autre lors du basculement. Si les deux points de sortie échouent en même temps au même endroit, le chemin local est le facteur commun. Si un seul échoue, le serveur ou la route qui y mène devient la piste. Notez les facteurs de confusion pour que la conclusion ne dépasse pas les preuves.

Corrélez avec le serveur que vous exploitez

Si vous administrez le point de sortie, faites correspondre l'heure de la tentative aux journaux d'écoute et d'association. Plusieurs clients sans rapport qui échouent sur la même passerelle constituent une preuve différente d'un seul téléphone qui tombe à chaque déplacement.

Une seule réponse d'un pair n'établit pas une santé continue de l'application. Après la reprise, testez la ressource dont vous avez réellement besoin, car une poignée de main réussie et un serveur joignable peuvent coexister avec un chemin applicatif cassé.

Rédigez le rapport qui circonscrit le problème

Séparez quatre affirmations : perte de liaison locale, joignabilité extérieure, négociation du tunnel et état propre de l'application. Chacune a ses propres preuves, et un rapport qui les garde distinctes indique à la personne suivante où regarder.

Notez aussi les limites de la comparaison. Si une politique a empêché un test de chemin direct, dites-le au lieu de présenter la comparaison des points de sortie comme une preuve. L'étiquette de pays dans l'application n'identifie pas l'itinéraire complet, et un serveur géographiquement proche peut toujours être atteint par un chemin congestionné.

La page des limitations connues du projet WireGuard rappelle utilement qu'un protocole peut être correct et laisser malgré tout le comportement de la liaison au système d'exploitation. Terminez en répétant le même test après la prochaine déconnexion, car un événement isolé est un point de données et un motif est un diagnostic.