Tester une allégation de confidentialité VPN : gardez des preuves qui tiennent

Le test commence par une phrase que quelqu'un veut vraie, et les preuves soutiennent soit une version étroite de celle-ci, soit rien du tout. Une vérification de l'adresse publique montre quelle sortie une requête a utilisée. Elle ne montre pas ce que le fournisseur conserve, qui peut le lire, ni ce qui arrive à une session qui ne se termine jamais. Parcourir le test comme une procédure documentée vous empêche d'affirmer plus que ce que la mesure peut porter.

Choisissez une allégation observable

Écrivez l'allégation sous forme d'une seule phrase vérifiable avant d'ouvrir le moindre outil : pour ce profil, sur ce réseau, les requêtes vers un écho d'adresse publique sortent par la sortie déclarée du fournisseur. Cette phrase nomme un sujet, une condition et une observation, et c'est ce qui la rend réfutable. Une allégation comme le VPN protège la vie privée n'a pas de forme observable, donc aucune mesure ne peut la trancher. Gardez une seconde phrase pour ce que le test ne couvrira pas, car la conservation, l'accès des tiers et la corrélation du trafic se situent tous hors d'un test dans le navigateur.

Écrivez cette seconde phrase à l'avance, pas après l'arrivée du résultat. Il est bien plus facile d'être honnête sur la portée tant que l'issue est encore inconnue qu'après qu'une capture d'écran rassurante a atterri dans le ticket. Une note de portée ajoutée après coup tend à décrire le résultat plutôt que la question.

Faits de montage dont un lecteur a besoin pour répéter la mesure

Le montage est ce qui rend un résultat reproductible, et c'est précisément ce que les gens sautent quand la réponse semble bonne. Les chaînes de version, les noms de profil, le réseau d'accès et les familles d'adresses appartiennent à la note, avec toute règle de partage du tunnel qui pourrait faire sortir le trafic du tunnel. Nommez aussi l'événement testé, car une connexion qui fonctionne, une coupure inattendue, une déconnexion manuelle et un transfert de réseau exercent des règles différentes. Un test qui mélange ces événements prouve peu de chose sur chacun d'eux.

Utilisez un trafic non sensible dans un environnement où vous êtes autorisé à tester. Capturer des paquets sans rapport donne au dossier un air technique et ajoute de l'exposition sans ajouter de preuves. Dirigez la capture vers l'interface du tunnel uniquement, et fixez une limite de taille de fichier pour qu'une longue exécution ne remplisse pas le disque. Arrêtez la capture avant de changer quoi que ce soit, afin que le fichier corresponde à la ligne de montage que vous avez écrite.

Dites ce qui a été mesuré et ce que cela signifie

Consignez ce que l'outil a affiché et ce que l'outil pouvait voir. Une réponse de résolveur, un résultat d'écho d'adresse et une recherche de route répondent à des questions différentes, et une étiquette de localisation dans une page web est une inférence sur une base de données, non un fait sur la sortie. Écrivez la commande qui a produit chaque ligne à côté de celle-ci, car une valeur sans sa commande ne peut pas être reproduite. Gardez l'horodatage dans le même fuseau horaire que le ticket de changement, sinon la séquence devient illisible une semaine plus tard.

curl -s https://icanhazip.com
curl -s https://ipinfo.io/ip; echo
resolvectl status --no-pager | head -15

Deux services d'écho indépendants qui concordent sont plus forts qu'un seul, et un désaccord est en soi une constatation qui mérite d'être notée. La sortie du résolveur montre si le DNS a suivi le tunnel ou a continué d'utiliser le réseau local, ce qui est une allégation distincte de l'adresse de sortie. Enregistrez la sortie brute avec un horodatage et conservez les résultats contraires plutôt que la capture d'écran la plus rassurante. Quand un changement déplace le résultat, appliquez une variable à la fois, car changer serveur et client ensemble vous laisse incapable de dire lequel a compté.

Ce qui appartient au dossier, et ce qui doit être retiré

Conservez la méthode, la sortie non secrète et les limites, puis retirez le reste. Les profils porteurs d'identifiants, les noms d'hôte privés et les identifiants de compte n'ont pas besoin de voyager avec les preuves, et un dossier de test qui les divulgue a endommagé ce qu'il était censé démontrer. Les cinq champs ci-dessous sont la forme la plus courte qui survive encore à une transmission.

Joignez la déclaration de politique à laquelle vous comparez, avec sa date et sa portée. RFC 6973 encadre l'analyse de confidentialité autour d'observateurs nommés et d'une portée définie, et ce cadre convient à un dossier de test : qui pouvait observer quoi, dans quelles conditions et quelles parties sont restées non examinées.

Terminez par un paragraphe qui déclare ce que les preuves soutiennent et ce qu'elles ne soutiennent pas. Ce paragraphe est le livrable, et tout ce qui précède existe pour le rendre honnête. S'il ne peut pas être écrit sans nuancer chaque clause, le test a mesuré moins que ce que le ticket affirme.