Comment tester un coupe-circuit VPN sans vos vrais comptes
Lancez un test de coupe-circuit avec une page leurre et un profil de secours : couvrez chaque type de coupure, lisez les codes de sortie de curl et distinguez un vrai blocage d’une panne DNS.
Vous n’avez pas besoin d’un vrai compte pour savoir si un coupe-circuit tient ; c’est exactement ce qu’un test met en jeu. La vérification crée une courte fenêtre où le trafic peut ou non sortir du tunnel, donc la charge utile doit être quelque chose que vous pouvez perdre. Je procède désormais avec une page leurre et un profil de navigateur de secours, et cela donne une réponse plus claire que la routine navigateur-plus-webmail que j’utilisais avant. Ce qui suit suit le même ordre que celui présenté par le client : le réglage, la destination, la transition, puis les preuves.
Le test répond à une question étroite : pendant cette transition, cette application peut-elle atteindre le réseau hors du tunnel ? Il ne dit rien de la pertinence du reste de la politique. Gardez le périmètre aussi étroit et le résultat mérite d’être noté.
Trouvez le commutateur et son périmètre dans le client
Ouvrez le client et repérez le réglage de blocage avant de changer le moindre état réseau. Les éditeurs le nomment différemment : coupe-circuit, mode verrouillage, verrou réseau, bloquer le trafic hors du tunnel. L’étiquette en dit moins que les options qu’elle contient. Ce qui compte, c’est si le blocage s’applique toujours, ou seulement quand l’application estime qu’un tunnel vient d’échouer, et s’il couvre toutes les applications ou une liste choisie.
Énumérez ensuite les transitions que votre client peut réellement effectuer. Une déconnexion lancée par l’utilisateur, la fermeture de l’application et la perte de contact avec le serveur sont trois chemins de code différents dans la plupart des clients, et ils ne partagent pas une seule politique de blocage. Certains libèrent le blocage à la fermeture. D’autres laissent les règles de filtrage installées jusqu’à ce que quelque chose les supprime. Lisez la référence des réglages de l’éditeur pour la version que vous exécutez au lieu de supposer, puis notez laquelle des trois vous testez.
Notez aussi le profil : protocole, familles d’adresses et activation ou non du tunnel divisé. Une affirmation sur l’appareil entier n’a pas de sens si le profil exclut délibérément quelques applications, et une exclusion que vous avez configurée n’est pas une fuite. La référence des réglages d’OpenVPN Connect est le genre de page qui indique quel commutateur change quel comportement, même si les libellés diffèrent selon le client.
Choisissez une destination leurre qui fonctionne aussi sans le tunnel
Le leurre doit avoir deux propriétés, et en omettre une seule donne un résultat illisible. Il doit être joignable directement quand le tunnel est coupé et le blocage désactivé, sinon « il a cessé de répondre » peut simplement signifier que l’hôte a disparu. Et il ne doit demander ni connexion, ni cookie, ni paiement, pour qu’une fuite vous coûte une ligne de journal au lieu d’une session.
Une page statique sur un hôte que vous contrôlez est le choix propre. Une machine virtuelle de secours servant un simple serveur HTTP fait presque aussi bien, et une page publique de test de connectivité convient si vous acceptez que sa disponibilité échappe à votre contrôle. Notez l’adresse, le port, la famille d’adresses et si la requête exige une résolution de nom, car chacun de ces éléments devient une variable que vous devrez peut-être isoler plus tard.
Établissez la référence avant de toucher au commutateur. Tunnel actif, le leurre doit répondre à travers le tunnel, ce qui prouve que la route de la politique fonctionne. Tunnel coupé et blocage désactivé, il doit répondre directement, ce qui prouve que la destination est vivante. C’est seulement alors qu’un échec dans l’état bloqué vous apprend quelque chose.
Exécutez les transitions dans un ordre fixe
Prenez les transitions une par une et laissez à chacune quelques secondes pour se stabiliser, car les clients démontent et reconstruisent souvent des règles dans cet intervalle. Exécuter la même vérification courte à chaque fois garde les observations comparables :
curl -sS -o /dev/null -w 'http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_exit=$?"
dig +short decoy.example
curl -6 -sS -o /dev/null -w 'v6_http=%{http_code}\n' --max-time 5 http://decoy.example/
echo "curl_v6_exit=$?"| Transition | Expected with the block on | Failure signature |
|---|---|---|
| Manual disconnect | Decoy stops answering within seconds | Decoy still returns 200 |
| Server or path failure | Blocked, with no exemption for the old endpoint | Direct access during the gap |
| Quit the app | Client-dependent; record what happens | Block disappears with the process |
| Wi-Fi to Ethernet | Block holds until the tunnel returns | Traffic flows mid-change |
La ligne sur la fermeture de l’application mérite sa propre exécution même si vous ne fermez jamais le client en usage normal. Si le blocage se libère à la fermeture, un plantage ou une mise à jour forcée vous offre la même exposition, et c’est un fait sur le déploiement, pas sur votre patience. Sous Windows, les sondes équivalentes sont Resolve-DnsName decoy.example et curl.exe -s -o NUL -w "%{http_code}" http://decoy.example/.
Distinguez un blocage d’un résolveur cassé
Une page qui ne se charge pas a plusieurs causes, et une seule est le commutateur qui fonctionne. Si le nom ne se résout pas, vous avez appris que le DNS est bloqué ou cassé, pas que le chemin des données est bloqué. Sondez aussi une adresse littérale, pour que la réponse ne dépende pas du tout de la résolution.
Les codes de sortie de curl séparent ces cas : 6 est un échec de résolution de nom, 7 signifie que la connexion a été refusée, 28 est un délai d’attente. Une route bloquée se manifeste généralement par un délai d’attente ou un refus face à une adresse littérale. Un blocage DNS seul laisse un 6 et cache tout le reste. Une page en cache ou un portail captif trompe l’œil, c’est pourquoi le code de sortie, et non l’écran, est la preuve.
Répétez la sonde en IPv6 avec une adresse littérale. Un blocage qui couvre IPv4 et ignore IPv6 est assez courant pour mériter sa propre ligne dans vos notes, et un client qui désactive IPv6 hors du tunnel devrait échouer proprement sur les deux familles.
Notez le périmètre que couvre le résultat
Quand le tunnel revient, confirmez la reprise : le leurre répond à travers le tunnel, le résolveur renvoie des réponses et la politique reste là où vous l’avez laissée. Puis annulez les expériences. Une règle de pare-feu temporaire, une route de débogage ou un profil de test laissés en place brouilleront la prochaine exécution et peuvent survivre à l’application.
Une seule passe couvre une version de client, un profil, une transition et une famille d’adresses. Notez ces quatre éléments avec le résultat :
- Version du client et plateforme, et si le réglage est par profil ou global.
- Profil, protocole et éventuelles exclusions de tunnel divisé.
- Transition testée, et comment vous l’avez déclenchée.
- Familles d’adresses et DNS, avec les codes de sortie de curl pour les états bloqué et débloqué.
Si une ligne reste vide, le test n’est pas terminé. L’itinérance signifie répéter la ligne du changement de réseau. Un redémarrage sans surveillance signifie vérifier que les règles reviennent, ce qui est une question d’ordre de restauration et non de commutateur. Relancez la séquence après une mise à jour du client, car les commutateurs changent rarement alors que le comportement derrière eux change. Gardez le leurre : rien à faire tourner, et la prochaine vérification prend cinq minutes.