VPN ou relais TURN : qu’est-ce qui transporte vraiment un appel WebRTC ?
Un tunnel modifie le chemin que voit ICE ; il n’alloue jamais de relais et ne fournit pas de signalisation. Comparez ce qu’apportent une sortie VPN et un serveur TURN.
La page se charge par le VPN, l’appel ne se connecte jamais : deux défaillances différentes avec la même barre d’adresse. Le tunnel a changé le chemin qu’utilise le navigateur ; il n’est devenu ni un service de signalisation, ni un serveur STUN, ni un relais, et il ne décide pas quelle paire de candidats ICE choisira. C’est la séparation du rôle de chaque composant qui transforme un vague « WebRTC est bloqué » en une panne précise.
Quatre rôles, dont le tunnel n’en touche qu’un
L’application échange les informations de session par un dispositif de signalisation quelconque, et c’est le premier rôle. ICE rassemble des adresses candidates et teste des paires jusqu’à ce qu’une fonctionne, ce qui est le deuxième. STUN permet à un pair de savoir à quoi ressemble son trafic vu de l’extérieur, et TURN alloue un relais pour les cas où aucun chemin direct n’existe. Ces quatre rôles sont distincts, et un VPN influe sur les adresses et le filtrage qu’ils rencontrent plutôt que de fournir l’un d’eux.
Voilà pourquoi une connexion réussie ne dit rien du chemin des médias. La signalisation emprunte généralement le même HTTPS que la page utilise déjà, sur le port 443, tandis que les médias peuvent voyager en UDP vers une destination entièrement différente.
L’adressage privé aggrave la confusion. Une adresse de tunnel n’est utile à un pair que si ce pair dispose d’un chemin prévu vers elle ; être privée n’est pas une preuve de joignabilité mutuelle, et les navigateurs ne le traitent pas comme tel lorsqu’ils écartent des candidats invérifiables. Un candidat qui vous semble local peut être non testable depuis l’autre côté. Cette lacune mérite d’être écartée avant de conclure que le tunnel abandonne les médias.
Comparez une sortie VPN à un relais TURN
Les deux transmettent des paquets, d’où la confusion, et le tableau de comparaison ci-dessus mérite d’être lu colonne par colonne plutôt que comme une liste de fonctions. Une allocation de relais est un objet par session créé par une requête authentifiée ; un tunnel est une route. L’un a des identifiants qui expirent, l’autre a une adresse de pair qui est joignable ou ne l’est pas.
| Component | What it contributes | What it needs to work | What it cannot do |
|---|---|---|---|
| VPN exit | Changes the observed mapping and the route packets take | A working tunnel and a policy that permits the media transport | Allocate a relay or supply signaling |
| STUN server | Reports the mapped address a peer appears to use | Reachability from the client, on its configured transport | Carry media when a direct path fails |
| TURN server | Relays media through an authenticated allocation | Valid credentials, an allowed transport and sufficient capacity | Fix a missing ICE policy or an unauthorized client |
| Signaling channel | Carries offers, answers and candidate lists | Both peers reaching the same application endpoint | Establish connectivity by itself |
Les numéros de port rendent la différence concrète. TURN écoute par défaut sur 3478 pour UDP et TCP et sur 5349 pour TLS, et un réseau qui autorise 443 mais rejette ces ports fera échouer les appels relayés tandis que la navigation continue normalement. Changer le port du VPN ne configure rien de tout cela, car les ports qui comptent appartiennent au service de relais, pas au tunnel.
Lisez les diagnostics, puis testez l’appel
Les navigateurs exposent les informations nécessaires sans capture de paquets. Ouvrez la page de diagnostic WebRTC de votre navigateur, passez l’appel et lisez la paire de candidats sélectionnée plutôt que la liste collectée : quels types de candidats locaux et distants ont été choisis, sur quel transport et quelle famille d’adresses, et si le chemin est direct ou relayé.
Deux lectures méritent d’être connues d’avance. Si la paire sélectionnée est hôte à hôte sur des adresses privées, les médias restent sur un chemin sur lequel vous pouvez raisonner ; si elle est relais à relais, l’appel consomme de la capacité de relais et dépend de la disponibilité de ce service. Une défaillance qui s’arrête à « vérification » sans paire sélectionnée signifie que des candidats ont été collectés mais qu’aucun n’a passé les contrôles de connectivité.
Comparez ensuite les mêmes deux extrémités sur le même appel en ne changeant qu’une condition approuvée, et acceptez le résultat sur des médias ou des données bidirectionnels plutôt que sur un indicateur « connecté ». La collecte de candidats réussit dans bien des cas qui ne transportent pas une seule image audio. Répétez l’appel de l’autre côté du changement et conservez les deux captures de diagnostic, car comparer deux exécutions est plus instructif que d’en lire une seule. Mêmes extrémités, même codec, une variable modifiée.
Une application qui fixe délibérément sa politique de transport ICE sur relay ne demande que des candidats de relais. Ce réglage ne crée pas de relais et ne répare pas des identifiants manquants ; il rend l’exigence explicite, ce qui est utile quand quelqu’un accuse le VPN d’une politique choisie par le site.
Gardez l’affirmation de confidentialité aussi étroite que les preuves
L’exposition des candidats dépend de la politique du navigateur et de l’application, pas seulement de l’état du tunnel, et la spécification W3C de connexion entre pairs traite la gestion des IP comme une question propre. Un VPN connecté est donc une base faible pour promettre qu’un appel ne révèle qu’une adresse choisie. Deux pairs derrière le même tunnel peuvent même choisir un chemin qui ne quitte jamais l’hôte, ce qui est à la fois une amélioration de la confidentialité et une contrainte de connectivité.
Ce que vous pouvez affirmer avec précision est plus étroit et plus utile : quelle paire de candidats a été sélectionnée, quel transport l’a portée et si ce chemin est resté dans le tunnel. Notez ces trois faits pour un appel qui fonctionne et pour un qui échoue, et la différence nomme souvent le composant à corriger.
Une fois la connectivité établie, séparez la performance de la joignabilité. Perte, délai, files d’attente et MTU se situent tous en aval d’une paire de candidats correcte, et traiter un appel saccadé comme une panne de connectivité vous renvoie à la liste des candidats sans raison.