Ce qu’une liste de candidats WebRTC révèle de votre VPN
Un candidat hôte, réflexif côté serveur ou relais indique d’où vient une adresse. Seule la paire ICE sélectionnée indique quel chemin les médias ont réellement emprunté.
Quand une page de test WebRTC affiche 172.20.4.15, elle a appris qu’une interface locale existe sur ce réseau. C’est une divulgation réelle, et ce n’est pas le même constat que « les médias sont sortis par la sortie du VPN ». La découverte de candidats et le routage des paquets sont des mécanismes distincts, et la plupart des rapports de fuite les fusionnent en un seul verdict. Lequel des deux vous regardez décide de la correction.
La collecte a lieu avant que quoi que ce soit soit envoyé
Le navigateur énumère les interfaces locales, envoie une demande de liaison à un serveur STUN et demande une allocation à un serveur TURN, puis écrit les résultats dans la description de session sous forme de lignes de candidats. Tout cela s’achève sans appel, sans média et sans interlocuteur. Une liste de candidats est donc un relevé de découverte, non de transport.
Les navigateurs modernes peuvent remplacer l’adresse littérale d’un candidat hôte par un nom mDNS .local, si bien que la page ne peut pas lire l’IP privée. Le réseau local voit toujours les requêtes multicast qui résolvent ce nom : l’adresse est donc cachée à l’application plutôt que retirée du réseau.
L’ordre compte aussi : un nouveau chargement de page collecte un nouvel ensemble, avec une autre allocation TURN et peut-être une autre correspondance réflexive. Deux exécutions qui divergent ne sont pas forcément deux configurations différentes.
Trois types de candidats, trois sortes de preuves
Chaque ligne provient d’une observation différente. Chaque type répond à une question différente, et le tableau les sépare selon ce qu’ils peuvent établir ou non.
| Candidate | Derived from | What it establishes | What it cannot establish |
|---|---|---|---|
| Host | An interface on the device | A local address exists in that network | That the peer can reach it |
| Server-reflexive | A STUN binding response | How a NAT mapped this source | Which exit the media will use |
| Peer-reflexive | A connectivity check that arrived | An address seen by the far side | That it was ever advertised |
| Relay | A TURN allocation | The relay server accepted the session | That the relay carries the call |
Un candidat relais est régulièrement confondu avec l’adresse internet de l’utilisateur. Il appartient au serveur TURN, et sa présence montre qu’un relais était disponible, non que le navigateur l’a choisi. La même confusion joue en sens inverse pour les candidats hôtes, où un nom mDNS cache l’adresse à la page alors que le réseau transporte toujours les requêtes. Lisez le type avant de lire la valeur.
La paire sélectionnée répond à la question du routage
ICE associe chaque candidat local à chaque candidat distant, exécute des vérifications de connectivité sur chaque paire et nomme un gagnant. Cette paire nommée, visible dans les diagnostics du navigateur lui-même, transporte les médias. Tout le reste de la liste est une possibilité qui a perdu.
Le gagnant vous donne la forme du chemin. Relais à relais passe par le serveur TURN, une paire hôte reste sur le réseau local, et une paire réflexive côté serveur passe directement par NAT. C’est le fait dont un contrôle VPN a besoin, et c’est un fait différent de la liste d’adresses. Deux appels avec des listes de candidats identiques peuvent emprunter des paires différentes.
Les candidats non sélectionnés ont tout de même été collectés, et la collecte est du trafic réseau qui quitte la machine. Un appel qui a finalement utilisé le relais ne signifie pas que rien n’a été divulgué pendant la construction de la liste.
Les contrôles répondent à des objectifs, pas à un score de fuite
La spécification WebRTC de gestion des IP décrit plusieurs politiques : n’utiliser que l’interface qui porte la route par défaut, utiliser toutes les interfaces, et désactiver l’UDP non proxifié pour que le trafic doive passer par un relais ou un proxy. Chacune échange connectivité et latence contre un type d’exposition différent. Celle qu’un navigateur implémente, et sous quel nom, varie selon la plateforme et la version.
Choisissez la politique en fonction de l’objectif. Cacher les adresses locales à une page est un objectif ; empêcher le trafic direct entre pairs en est un autre ; garder chaque paquet dans le tunnel en est un troisième. Le premier concerne surtout ce que l’application apprend, le deuxième quel chemin est autorisé, et le troisième doit aussi être appliqué à la limite de la plateforme ou du VPN.
Quel que soit le contrôle choisi, vérifiez les deux moitiés : lancez le test de collecte et notez les types de candidats, puis inspectez la paire sélectionnée pendant une session réelle. Une liste d’adresses propre avec un chemin média direct reste un chemin que vous ne vouliez pas.