Activer un VPN sur son PC ne suffit pas à garantir que tout le trafic est réellement protégé ou qu’aucune fuite n’existe. Entre le routage, le DNS, les fuites WebRTC, les applications qui contournent le tunnel ou les erreurs de configuration, il est nécessaire de valider techniquement le comportement réel de la connexion.

Cette check-list s’adresse à un utilisateur à l’aise avec Windows et quelques outils en ligne de commande. L’idée n’est pas de “faire confiance à l’icône du client VPN”, mais de vérifier, point par point, ce qu’il se passe sur le fil.

1. Vérifier ce que voit Internet : IP, localisation, opérateur

Première étape : vérifier que, du point de vue d’un service externe, votre adresse IP a bien changé lorsque le VPN est actif.

  • Sans VPN, notez :
    • l’adresse IP publique vue par un site de type “What is my IP” ;
    • le pays et la ville approximative ;
    • l’opérateur (ASN) associé à cette IP (souvent le nom de votre FAI).
  • Activez le VPN, puis vérifiez de nouveau :
    • l’IP doit être différente ;
    • le pays/localisation doivent correspondre à ce que le VPN annonce ;
    • l’opérateur doit être celui de l’hébergeur du serveur VPN, pas votre FAI.

Si l’IP publique ne change pas ou si la localisation reste la même alors que vous avez choisi un serveur distant, il y a un problème de tunnel ou de routage.

2. Vérifier les DNS : détecter les fuites de résolution

Un VPN peut chiffrer le trafic, mais laisser les requêtes DNS passer hors tunnel, ce qui permet à votre FAI ou au réseau local de savoir quels domaines vous consultez.

2.1 Contrôler les serveurs DNS utilisés

Sous Windows, après connexion au VPN, inspectez la configuration réseau : 


ipconfig /all

Repérez :

  • l’interface réseau du VPN ;
  • les serveurs DNS associés à cette interface ;
  • les DNS associés aux autres interfaces (Wi-Fi, Ethernet).

Idéalement :

  • les requêtes DNS doivent utiliser des serveurs associés au VPN (ou un DNS chiffré indépendant, si vous l’avez configuré ainsi) ;
  • pas les DNS de la box ou du FAI lorsque le VPN est censé prendre en charge la résolution.

2.2 Utiliser un test de fuite DNS

Ensuite, lancez un test de fuite DNS (DNS leak test) dans le navigateur avec le VPN activé. Vérifiez :

  • que les serveurs DNS affichés correspondent au pays / à l’opérateur du VPN, ou au service chiffré que vous utilisez ;
  • qu’aucun serveur DNS de votre FAI n’apparaît dans les résultats.

Si des DNS liés à votre FAI apparaissent, la résolution n’est pas entièrement encapsulée par le VPN.

3. Vérifier le routage : routes, passerelle et split tunneling

Le comportement du VPN est dicté par la table de routage. C’est elle qui décide quel trafic part dans le tunnel.

3.1 Inspecter la table de routage

Dans un terminal (CMD ou PowerShell) : 


route print

Points à observer :

  • La route par défaut (0.0.0.0/0) pointe-t-elle vers l’interface VPN ou vers la passerelle locale ?
  • Existe-t-il des routes spécifiques pour certains préfixes (par exemple 10.0.0.0/8, 192.168.0.0/16) via le VPN ?
  • L’interface du VPN apparaît-elle bien dans la liste d’interfaces avec une IP dédiée (souvent en 10.x.x.x ou autre réseau privé) ?

Selon le mode :

  • Full tunnel : la route par défaut doit passer par le VPN.
  • Split tunneling : seules certaines routes passent par le VPN, le reste utilise la passerelle locale.

3.2 Tester le chemin avec tracert

Pour vérifier le chemin réellement emprunté : 


tracert 8.8.8.8
tracert <ip_d_un_service_sensible>

Sur un tunnel bien configuré en full tunnel :

  • le premier saut public devrait être une IP appartenant à l’infrastructure du VPN, pas à votre FAI ;
  • le nombre de sauts peut être différent de celui observé sans VPN.

4. Vérifier le kill switch : que se passe-t-il si le VPN coupe ?

Un “kill switch” a pour objectif de bloquer le trafic Internet si le VPN tombe, pour éviter qu’il continue en clair hors tunnel.

4.1 Test simple de kill switch

Procédure de base :

  1. Activez le VPN.
  2. Ouvrez une commande ping vers une IP externe (par exemple 1.1.1.1) :

ping 1.1.1.1 -t
  1. Coupez volontairement la connexion VPN (bouton déconnexion ou blocage depuis le serveur).
  2. Observez le comportement :
    • si le kill switch est actif et correct, le trafic Internet devrait être interrompu jusqu’à la reconnexion du VPN ;
    • si le ping continue sans interruption et que l’IP est à nouveau celle de votre FAI, le kill switch ne fait pas son travail.

Vous pouvez aussi vérifier dans le navigateur si les pages continuent de se charger lorsque le VPN est déconnecté alors que le kill switch est censé être activé.

5. Vérifier quelles applications passent (ou non) par le VPN

Il est possible que certaines applications contournent le tunnel VPN, volontairement ou non (erreur de configuration, split tunneling, proxy spécifique).

5.1 Monitorer les connexions actives

Utilisez par exemple :

  • netstat -b -n (CMD en administrateur) pour voir quels processus ouvrent quelles connexions ;
  • le Moniteur de ressources Windows (onglet Réseau) pour visualiser les connexions par processus.

Combinez avec un utilitaire qui affiche les interfaces utilisées (ou un filtrage avancé) pour savoir :

  • si une application sensible (client mail, navigateur pro, logiciel métier) utilise bien l’interface VPN ;
  • si certaines applications (jeu, client de mise à jour, service de télémétrie) continuent à sortir via l’interface physique.

Si le client VPN propose un split tunneling par application, vérifiez que la liste des applications incluses/exclues correspond à ce que vous pensez.

6. Vérifier les fuites WebRTC dans le navigateur

WebRTC peut, dans certains cas, révéler des adresses IP locales ou publiques du client, même via un VPN.

Étapes de vérification :

  • Activer le VPN.
  • Utiliser un outil de test WebRTC dans le navigateur.
  • Observer les IP visibles :
    • l’IP publique révélée doit être celle du VPN ;
    • des IP locales privées peuvent apparaître (10.x, 192.168.x.x), ce qui est normal, mais cela peut avoir un impact sur la confidentialité selon le modèle de menace.

Si votre IP publique réelle (côté FAI) apparaît via WebRTC alors que le VPN est actif, il y a une fuite que vous pouvez corriger en :

  • désactivant WebRTC dans le navigateur ou via extension ;
  • configurant le navigateur pour limiter les interfaces utilisables par WebRTC.

7. Vérifier le protocole et la configuration de chiffrement

Même sans pouvoir auditer toute la crypto, vous pouvez au moins vérifier :

  • quel protocole est utilisé (IKEv2, OpenVPN, WireGuard, SSTP, etc.) ;
  • si ce choix est cohérent avec vos besoins (stabilité, performance, filtrage réseau) ;
  • si la configuration ne force pas un mode “faible” (anciennes suites cryptographiques, modes obsolètes).

Selon le client :

  • l’interface graphique indique le protocole en cours d’utilisation ;
  • les fichiers de configuration (pour OpenVPN, WireGuard, IKEv2 manuels) permettent de voir les algorithmes utilisés.

Exemples d’indices :

  • OpenVPN avec TLS récent et AES-256-GCM est aujourd’hui standard ;
  • WireGuard utilise des primitives modernes (ChaCha20, Poly1305) par design ;
  • éviter les protocoles marqués comme obsolètes (PPTP, L2TP sans IPsec).

8. Comprendre les logs côté client et côté serveur

Même si vous n’avez pas accès aux logs serveur d’un fournisseur tiers, vous pouvez examiner :

  • les logs du client VPN sur votre PC (souvent option “journal” ou “log” dans l’application) ;
  • les événements dans le journal Windows liés à la connexion réseau ou au service VPN.

Cela permet de :

  • détecter des déconnexions fréquentes ou des reconnections silencieuses ;
  • voir si des erreurs de négociation cryptographique se produisent ;
  • confirmer que le client applique bien les options que vous avez définies (kill switch, split tunneling, protocole choisi).

Sur un VPN personnel (auto-hébergé), vous pouvez aller plus loin en examinant les logs serveur pour vérifier :

  • les IP client qui se connectent ;
  • les échecs d’authentification (tentatives d’intrusion) ;
  • la cohérence entre ce que vous observez côté client et côté serveur.

9. Bonnes pratiques pour des vérifications régulières

  • Refaire les tests IP et DNS à chaque changement majeur de configuration (nouveau protocole, nouveau client, nouveau serveur).
  • Vérifier le routage dès que vous activez un split tunneling ou que vous ajoutez des routes manuelles.
  • Tester le kill switch après mise à jour du client VPN ou du système.
  • Contrôler périodiquement les fuites WebRTC si vous changez de navigateur ou de configuration.
  • Documenter les comportements attendus (IP VPN, DNS, routes) pour pouvoir comparer rapidement en cas de doute.

Conclusion

Vérifier la sécurité de son VPN sur PC ne se résume pas à “l’icône est verte, donc tout va bien”. C’est un ensemble de contrôles concrets :

  • quelle IP et quels DNS voient réellement les services en face ;
  • comment le trafic est routé (full tunnel ou split) ;
  • ce qu’il se passe lorsque le tunnel tombe ;
  • quelles applications passent à l’intérieur ou à l’extérieur du tunnel ;
  • quelles éventuelles fuites existent (WebRTC, DNS, routes oubliées).

En prenant l’habitude de lancer quelques commandes simples (ipconfig, route print, tracert, netstat) et en utilisant quelques tests en ligne (IP, DNS, WebRTC), vous transformez l’usage du VPN d’une simple croyance en un comportement réseau réellement maîtrisé.

Un VPN correctement configuré, vérifié et régulièrement re-testé devient ainsi une brique fiable de votre architecture de sécurité personnelle, plutôt qu’une boîte noire à laquelle vous faites confiance par défaut.

Bien apréhender sa connexion