Vérifier un VPN avec l’adresse IP et le DNS

Une référence sans VPN permet d’identifier précisément les chemins IP et DNS modifiés pendant le second essai.

Réponse courte

Notez IPv4, IPv6, organisation réseau et résolveurs observés sans VPN, puis recommencez sur le même accès après connexion. Des changements attendus confirment uniquement ces chemins testés ; ils ne prouvent ni protection de toutes les applications ni sécurité complète.

Définir ce que le VPN doit changer

Lisez la documentation du serveur ou du mode choisi : pays de sortie, couverture IPv4 et IPv6, DNS et split tunneling. Sans conception attendue, une valeur inconnue ne peut pas être classée correctement.

Utilisez la même application pour les deux essais et notez DNS privé Android et DNS sécurisé du navigateur.

Créer la référence sans VPN

Déconnectez le VPN en gardant le même Wi-Fi ou réseau mobile. Relevez IPv4 et IPv6 publiques, organisation, pays approximatif, tous les résolveurs et l’heure.

  1. Déconnecter le VPN

    Attendre le tunnel inactif.

  2. Relever les IP

    IPv4 et IPv6 séparément.

  3. Tester DNS à neuf

    Conserver tous les résolveurs.

  4. Noter les réglages

    Réseau, DNS privé et navigateur.

Poursuivez avec Comprendre le DNS et les tests de fuite DNS, comparez avec Pourquoi ma localisation IP est-elle incorrecte ? ou utilisez IP Finder pour Android pour l’étape pratique suivante.

Connecter puis répéter à conditions égales

Connectez le serveur prévu, attendez l’état actif et refaites exactement les mêmes contrôles sans changer l’accès de base.

Comparez région de sortie, familles prises en charge, politique DNS et règles de split tunneling annoncées.

Les détails de protocole de ce guide suivent VPN developer guide et RFC 1034 — Domain Names: Concepts and Facilities ; consultez ces sources primaires pour la terminologie exacte et les cas limites.

Interpréter les changements

Une nouvelle IP attendue montre que le chemin testé présente la sortie VPN. Un nouveau résolveur attendu montre que les noms du test ont atteint l’infrastructure prévue.

Si une famille ou DNS reste inchangé, examinez précisément ce chemin : DNS privé, navigateur, exclusion d’application ou politique intentionnelle peuvent l’expliquer.

Examiner un résultat inattendu

Rechargez le test après connexion, vérifiez IPv4 et IPv6 séparément, split tunneling, DNS privé et navigateur. Essayez un autre serveur en gardant les autres conditions puis consultez la documentation actuelle.

Si l’écart persiste, envoyez au fournisseur référence, résultat VPN, heure, réglages et serveur.

  • Ne pas réutiliser une page chargée avant le VPN.
  • Changer une seule condition.
  • Conserver toutes les familles et tous les résolveurs.
  • Joindre le comportement attendu.

Ce que la comparaison ne certifie pas

Elle échantillonne seulement les chemins IP et DNS des outils utilisés. Elle n’audite pas la cryptographie, toutes les applications, tous les protocoles, l’absence complète de fuite ni l’anonymat.

IP Finder ne modifie pas la route : le résultat est une preuve reproductible pour le support, pas un badge de sécurité.

Interpréter le comparatif avant et après

Une configuration volontaire peut produire plusieurs trajets. Un navigateur exclu du tunnel peut conserver la référence alors qu’une autre application passe par le VPN. Nommez donc l’application testée et comparez les résultats aux règles IPv4, IPv6, DNS et split tunneling du fournisseur.

Ce que le comparatif permet réellement de conclure
ObservationConclusion soutenueQuestion encore ouverte
L’IP publique devient celle du réseau VPN attenduLe trajet public testé présente la sortie VPNToutes les applications et familles l’utilisent-elles ?
Le DNS devient le résolveur attenduLes requêtes de test atteignent l’infrastructure prévueChaque application a-t-elle le même comportement DNS ?
L’IP change mais le DNS reste celui de départLes chemins public et DNS diffèrentDNS privé, navigateur, split tunneling ou politique VPN
Une famille reste inchangéeCette famille doit être examinée séparémentLe VPN la prend-il en charge, la bloque-t-il ou la contourne-t-il ?

Utiliser des tests neufs et séparer les familles

Rechargez le contrôle d’IP après établissement du tunnel et lancez une nouvelle série DNS avec de nouveaux noms. Une page déjà chargée ou une réponse en cache peut encore appartenir à la référence. Gardez le même Wi-Fi ou réseau mobile sous-jacent.

Contrôlez IPv4 et IPv6 séparément, car le tunnel peut traiter une famille autrement. Si un seul résultat diverge, enquêtez sur ce trajet sans changer en même temps DNS, serveur et accès réseau.

Les chemins observés ne constituent pas un audit complet

La comparaison couvre seulement les contrôles IP et DNS réalisés. Elle n’inspecte ni la cryptographie du tunnel, ni chaque application, protocole ou exception possible. Un résultat attendu n’est donc pas un label général de sécurité ou d’anonymat.

Si l’écart persiste, transmettez au fournisseur la référence, le résultat VPN, l’heure, le serveur, la famille d’adresse ainsi que les réglages DNS privé et navigateur. Ces données reproductibles valent mieux qu’une accusation générale de fuite.

Voir les serveurs DNS utilisés par le réseau

Lancez une nouvelle observation DNS sur Android et comparez-la au trajet de résolveur attendu.

Obtenir IP Finder

Questions fréquentes

Que faire si l’IP ne change pas ?
Confirmez le VPN actif, relancez le test, vérifiez le split tunneling et comparez IPv4 et IPv6 séparément.
Et si l’IP change mais pas DNS ?
Contrôlez DNS privé Android, DNS du navigateur, réglage VPN et exclusions ; les deux chemins sont distincts.
Un bon résultat IP et DNS prouve-t-il l’absence de fuite ?
Non. Il confirme uniquement les observations testées à ce moment, pas chaque application ni toute la sécurité du VPN.

Sources

  1. VPN developer guide — Android Developers
  2. RFC 1034 — Domain Names: Concepts and Facilities — IETF

Répéter la comparaison après un changement de réseau

Conservez le contexte, changez de Wi-Fi, de réseau mobile ou d’état VPN, puis relancez la vérification adaptée.

Obtenir IP Finder