Quelle adresse source STUN voit-il avec un VPN sur routeur ?
Route, choix de la source et traduction déterminent l’adresse qu’un réflecteur signale. Trois faits à noter, puis une requête pour confirmer quel chemin l’emporte.
La question ressemble à une seule consultation et recouvre en réalité trois décisions. Quel chemin prend la binding request, quelle source le noyau choisit pour ce chemin et si quelque chose en route réécrit cette source. Changez l’une des trois et l’adresse qu’un serveur STUN signale change avec elle. C’est pourquoi dire que le VPN se trouve sur le routeur ne vous apprend presque rien en soi.
La décision repose sur trois faits
D’abord la route : les règles de politique et la table de routage décident si la requête sort par le tunnel ou par le WAN ordinaire, et une destination exclue emprunte le second chemin même lorsqu’un tunnel est actif. Ensuite la source : le noyau choisit une source pour la route retenue, et ce choix dépend de la source préférée de la route et de toute règle qui a correspondu. Enfin la traduction : NAT en chemin remplace la source choisie. L’adresse réfléchie est le produit des trois, pas une propriété du tunnel.
Changez l’un des trois et la réponse change alors que chaque composant paraît encore sain dans son propre journal. C’est la raison habituelle pour laquelle ce diagnostic s’enlise.
Notez les trois faits pour le flux que vous testez avant de commencer. Interface, route et règle de traduction suffisent à prédire le résultat, et c’est la prédiction qui rend une surprise instructive. Si vous ne pouvez pas remplir l’un des trois, cette lacune est le véritable constat.
Suivre une binding request le long du chemin
Une binding request STUN demande à un serveur de signaler l’adresse de transport source qu’il a observée. La réponse décrit le chemin emprunté par la requête, pas un inventaire des interfaces de la machine cliente. Deux requêtes sur deux chemins signaleront honnêtement deux adresses différentes.
| Path taken | Source the reflector sees | What it means |
|---|---|---|
| Tunnel to a public exit that translates | The exit's public address | The reflector learns nothing about the LAN |
| Tunnel to a private reflector, translated to the tunnel address, no later translation | That tunnel address | An internal identifier is disclosed to that reflector |
| Excluded flow over the ordinary WAN | The WAN address | The tunnel was not used at all |
Lisez ce tableau comme un ensemble de conditions, non comme un menu de fournisseurs. La ligne du milieu exige que le réflecteur privé soit joignable sous le routage et la politique de pairs propres au tunnel ; c’est un fait de configuration que vous pouvez vérifier, et non quelque chose qu’un niveau de compte implique. La ligne du bas est généralement celle qui compte pour la politique, car ce trafic était censé rester dans le tunnel. Entre les deux se trouve le cas ordinaire, où la sortie traduit et où le réflecteur ne voit que la sortie.
Les candidats hôte et les candidats réflexifs côté serveur viennent de mécanismes différents, donc une liste de candidats ne dit rien du chemin réellement utilisé par les médias. Lisez la paire sélectionnée, pas le journal de collecte, quand vous voulez savoir où la session est allée.
Ce que l’adresse tunnel du routeur n’est pas
Une adresse tunnel attribuée au routeur appartient à une interface du routeur. Un navigateur sur un hôte du LAN possède ses propres adresses d’interface et aucune vue directe de l’interface tunnel du routeur. Traiter les deux comme interchangeables produit des réponses fausses et assurées sur ce qu’une page web peut apprendre.
Le transfert est ce qui les relie. La requête traverse le routeur comme trafic routé, et sa source est ce que le routage et la traduction ont produit.
Si le chemin tunnel conserve la source LAN, un réflecteur privé peut apprendre cette adresse LAN, ce qui est une divulgation réelle et différente de l’adresse tunnel. Si le chemin traduit vers l’adresse tunnel, le réflecteur apprend l’adresse tunnel à la place. Les deux issues sont compatibles avec le même navigateur sur le même hôte, et c’est pourquoi une observation doit être rattachée à un flux précis. Demandez au noyau quelle source il utiliserait avant d’accuser l’application.
Divulgation contre contournement : deux constats, deux réparations
Une adresse tunnel réfléchie divulgue un identifiant interne sur un chemin que vous avez autorisé. Une requête directe par le WAN contourne un chemin que vous vouliez imposer. La première est une question d’information, la seconde une question d’application des règles, et elles se corrigent à des endroits différents. Les fondre en un seul mot produit une réparation qui ne traite ni l’une ni l’autre.
WebRTC rend cela plus visible sans le rendre faux, car collecter un candidat n’est pas la même chose que le sélectionner.
ip route get 203.0.113.7 from 192.0.2.25
ip rule showExécutez la requête de route pour chaque adresse de réflecteur que vous autorisez, avec la source que ce flux est censé porter, puis exécutez-la de nouveau pour les plages exclues afin de voir ce que le repli sélectionne. Comparez les deux réponses à la politique que vous avez notée. Lorsqu’elles diffèrent d’une manière que vous n’aviez pas prévue, vous avez trouvé le point de réparation sans même avoir à interpréter la liste de candidats d’un navigateur.