technologie

Comment vérifier les fuites DNS et les fuites WebRTC : diagnostic en 6 étapes et solution par cause

Une fuite DNS est un phénomène dans lequel seules les requêtes DNS quittent le tunnel VPN, et une fuite WebRTC est un phénomène dans lequel les requêtes STUN quittent le proxy, révélant la véritable adresse IP. Nous résumons le diagnostic en 6 étapes en utilisant uniquement le navigateur, les solutions pour 8 causes et les méthodes de gestion pour l'application StageVPN et l'extension Chrome.

L'équipe StageVPN22 minutes de lecture

Illustration 3D représentant un petit morceau de lumière s'échappant d'un passage bleu en forme de tuyau.

Si vous voyez l'un des symptômes ci-dessous même après avoir activé le VPN, suspectez une fuite DNS ou une fuite WebRTC. Une fuite se produit lorsque des informations censées passer par le chemin VPN quittent ce chemin (également appelée exfiltration).

  • L'IP du serveur VPN est affichée sur la page de vérification IP, mais le serveur DNS de l'entreprise de télécommunication ou du routeur est affiché dans le test DNS.
  • L'adresse IPv4 a changé, mais l'adresse IPv6 est la même qu'avant la désactivation du VPN.
  • Sur la page de test WebRTC, l'adresse IP publique apparaît telle qu'elle était avant la désactivation du VPN.
  • L'adresse IP d'origine n'est visible qu'immédiatement après le passage du Wi-Fi aux données mobiles ou la sortie du mode veille.
  • J'ai activé StageVPN pour Chrome, mais d'autres navigateurs et programmes PC se connectent en utilisant l'adresse IP d'origine.
  • Même avec le VPN activé, le site affiche la langue et le contenu en fonction de la région d'origine (cela peut être dû aux paramètres du compte/des cookies).

La fuite DNS est un phénomène dans lequel la communication Web passe par le tunnel lorsque le VPN est activé, mais seules les requêtes DNS sortent du tunnel et le nom de domaine est visible par le serveur DNS de l'entreprise de télécommunication ou du Wi-Fi. La fuite WebRTC est un phénomène dans lequel le WebRTC du navigateur envoie une requête STUN directement depuis le VPN/proxy, permettant à la page Web de découvrir l'adresse IP publique réelle. Aucun de ces phénomènes ne signifie que le contenu de la page fuit. Cependant, il révèle « qui accède à où ». Cet article commence par les symptômes et passe par six étapes de diagnostic, de résolution par cause et de réexamen.

Même si le trafic Web est protégé, seules les requêtes DNS sont émises.
Même si le trafic Web est protégé, seules les requêtes DNS sont émises.

Diagnostic : Comment rechercher une fuite en 6 étapes

Le principe de la vérification des fuites est de comparer les valeurs avec le VPN désactivé et avec celui-ci activé. Comparez l'adresse IP affichée sur le site, le serveur qui a reçu la requête DNS et l'adresse du candidat WebRTC. Si les valeurs d'origine sont visibles même après avoir activé le VPN, il s'agit d'une fuite. Les tests n'ont de sens que sur les appareils et les navigateurs que vous utilisez réellement. Même si vous ne disposez pas d'un site de test spécifique, vous pouvez vérifier la plupart des choses simplement en utilisant un navigateur. La page de vérification IP est une page Web qui affiche l'adresse IP publique de la personne connectée à l'écran. Vous pouvez le trouver dans un moteur de recherche sous « Vérifier l’IP ». Recherchez la page de test de fuite DNS et la page de test WebRTC de la même manière. Le principe est le même quelle que soit la page que vous utilisez, vous n’avez donc pas besoin de vous appuyer sur un site précis.

  1. Désactivez le VPN et enregistrez votre IP. Ouvrez la page de vérification IP et notez l'adresse IPv4 publique et, si elle est présente, l'adresse IPv6. Cette valeur constitue la base de toutes les comparaisons ultérieures.
  2. Allumez votre VPN et comparez les IP. Après avoir vérifié l'indicateur d'achèvement de la connexion sur l'application StageVPN ou l'indicateur vert ON sur l'icône StageVPN pour Chrome, ouvrez à nouveau la même page. IPv4 doit être remplacé par l'adresse de votre serveur VPN.
  3. Vérifiez votre serveur DNS. Ouvrez la page Test de fuite DNS. Ces pages interrogent des sous-domaines aléatoires, puis affichent le serveur DNS qui a envoyé la requête. Si vous pouvez voir les serveurs de votre opérateur ou de votre routeur, il s'agit d'une fuite DNS.
  4. Ouvrez chrome://webrtc-internals. La saisie de cette adresse dans la barre d'adresse de Chrome affichera les connexions WebRTC en cours et les adresses des candidats. L'élément apparaîtra si la page de test WebRTC ou la page d'appel vidéo est ouverte dans un autre onglet.
  5. Vérifiez l'adresse IP du candidat. Si l'adresse du candidat srflx (réflexion du serveur) est la même que l'adresse IP publique d'origine de l'étape 1, il s'agit alors d'une fuite WebRTC. S'il s'agit de l'adresse IP du serveur VPN ou si seuls le nom .local et l'adresse IP privée sont visibles, l'adresse IP publique n'est pas exposée.
  6. Vérifiez IPv6. Si vous aviez une adresse IPv6 à l'étape 1, activez le VPN et voyez si cette adresse a disparu ou a changé. Si tel est le cas, IPv6 quitte le tunnel. Basculez entre le Wi-Fi et les données mobiles et répétez pour voir si les résultats sont les mêmes après le redémarrage du navigateur.
Tableau 1. Comment lire les résultats du diagnostic
Résultats des observationssignificationCause suivante
IP du serveur VPN visible sur siteLes communications Web passent par le chemin VPNNormal, prochaine étape
IPv4 a changé, mais IPv6 est l'adresse d'origineIPv6 quitte le tunnelCause 2
Le serveur DNS provient de l'entreprise de télécommunication ou du routeur.Fuite DNSCauses 1, 3, 4, 5
Le serveur DNS est un fournisseur DNS publicDNS dans votre configuration VPN ou un DNS sécurisé que vous spécifiez vous-même.Ne présumez pas qu'il s'agit d'une fuite uniquement basée sur le nom de l'entreprise, vérifiez la cause 4.
L'adresse IP publique d'origine est visible dans WebRTCFuite WebRTCCauses 6 et 7
Seuls les noms .local ou les IP privées sont visibles dans WebRTCL'adresse IP publique n'est pas exposéegénéralement normal
IP d'origine uniquement immédiatement après le changement de réseauécart au moment de la transitionCause 8

Les résultats peuvent varier selon le site de test. Il existe des endroits qui affichent uniquement IPv4 et des endroits qui affichent IPv6, et les méthodes de recherche de serveurs DNS sont également différentes. Comparez à plusieurs endroits et en passant à plusieurs réseaux.

Que révèle une requête DNS ?

Les requêtes DNS contiennent des noms de domaine. Le contenu de la page ou les valeurs saisies ne sont pas inclus. DNS est le système de carnet d'adresses d'Internet qui convertit les noms de domaine lus par les humains en adresses IP utilisées par les ordinateurs. Chaque fois que vous saisissez une adresse dans votre navigateur ou qu'une application contacte un serveur, votre appareil demande d'abord au serveur DNS « quelle est l'adresse de ce nom ? Ainsi, en consultant simplement l’historique des requêtes, vous pouvez en savoir beaucoup sur le moment et le service auquel vous avez essayé d’accéder.

  1. mon appareilApplication/Navigateur
  2. Wi-Fi publicrouteur de café
  3. DNS de l'opérateurserveur existant
  • Zones pouvant être exposées
Figure 1. En cas de fuite DNS : les communications Web passent par le tunnel, mais les requêtes DNS sont envoyées vers le réseau actuel.
  1. mon appareilApplication/Navigateur
  2. Wi-Fi publicrouteur de café
  3. serveur VPNStageVPN
  4. serveur DNSSpécifier dans la configuration VPN
  • Cryptage VPN
Figure 2. Sans fuites : les requêtes DNS entrent également dans le tunnel et le serveur DNS voit l'adresse IP du serveur VPN.

Les requêtes DNS traditionnelles sont envoyées au port UDP 53 en clair. Pour compenser cela, DoH (RFC 8484), qui encapsule les requêtes en HTTPS, et DoT (RFC 7858), qui encapsule les requêtes en TLS, ont été créés. Cependant, même si vous utilisez un DNS chiffré, le nom du serveur (SNI) envoyé lors de la connexion à un site via HTTPS peut être visible sur le réseau si le site et le navigateur ne supportent pas ECH (Encrypted Client Hello).

Tableau 2. Où trouver les noms de domaine par méthode de transfert DNS.
mode de livraisonObservateur sur le même Wi-FiOpérateur Wi-Fi/entreprise de communicationServeur DNS recevant la requête
DNS brut (texte clair)peut voirpeut voirVisible, avec mon IP publique
DoH/DoT (DNS crypté)je ne peux pas voirNon visible, les adresses des serveurs DNS sont visiblesVisible, avec mon IP publique
DNS dans un tunnel VPNje ne peux pas voirNon visible, voit seulement qu'il communique avec le serveur VPNVisible, avec IP du serveur VPN
État de la fuite DNSS'il s'agit de texte brut, vous pouvez le voir.peut voirVisible, avec mon IP publique

Le DNS sécurisé (DoH) et le VPN ont des objectifs différents. DoH chiffre uniquement les requêtes DNS ; le site accède lui-même et les adresses IP que le site voit restent les mêmes. Un VPN crypte l'intégralité de la communication entre votre appareil ou navigateur et le serveur VPN et modifie l'adresse IP vue par les sites. Le mode navigation privée n’arrête pas non plus les fuites. Le mode navigation privée est une fonction qui ne laisse ni historique ni cookies sur l'appareil, et ne modifie pas les requêtes DNS ou les routes WebRTC.

Comment WebRTC détermine-t-il une adresse IP ?

WebRTC trouve sa propre adresse de plusieurs manières pour connecter deux appareils par le chemin le plus court et transmet les résultats au script sur la page Web. WebRTC est une technologie Web standard qui vous permet de passer des appels vidéo, des appels vocaux et des transferts de fichiers sans plug-ins dans votre navigateur. Le processus de collecte d'adresses est appelé ICE (RFC 8445). Même les pages qui ne passent pas d'appels vidéo peuvent démarrer ce processus avec un script.

  1. Créer un objet de connexionLe script de page Web crée RTCPeerConnection
  2. Rassembler les candidats locauxVotre navigateur rassemble les adresses des appareils réseau de votre appareil
  3. Requête STUNDemandez au serveur STUN « à quoi ressemble mon adresse » avec UDP
  4. Livraison du candidatUne liste de candidats comprenant les adresses publiques fournies par le serveur STUN est livrée sur la page.
Figure 3. Ordre dans lequel WebRTC rassemble les adresses candidates à la connexion (ICE)
Tableau 3. Types de candidats à la connexion WebRTC et informations pouvant être révélées
Type de candidatquelque choseInformations susceptibles d'être révéléesProtection des navigateurs récents
hôteAdresse du périphérique réseau de la machineIP privée (192.168.x, etc.)Masqué avec un nom .local aléatoire (mDNS), mais peut être vu sur les sites qui ont accordé des autorisations de caméra et de microphone.
srflx (réflexion du serveur)Mon adresse publique vue par le serveur STUNIP publique, vraie IP si vous contournez le proxyPeut être restreint par la politique de traitement IP WebRTC
relaisTURN Adresse du serveur relaisIP du serveur relaisSi vous utilisez le relais, l'autre partie verra l'adresse du serveur au lieu de votre IP.

Le problème est la requête STUN à l'étape 3. Les proxys du navigateur transmettent les requêtes Web, mais les communications UDP de WebRTC ne passent pas par le proxy dans les paramètres par défaut du navigateur. L'adresse fournie par le serveur STUN n'est donc pas le serveur proxy, mais mon IP publique d'origine. Les choses sont différentes avec les VPN à l’échelle de l’appareil. Étant donné que toutes les communications UDP, y compris les requêtes STUN, transitent vers le tunnel, l'adresse vue par le serveur STUN est également l'adresse IP du serveur VPN.

Proxy du navigateur et politique par défaut

  • Les requêtes Web passent par un proxy
  • Les requêtes STUN vont directement à UDP
  • La page peut voir la véritable adresse IP publique

Proxy du navigateur et Disable_non_proxied_udp

  • Empêcher UDP de passer par proxy
  • WebRTC utilise uniquement des chemins proxy
  • Certains appels ont des méthodes ou une qualité de connexion différentes

VPN à l'échelle de l'appareil

  • Les requêtes STUN passent également par le tunnel.
  • Le candidat à l'adresse publique est l'adresse IP du serveur VPN
  • La déconnexion et la gestion IPv6 nécessitent une confirmation
Figure 4. Potentiel de fuite WebRTC en fonction de la méthode de connexion

Chrome dispose d'une « politique de gestion IP WebRTC » qui détermine quelle adresse WebRTC utilisera, et les extensions peuvent modifier cette valeur. Chaque valeur correspond à quatre méthodes décrites dans la recommandation de gestion des adresses IP WebRTC de l'IETF (RFC 8828).

Tableau 4. Valeurs de la stratégie de gestion IP WebRTC de Chrome (basées sur l'API chrome.privacy)
valeur politiquemouvementplage d'exposition
défautCollectez les candidats de tous les appareils du réseauLe plus large (adresses locales masquées par mDNS)
default_public_and_private_interfacesUtilisez uniquement les appareils sur l'itinéraire par défaut, utilisez des adresses publiques et privéesN'expose pas les adresses d'autres appareils
default_public_interface_onlyUtilisez uniquement les adresses publiques de la route par défautLes adresses privées ne sont pas exposées
désactiver_non_proxied_udpPas d'UDP via proxy, utilisez TCP via proxy si le proxy ne prend pas en charge UDPNe pas exposer les adresses des routes en dehors du proxy
Procédure de vérification à l'aide d'un navigateur uniquement sans site spécifique
Procédure de vérification à l'aide d'un navigateur uniquement sans site spécifique

Solution : Comment vérifier et corriger par cause

La plupart des fuites ont l’une des huit causes suivantes : Ceci est généralement dû à des paramètres qui se chevauchent. Commencez par vérifier le numéro de cause indiqué dans le tableau de diagnostic, et chaque fois que vous en corrigez un, répétez l'étape 6 de l'image ci-dessus pour voir si le résultat a changé. Si vous modifiez plusieurs paramètres à la fois, vous ne saurez pas ce qui a fonctionné.

Cause 1 · Il n'y a pas de serveur DNS dans la configuration VPN ou l'appareil utilise un DNS différent.

vérifier Lorsque le VPN est activé, le test DNS affiche le routeur Wi-Fi ou le serveur DNS de l'opérateur. Vous disposez souvent d'un DNS manuel dans les paramètres Wi-Fi de votre appareil.

résoudre L'application StageVPN inclut un serveur DNS dans la configuration VPN et envoie des requêtes dans le tunnel. Rétablissez le DNS manuel sur automatique dans les paramètres réseau de votre appareil, puis déconnectez-vous et reconnectez-vous au VPN. Si le problème est toujours le même, vérifiez les causes 3 et 5.

Parce que 2 IPv6 sort du tunnel

vérifier IPv4 a été remplacé par l'adresse du serveur VPN, mais IPv6 reste identique à la valeur notée à l'étape 1. Si le VPN tunnelise uniquement IPv4, les requêtes et les communications IPv6 suivront la route d'origine.

résoudre L'application StageVPN est configurée pour envoyer également des communications IPv6 au tunnel (AllowedIPs 0.0.0.0/0, ::/0), il n'est donc généralement pas nécessaire de la désactiver. Si IPv6 apparaît toujours comme il se doit, vérifiez d’abord si une autre application VPN ou les paramètres de l’appareil modifient l’itinéraire. Certains sites de test ne prennent pas en charge IPv6, alors comparez sur plusieurs sites.

Cause 3 · Le système d'exploitation interroge simultanément le DNS de plusieurs périphériques réseau.

vérifier Surtout lors d'une connexion VPN sur un PC Windows, le test DNS affiche à la fois le DNS du VPN et celui de votre opérateur. Cela est dû à une fonctionnalité qui interroge simultanément tous les périphériques réseau, telle que la résolution intelligente de noms multi-hébergements de Windows.

résoudre Gardez votre système d'exploitation et votre logiciel VPN à jour et répétez les tests. Ce phénomène est principalement signalé avec les VPN à l'échelle de l'appareil sur PC, et ne se produit pas de la même manière sur l'application StageVPN sur smartphones et StageVPN pour Chrome sur Chrome en raison de structures différentes.

Cause 4 · Le DNS sécurisé (DoH) est spécifié séparément dans le navigateur ou l'appareil

vérifier Le test DNS montre les serveurs des fournisseurs DNS publics. Dans ce cas, il ne s’agit peut-être pas d’une fuite mais d’un réglage que vous avez vous-même précisé. Si vous disposez d'un VPN à l'échelle de l'appareil, cette requête passera également par le tunnel, mais elle sera reçue par le fournisseur spécifié plutôt que par le DNS dans votre configuration VPN.

résoudre Si tel est le paramètre souhaité, vous pouvez le laisser tel quel. Si vous souhaitez utiliser DNS pour votre configuration VPN, il modifiera automatiquement les paramètres DNS sécurisés de votre navigateur et de votre appareil. Il est important de ne pas présumer qu’il s’agit d’une fuite simplement en regardant le nom de l’entreprise.

Cause 5 · D'autres applications VPN, proxy et de sécurité sont également activées

vérifier Les fonctionnalités réseau d'autres applications VPN, extensions proxy, filtres publicitaires ou programmes de sécurité sont activées en même temps. Les paramètres de l'itinéraire s'écrasent les uns les autres, ce qui entraîne le transfert de certaines requêtes vers l'itinéraire d'origine.

résoudre Allumez-en un seul à la fois. Désactivez les autres applications et extensions, déconnectez et reconnectez StageVPN et répétez l'étape 6. Les paramètres de proxy de Chrome ne peuvent contrôler qu'une seule extension à la fois, donc si une autre extension utilise un proxy, StageVPN pour Chrome ne se connectera pas et vous dira pourquoi.

Cause 6 · Seul le proxy du navigateur est utilisé, mais une communication en dehors du navigateur est attendue

vérifier J'ai activé StageVPN pour Chrome, mais d'autres navigateurs, messageries PC et programmes de messagerie se connectent en utilisant l'adresse IP et le DNS d'origine. Ce n'est pas une fuite, c'est la gamme conçue. L'extension couvre uniquement la communication dans Chrome.

résoudre Si vous devez protéger des programmes en dehors de Chrome, utilisez un VPN qui s'applique à l'ensemble de l'appareil. Sur les smartphones, c'est exactement ce que fait l'application StageVPN. La différence de portée entre les deux méthodes est VPN de navigateur vs VPN d'applicationJe l'ai organisé en .

Cause 7 La politique WebRTC n'est pas appliquée

vérifier J'ai activé StageVPN pour Chrome et je peux voir l'adresse IP publique d'origine dans le test WebRTC ou dans le candidat srflx dans chrome://webrtc-internals. Si une autre politique de gestion d'extension ou d'entreprise/organisation contrôle en premier les paramètres WebRTC, StageVPN pour Chrome ne modifiera pas la politique et la laissera telle quelle.

résoudre Désactivez toutes les autres extensions qui contrôlent les paramètres WebRTC et reconnectez StageVPN pour Chrome. Si la politique de gestion en est la cause, contactez votre administrateur. Pour écrire dans une fenêtre de navigation privée, vous devez activer « Autoriser en mode navigation privée » dans l'écran de gestion des extensions. Lorsqu'elle est désactivée, les communications dans les fenêtres de navigation privée ne passent pas par le proxy.

Cause 8 · Au moment où la connexion VPN est perdue

vérifier L'adresse IP d'origine n'est visible qu'immédiatement après avoir changé de réseau ou quitté le mode veille, et après un certain temps, c'est normal. Pendant la déconnexion, toutes les requêtes et communications empruntent la voie normale.

résoudre Avant d'effectuer tout travail sensible, vérifiez si l'indicateur d'achèvement de connexion de l'application ou l'icône d'extension est allumée. WireGuard, utilisé par l'application StageVPN, ne rétablit pas de tunnel même lors du passage du Wi-Fi au LTE, mais le protocole ne peut pas compenser les déconnexions temporaires du réseau lui-même. La possibilité de bloquer automatiquement les communications lorsque le VPN est déconnecté n'est pas une fonctionnalité fournie par StageVPN. Le principe est Expliquer les principes de WireGuardC'est dans

Comment les applications StageVPN et StageVPN pour Chrome stoppent-elles les fuites ?

L'application StageVPN réduit les fuites en tunnelant toutes les communications, tandis que StageVPN pour Chrome recherche des noms de proxy et ajuste les politiques WebRTC. Puisque l’étendue de la protection est différente, la manière dont elle est gérée est également différente.

Tableau 5. Traitement DNS/WebRTC de l'application StageVPN et StageVPN pour Chrome (en septembre 2026)
articleApplication StageVPN (iPhone·iPad·Android)StageVPN pour Chrome
plage de protectionTous les appareilsNavigateur Chrome
Communications envoyées via la route VPNIPv4·IPv6 Tous (IP autorisées 0.0.0.0/0, ::/0)Les requêtes Web passent par proxy (hors bandes IP privées et localhost)
Requêtes DNSTransférer dans le tunnel vers le serveur DNS spécifié dans la configuration VPN.Les requêtes qui transitent par un proxy ne sont pas recherchées par Chrome, mais par le serveur proxy.
WebRTCToutes les communications UDP passent par le tunnel.Disable_non_proxied_udp est appliqué lors de la connexion et revient au paramètre d'origine une fois déconnecté.
Ce que vous voyez actuellement sur le réseauLe fait qu'il y ait une communication cryptée avec le serveur VPN et la quantité de donnéesRecherche de noms d'adresses de serveur proxy, de connexions chiffrées avec le proxy et de communications à partir d'applications extérieures à Chrome
Cas qui peuvent ne pas s'appliquerPendant que la connexion VPN est perdue, lorsqu'une autre application VPN redirigeFenêtre de navigation privée avec Autoriser le mode navigation privée désactivé lorsqu'une autre extension ou une autre stratégie de gestion contrôle les paramètres proxy/WebRTC
Historique d'accès (93 jours)Les domaines consultés ne sont pas enregistrésLe nom d'hôte de destination connecté est enregistré, mais le chemin ou le terme de recherche n'est pas enregistré.

StageVPN ne vous guide pas à travers un menu distinct de paramètres de protection contre les fuites DNS dans le cadre de ses offres. Le comportement ci-dessus dépend de la configuration VPN par défaut de l'application et de la méthode de connexion de l'extension. Le champ d'application de la prestation est Caractéristiques et étendue de l'offreVous pouvez le vérifier ici.

Aucune fuite signifie que les requêtes et les communications passent par le chemin VPN plutôt que par l'opérateur. Cela ne signifie pas qu’aucun enregistrement ne sera conservé. StageVPN conserve les enregistrements d'accès pendant 93 jours conformément à la loi sur la protection des secrets des communications et n'enregistre pas le contenu des communications. L'article est Accéder à l’avis de stockage des dossiersEh bien, la raison pour laquelle je le révèle est Pourquoi divulguons-nous notre politique de conservation des enregistrements d’accès ?expliqué.

Comment les applications et les extensions préviennent les fuites
Comment les applications et les extensions préviennent les fuites

Liste de contrôle de revérification : que vérifiez-vous à nouveau après avoir apporté des modifications ?

Chaque fois que vous corrigez une cause, vérifiez à nouveau les éléments ci-dessous depuis le début. Si tout se passe bien, il n'y a pas de fuite. Si un élément échoue, il retourne sur la carte de cause correspondante.

  • Après avoir déconnecté et reconnecté le VPN, j'ai vérifié si l'application indiquait que la connexion était terminée ou si l'icône d'extension était activée.
  • Sur la page de vérification IP, soit vous verrez l'adresse du serveur VPN pour IPv4 et IPv6, soit vous ne verrez pas IPv6.
  • Le test DNS n'affiche pas le serveur DNS de l'entreprise de télécommunication ou du routeur.
  • Le candidat srflx dans chrome://webrtc-internals n'a pas l'adresse IP publique d'origine.
  • Les fonctionnalités réseau des autres applications VPN, proxys/extensions VPN et programmes de sécurité sont désactivées.
  • Si vous avez défini un DNS manuel ou un DNS sécurisé pour votre appareil et votre navigateur, vous avez vérifié qu'il s'agit du paramètre prévu.
  • Votre système d'exploitation, votre navigateur ainsi que les applications et extensions StageVPN sont à jour.
  • Même résultat même après avoir basculé entre le Wi-Fi et les données mobiles et redémarré le navigateur.
  • Si vous devez protéger des programmes en dehors de Chrome, vous pouvez utiliser un VPN à l'échelle de l'appareil plutôt qu'une extension.

C'est également une bonne idée de déterminer quand une nouvelle inspection est nécessaire. C'est après une mise à jour majeure de votre système d'exploitation ou de votre navigateur, après l'installation d'une nouvelle extension ou application de sécurité, ou avant d'effectuer tout travail sensible sur un réseau auquel vous vous connectez pour la première fois. Si les paramètres sont les mêmes mais que les résultats ont changé, l’une de ces trois choses en est généralement la cause. Une fois pris en main, les 6 étapes du diagnostic peuvent être réalisées en quelques minutes seulement.

Si le problème persiste, organisez le modèle de l'appareil, la version du système d'exploitation et de l'application, l'heure de son apparition et les résultats des tests. support clientVeuillez nous contacter. Veuillez ne pas envoyer votre mot de passe ou votre code de vérification. Les paramètres de l'appareil à vérifier ainsi que la recherche de fuites sont : 10 paramètres de confidentialité du smartphoneEh bien, il existe des risques qui ne peuvent être résolus avec un seul VPN. Ce que les VPN empêchent et ne peuvent pas empêcherEh bien, vos habitudes sur les réseaux publics sont Règles de sécurité du Wi-Fi publicJe l'ai organisé en .

matériel de référence

  1. RFC 1034 : Noms de domaine — Concepts et fonctionnalités — Structure du DNS et rôle des résolveurs (IETF)
  2. RFC 8484 : requêtes DNS sur HTTPS (DoH) — Comment chiffrer les requêtes DNS sur HTTPS (IETF)
  3. RFC 7858 : DNS sur TLS — Comment chiffrer les requêtes DNS avec TLS (IETF)
  4. RFC 8445 : Établissement de connectivité interactive (ICE) — Types de candidats à la connexion WebRTC et procédures de collecte (IETF)
  5. RFC 8828 : Exigences de gestion des adresses IP WebRTC — Plage d'adresses que les navigateurs exposent à WebRTC (IETF)
  6. API chrome.privacy — Valeurs de la politique de gestion IP Chrome WebRTC (Chrome pour les développeurs)
  7. API chrome.proxy — Paramètres de proxy d'extension, liste de contournement et priorités de contrôle (Chrome pour les développeurs)
  8. API WebRTC — RTCPeerConnection et le concept de candidats ICE (MDN Web Docs)
  • Fuite #DNS
  • Fuite #WebRTC
  • Fuite #DNS
  • #Test de fuite IP
  • Paramètres #VPN