Comment tester la stabilité d'un VPN sans journaliser votre navigation

Vous voulez savoir si le tunnel survit à une mise en veille de l'ordinateur portable, à une déambulation entre points d'accès, ou à une heure d'appels, et vous préférez ne donner à personne un journal de tout ce que vous lisez en le découvrant. Trois choses y répondent : une sonde fixe, les mêmes quatre faits échantillonnés selon un planning et l'événement qui les a modifiés, consigné. Dix minutes de cela valent mieux qu'un après-midi à regarder une page ne pas se charger. Le journal qui vous reste est aussi assez court pour être joint à un ticket sans en masquer la moitié.

Décidez ce que stable doit vouloir dire

« Le VPN est tombé » recouvre quatre défaillances différentes sous un seul mot. Le pair peut perdre sa poignée de main, la route peut retomber sur la passerelle locale, la résolution de noms peut partir vers un serveur qui ne répond jamais par le tunnel, ou tout cela peut être sain tandis qu'une application échoue encore. Décidez laquelle correspond à votre symptôme avant de collecter quoi que ce soit, car chacune demande une sonde différente. Choisissez ensuite un intervalle que vous pouvez tenir : un échantillon toutes les trente secondes pendant dix minutes attrape une itinérance sans transformer le test en charge de travail.

Si la plainte est un appel qui se fige quand vous allez à la cuisine, la propriété dont vous avez besoin est de savoir si une requête fraîche aboutit après l'itinérance. Cela se vérifie en une ligne et n'enregistre aucune navigation.

Fixez une sonde inoffensive

Choisissez une destination que vous êtes autorisé à interroger et qui n'est pas liée à vos comptes : un hôte de documentation, un point de terminaison d'état interne ou la passerelle du tunnel elle-même. Rendez l'opération reproductible, par exemple curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://example.com/, qui imprime une ligne par tentative. Gardez ce format de sortie fixe pendant toute l'exécution. Un code d'état et une durée collectés de la même façon deux fois sont ce qui rend deux exécutions comparables.

Résistez au site sur lequel vous comptez réellement. Une page de banque ou de webmail traîne des traqueurs, des redirections et du contenu personnel dans la mesure, et imprime des identifiants de session dans tout ce que vous collerez plus tard dans un ticket. Utilisez la même destination pendant toute l'investigation et notez-la à côté de l'intervalle.

Échantillonnez les quatre faits

L'état du pair, la route, le résolveur et une requête fraîche sont les quatre observations, et chacune a une source bon marché. Sur WireGuard, wg show wg0 latest-handshakes donne l'horodatage du pair et ip route get 1.1.1.1 montre quelle interface le noyau utiliserait. Sur OpenVPN, le même état se trouve dans le fichier d'état écrit par --status /run/openvpn/status 10 ou derrière state sur l'interface de gestion. Un client Windows reste dans PowerShell avec Get-NetAdapter et Resolve-DnsName.

Bouclez-les dans un seul terminal pour que chaque ligne porte un horodatage : for i in $(seq 1 20); do date -Is; wg show wg0 latest-handshakes; ip route get 1.1.1.1; sleep 30; done. Cette boucle couvre trois des six champs du journal ; la version du client s'inscrit une fois en haut, et l'horodatage de l'événement s'ajoute quand l'événement survient.

Le résolveur est le fait que les gens sautent, et dig +short le cache, car cette forme n'imprime que la réponse. Demandez le serveur explicitement avec dig example.com | grep SERVER:, ou utilisez nslookup example.com là où dig n'est pas installé, qui imprime l'adresse du serveur où la requête est allée. Une vieille poignée de main sur un tunnel inactif n'est pas non plus une faute automatique, puisque WireGuard ne renouvelle les clés que lorsqu'il y a du trafic à protéger.

Provoquez l'événement, pas une fuite

Prenez cinq minutes calmes comme ligne de base avant l'événement qui vous intéresse, qu'il s'agisse de fermer le capot, de marcher vers un autre point d'accès ou de passer au partage de connexion d'un téléphone. Notez l'heure à laquelle vous l'avez provoqué, afin que les échantillons de part et d'autre puissent être alignés.

Sans cet horodatage, le journal montre un trou et personne ne peut dire si c'est le client ou le réseau qui l'a fermé. Deux exécutions avec l'événement à des endroits différents valent plus que dix sans. Utilisez les commandes de déconnexion et de reconnexion du client lui-même. Ne désactivez pas le kill switch et ne poussez pas de trafic hors du tunnel pour voir ce qui se passe, car sur un portable géré c'est une violation de politique et sur votre propre machine cela crée exactement l'exposition que vous testiez.

Gardez un journal assez petit pour être terminé

Six champs par échantillon : heure, version du client, point de terminaison, réseau d'accès, événement, résultat. Laissez de côté les adresses web, les charges utiles, les jetons et tout ce qui porte un identifiant de session, car le journal est une preuve sur le tunnel et rien d'autre. Gardez-le à côté de la boucle pour que la personne suivante puisse le relancer sans demander ce que signifient les colonnes.

Après un changement, répétez le test avec la même sonde et le même intervalle ; si vous échangez la destination et la version du client ensemble, le résultat n'appartient à aucune des deux. Une exécution propre de dix minutes est une preuve pour ces conditions et cette destination, pas une promesse sur le réseau de l'hôtel le mois prochain. Conservez le script et le modèle de journal là où vous les trouverez. Les limitations documentées de WireGuard méritent d'être lues avant d'attribuer une coupure au protocole.