Un opérateur VPN peut-il voir quels sites vous visitez ?

Demandez ce que le VPN peut voir, et la réponse dépend de l'endroit où vous vous situez dans le chemin. Au niveau de la session, l'opérateur dispose des événements d'authentification et des comptages d'octets. Au niveau des paquets, des adresses de destination et des horodatages. Au niveau DNS, il peut avoir les noms eux-mêmes. Chaque couche répond à une question différente, et aucun interrupteur ne vous fait passer de l'une à l'autre.

Cartographiez la couche avant toute affirmation

La même connexion produit des enregistrements différents à chaque point, et une affirmation sur la confidentialité n'a de sens que lorsqu'elle nomme le point. Lisez le tableau colonne par colonne : ce qui existe à cette couche, ce qu'un opérateur peut y voir et ce que ces mêmes enregistrements ne peuvent toujours pas lui dire.

Lire une seule couche comme si elle était toute l'image, c'est ainsi que commencent les exagérations comme le faux réconfort. Un fournisseur qui dit ne pas journaliser la navigation peut être exact sur la journalisation des URL tout en conservant des enregistrements de session, et une capture de paquets qui ne montre que des adresses ne devient pas un historique de navigation sans recherches inverses et suppositions.

Quand vous évaluez une politique, trouvez la phrase qui décrit chaque couche. Si la politique ne les sépare pas, demandez quels enregistrements existent plutôt que d'accepter une déclaration générale sur le chiffrement.

Inventaire des sessions : ce qu'un serveur OpenVPN standard conserve

Dès l'installation, un serveur OpenVPN ne capture pas le trafic. La sortie normale est un inventaire de sessions : le compte qui s'est authentifié, l'adresse source d'où il venait, les horodatages de début et de fin, l'adresse de tunnel attribuée et les totaux d'octets dans chaque sens. C'est un inventaire de sessions, pas une liste de destinations.

Les options de journalisation peuvent ajouter du détail. Un niveau de verbosité plus élevé écrit davantage sur la poignée de main, et un fichier d'état peut lister les clients connectés, mais ni l'un ni l'autre ne transforme le serveur en proxy transparent. Produire des URL exige de terminer le TLS ou d'exécuter un proxy explicite, et les deux changent l'accord de confiance au lieu d'activer une fonction cachée.

C'est pourquoi la version exacte de l'affirmation sans journal de navigation est plus étroite qu'elle n'en a l'air. Le serveur ne connaît pas la page, mais il sait qu'une session a existé et environ combien de données l'ont traversée. Que cet enregistrement de session soit conservé, et pendant combien de temps, est une question de politique distincte.

Les paquets internes et externes sont des preuves différentes

Une capture de paquets est la façon de voir ce qui traverse réellement le tunnel. Sur le serveur, nommez l'interface du tunnel et écrivez dans un fichier analysable hors ligne :

sudo tcpdump -ni tun0 -w /tmp/tun.pcap
sudo tcpdump -r /tmp/tun.pcap -nn | head

Ce fichier contient le trafic interne déchiffré : l'adresse de tunnel du client comme source, l'adresse et le port de destination, les tailles de paquets et les horodatages. Il ne contient pas le chemin HTTP ni le corps de la réponse, sauf si le TLS a été terminé quelque part, et ce sont des données sensibles dont la conservation est une décision de politique et non une commodité de débogage.

Une capture sur l'interface physique montre autre chose. On y voit les paquets externes adressés au point de terminaison du VPN, avec la charge chiffrée à l'intérieur. Des adresses sans rapport dans ce fichier sont normales dès qu'un adaptateur virtuel existe, car l'interface de tunnel porte les flux internes tandis que le transport chiffré porte les externes.

Demandez à quelle question la capture doit répondre. L'usage du tunnel par une application est visible sur l'adaptateur virtuel ; l'accessibilité du tunnel jusqu'au point de terminaison est visible sur l'interface physique. Utiliser l'un ou l'autre fichier comme s'il était l'image complète produit des conclusions que les données ne soutiennent pas.

Le DNS est là où les noms deviennent visibles

Le DNS reste l'exception pratique. Le résolveur voit les noms qu'on lui demande de résoudre, donc qui l'exploite apprend quels sites un client consulte, même lorsque les connexions ultérieures sont chiffrées. Une capture du tunnel montre des adresses ; le résolveur montre des noms.

Vérifiez quelle adresse le résolveur a utilisée pour joindre un service extérieur. La réponse est l'adresse de sortie du résolveur, et la comparer à la sortie du VPN vous dit si la requête a voyagé dans le tunnel :

dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53

Si cette adresse correspond à la connexion locale et non à la sortie du tunnel, la recherche a contourné le VPN et le nom était visible sur le chemin local. Refaites le contrôle après une mise à jour du client, car une nouvelle version peut changer le résolveur installé par le profil.

Le DNS chiffré déplace la visibilité au lieu de la supprimer. Le réseau ne voit plus la requête, mais le résolveur la voit encore, et la question de confiance change simplement de mains. Le nom de serveur TLS dans la poignée de main de la connexion est un autre signal partiel : il survit souvent même lorsque la charge est opaque, si bien que les adresses de destination ne sont pas les seules métadonnées qu'un serveur de transfert peut observer.

Trois types d'enregistrements et qui peut les lire

La comptabilité des sessions, les enregistrements par nom et les preuves de fuite sont trois produits différents avec trois obligations différentes. Les journaux de session sont bon marché et peu sensibles, et ils répondent qui s'est connecté et quand. Les enregistrements par nom exigent un résolveur journalisant ou un proxy explicite, et ils créent une obligation de divulgation envers les personnes concernées. La preuve de fuite est un test côté client qui compare ce que le résolveur révèle à la sortie du tunnel.

Notez lequel de ces trois vous exploitez, qui peut le lire et combien de temps il reste. Les affirmations selon lesquelles un service ne tient aucun journal décrivent une couche, et elles ne restent vraies que dans ce périmètre. Le même fournisseur peut être exact sur les sessions et se tromper sur le DNS.

Gardez le test reproductible : la même requête au résolveur, la même interface de capture et la même comparaison. Une affirmation de confidentialité qui ne peut pas être testée sur une couche nommée est un slogan, pas un fait opérationnel.