Quel VPN choisir si mon extension de navigateur fuit WebRTC ? J’ai arrêté de réparer l’extension et déplacé la protection sous le navigateur

Quel VPN choisir si mon extension de navigateur fuit WebRTC ? J’ai arrêté de réparer l’extension et déplacé la protection sous le navigateur

Le test d’adresse IP disait que j’étais aux Pays-Bas.
Parfait.
L’extension VPN était verte.
Amsterdam.
Connecté.

J’ai alors ouvert un test WebRTC presque par curiosité.
Une deuxième adresse est apparue.
La mienne.
Pas celle du serveur VPN.
Mon adresse publique habituelle.

J’ai rechargé la page.
Même résultat.
J’ai changé de serveur.
Amsterdam est devenue Francfort.
Le test IP classique voyait bien l’Allemagne.

WebRTC, lui, continuait à retrouver mon autre adresse.
À ce moment-là, ma question n’était plus vraiment :
« Quelle extension VPN est la meilleure ? »
Elle était devenue beaucoup plus précise :

si mon navigateur possède encore un chemin capable de révéler mon adresse réelle, est-ce que je veux vraiment résoudre le problème en ajoutant encore un réglage dans ce même navigateur ?

Le piège, c’est que tout avait l’air de fonctionner

C’est ce qui rend une fuite WebRTC agaçante.
Ma navigation ordinaire passait bien par l’extension.
Les sites classiques voyaient l’adresse du serveur VPN.
Je pouvais changer de pays.
Rien ne ressemblait à une panne.

Puis WebRTC posait une autre question au réseau.

Pour établir certaines communications en temps réel, WebRTC utilise notamment ICE et STUN afin de découvrir les chemins disponibles et l’adresse publique utilisable pour la connexion.

La conséquence pratique tient en une phrase :

un navigateur peut afficher l’IP du VPN pendant la navigation ordinaire tout en révélant autre chose au moment d’une négociation WebRTC.

C’était exactement ce que mon test venait de montrer.

Je suis donc allé chercher le correctif le plus évident.

Mon grand fournisseur avait déjà prévu un bouton pour ça

J’utilisais l’extension NordVPN.

Le choix était tout à fait logique.

L’extension fait passer le trafic du navigateur par son infrastructure, permet de changer d’adresse IP et inclut une protection contre les fuites WebRTC.

J’ai ouvert les paramètres.
« Block WebRTC ».
Activé.
C’était déjà activé.
Je l’ai désactivé.

Réactivé.
Fermé le navigateur.
Rouvert.
Test.
Toujours mon adresse réelle.

C’est là que le problème a cessé d’être « mon VPN ne fonctionne pas ».

Il est devenu :

« qu’est-ce qui, dans Chrome, décide réellement de la manière dont WebRTC sort sur le réseau ? »

Une extension peut avoir le bon réglage sans être seule à le contrôler

Chrome permet aux extensions d’agir sur une politique dédiée à la gestion des adresses IP WebRTC.

C’est précisément le type de mécanisme qu’utilise une protection contre les fuites.

Mais un autre détail comptait davantage pour mon cas : plusieurs extensions ou politiques du navigateur peuvent intervenir sur le même réglage.

J’ai regardé ma barre d’extensions.
Bloqueur de publicité.
Extension de confidentialité.
Gestionnaire de cookies.
VPN.

J’avais empilé plusieurs couches censées améliorer ma vie privée.

Elles étaient maintenant en train de rendre beaucoup moins évident qui contrôlait quoi.

J’ai désactivé l’autre extension de confidentialité.
Relancé Chrome.
Refait le test.
Cette fois, mon adresse réelle avait disparu.
Le correctif fonctionnait.

Et, paradoxalement, c’est à ce moment-là que j’ai eu envie de changer de méthode.

J’avais réparé la fuite, mais créé une configuration à surveiller

Techniquement, je pouvais m’arrêter là.
L’extension VPN fonctionnait.
Le blocage WebRTC aussi.

Mais ma protection dépendait désormais d’une petite chaîne mentale :

extension VPN installée ;
blocage WebRTC activé ;
aucune autre extension ne reprend le même réglage ;
configuration du navigateur inchangée ;
test à refaire après une modification.

Ce genre de friction apparaît aussi dans les expériences publiques : un utilisateur a décrit une adresse réelle visible via WebRTC jusqu’à ce que la protection correspondante soit correctement activée.

C’était suffisant pour confirmer mon problème pratique.

Je ne cherchais plus un meilleur bouton WebRTC.

Je voulais savoir si je pouvais enlever ce bouton de l’équation.

J’ai donc retiré l’extension VPN

Pas simplement déconnectée.
Désactivée.
Chrome est redevenu un navigateur ordinaire.
Puis j’ai ouvert OnlydogVPN^↗ comme application.
Connecter.

Premier test : adresse IP classique.
Adresse de la VPN.
Deuxième test : WebRTC.
J’ai attendu.
Mon adresse publique habituelle n’est pas apparue.

J’ai ouvert un autre test.
Même résultat.
Puis j’ai lancé une page utilisant réellement WebRTC.
La fonction continuait de fonctionner.
Je n’avais pas désactivé WebRTC.

Je n’avais pas installé un deuxième correctif pour protéger le premier.

Je n’avais pas modifié Chrome.

Surtout, je n’avais plus besoin de maintenir deux raisonnements différents :

« le trafic web passe par l’extension »

et

« maintenant il faut empêcher WebRTC de sortir autrement ».

Le navigateur utilisait simplement une connexion déjà placée derrière la VPN.

Et c’est là que mon critère de choix a changé.

Je ne voulais plus protéger chaque sortie du navigateur séparément

Avant ce test, je comparais des extensions par fonctions.
Blocage WebRTC.
Changement rapide de pays.
Split tunneling par site.
Protection contre les trackers.

Réglages supplémentaires de confidentialité.

Ces fonctions peuvent être très utiles, et l’extension NordVPN en propose plusieurs.

Mais une fuite WebRTC m’avait montré la faiblesse de mon raisonnement.

Je m’étais concentré sur tout ce que l’extension savait corriger dans Chrome.

La seconde configuration déplaçait simplement la protection plus bas.

Pour ce problème précis, c’était ce que je préférais :

protéger la connexion utilisée par le navigateur plutôt que demander au navigateur de protéger séparément chacun de ses chemins réseau.

Je pouvais enfin arrêter de comparer des interrupteurs.
Le résultat du test était plus simple :
VPN active.
WebRTC actif.
Adresse réelle absente.

Je n’ai pas désactivé WebRTC juste pour obtenir un résultat vert

Cela comptait pour moi.
J’utilise WebRTC.
Appels vidéo.
Audio dans le navigateur.
Outils collaboratifs.

Désactiver brutalement la fonction aurait pu faire disparaître la fuite tout en cassant quelque chose dont j’avais réellement besoin.

Je voulais conserver le navigateur normal et changer ce qu’il trouvait derrière lui.

C’est ce qui s’est produit avec la seconde configuration.

WebRTC continuait à fonctionner.

Mon adresse publique habituelle ne revenait plus dans les tests.

Je ne peux pas observer de l’extérieur toutes les règles internes de routage ou de filtrage appliquées par le navigateur et le service pendant chaque négociation WebRTC.

Mais le résultat que je cherchais était observable sans ambiguïté :

l’adresse que je voulais masquer n’apparaissait plus.

Après une heure passée à inspecter les réglages de Chrome, cette simplicité avait beaucoup de valeur.

Le bénéfice suivant est apparu sans ajouter une nouvelle extension

Une fois le problème WebRTC réglé, j’ai continué à naviguer pour vérifier quelques sites.

C’est là que j’ai remarqué le compteur de requêtes bloquées dans l’application.

Une partie des demandes liées au suivi et à la publicité était arrêtée.

Ce n’était pas ce qui avait supprimé la fuite WebRTC.

Mais cela résolvait une petite friction liée au même objectif : réduire ce que mon navigateur envoyait inutilement à l’extérieur.

Et surtout, je n’avais pas besoin d’ajouter une nouvelle extension à Chrome pour l’obtenir.

Après avoir découvert qu’une accumulation d’extensions pouvait compliquer le contrôle du réglage WebRTC, cette absence d’une couche supplémentaire m’a semblé particulièrement bienvenue.

Quand je garderais malgré tout l’extension NordVPN

Une extension de navigateur a une vraie force : elle est légère et ciblée.

Si je veux seulement modifier le trafic de Chrome et laisser le reste de l’ordinateur utiliser la connexion normale, c’est pratique.

NordVPN possède aussi une histoire publique, une infrastructure et une documentation beaucoup plus vastes que la petite application. Son outil de blocage WebRTC existe précisément pour éviter le type de fuite que j’avais rencontré.

Si je veux un contrôle fin à l’intérieur du navigateur, je vois très bien pourquoi je choisirais cette approche.

La petite application a également moins de localisations, moins d’avis indépendants et un historique public plus court.

Mais mon problème n’était plus le nombre de fonctions disponibles dans l’extension.

J’en avais déjà une très complète.

Mon problème était que la frontière de protection se trouvait à un endroit où plusieurs composants du navigateur pouvaient encore me forcer à réfléchir.

OnlydogVPN a déplacé cette frontière sous le navigateur.

Dans mon test, cela a suffi pour faire disparaître la fuite sans transformer Chrome en projet de configuration.

Maintenant, je teste toujours deux choses

Je ne me contente plus de chercher « mon IP » sur Google.
Je vérifie d’abord l’adresse vue par une page classique.
Puis je vérifie WebRTC.

Si les deux montrent uniquement la connexion attendue, je passe à autre chose.

Si le site classique voit le VPN mais que WebRTC retrouve mon adresse réelle, je ne commence plus par changer de serveur.

Je regarde où se trouve réellement la protection.

Est-ce une extension qui agit seulement dans le navigateur ?

Un autre module peut-il modifier le comportement WebRTC ?

Suis-je en train d’ajouter un correctif à un autre correctif ?

NordVPN m’a montré qu’une bonne extension pouvait résoudre la fuite en contrôlant correctement WebRTC.

La petite application m’a donné le résultat que j’ai finalement préféré : j’ai retiré cette bataille de réglages du navigateur, et mon adresse réelle a cessé d’apparaître dans le test.

Si une extension VPN fuit mon IP via WebRTC, je ne cherche donc plus d’abord une extension avec un meilleur bouton WebRTC — je préfère une VPN qui me donne moins de raisons d’ouvrir les paramètres du navigateur.