Ce que révèle une réponse STUN quand le VPN tourne sur le routeur

Quand le tunnel vit sur le routeur, la machine qui fait tourner le navigateur n’a aucune interface de tunnel. Demandez à cette machine ses adresses locales et vous obtenez une adresse privée de LAN et une adresse de bouclage, rien qui ressemble à une adresse VPN. Pourtant, un serveur STUN de l’autre côté peut encore rapporter quelque chose de significatif sur le chemin, et ce qu’il rapporte dépend entièrement de la façon dont cette requête précise a été routée et traduite.

C’est la partie qui mérite qu’on ralentisse. « Le navigateur ne possède pas l’adresse VPN » répond à une question sur les interfaces, alors qu’une adresse réfléchie est une réponse sur un chemin à travers la traduction. Confondre les deux produit des conclusions assurées sur la divulgation que les preuves ne soutiennent pas.

Deux appareils, deux jeux d’interfaces

Dans une installation reposant sur un routeur, le tunnel se termine sur le routeur et le client du LAN envoie le trafic ordinaire vers sa passerelle par défaut. La liste d’interfaces du client reste courte : une adresse privée, peut-être une seconde pour un autre réseau, et le bouclage. Le risque n’est pas que l’une d’elles soit justement l’adresse du tunnel ; il est que la requête sorte par un chemin que vous n’avez pas choisi.

Demandez au client quel chemin prendrait une destination précise au lieu de demander quelles interfaces existent. La réponse nomme une passerelle et l’adresse source que le noyau utiliserait, ce qui est déjà plus instructif que n’importe quel inventaire d’adresses.

ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ips

Les plages de documentation sont de bonnes destinations de test parce qu’elles ne se résolvent jamais vers un service réel. Comparez ce que dit le client avec ce que dit le routeur, et traitez tout désaccord comme la preuve que le routage par politique, une règle de tunnel divisé ou une seconde route par défaut fait quelque chose que vous n’avez pas pris en compte.

Ce qu’une réponse Binding est autorisée à dire

RFC 8489 définit la requête et la réponse Binding, où le serveur rapporte l’adresse de transport source qu’il a observée pour cette requête. C’est une affirmation sur un quintuplet à un instant donné, pas un recensement des interfaces du client. Tout l’intéressant se passe donc entre le client et le point d’observation.

Cet écart est comblé par le routage et la traduction. Un routeur qui fait du NAT source sur le trafic sortant remplace la source privée du client par sa propre adresse sur l’interface de sortie. Si cette interface est le tunnel, le réflecteur voit l’adresse du tunnel. Si le paquet a été exclu du tunnel, le réflecteur voit ce que la traduction WAN a produit. Même client, même réflecteur, réponse différente.

Trois cas qui se ressemblent et ne le sont pas

La distinction utile n’est pas public contre privé, mais quel point d’application a traité le paquet. Travaillez les cas avec les tables du routeur ouvertes, car un seul navigateur peut produire les trois selon une règle que vous avez oublié avoir écrite.

Seul le deuxième cas enfreint l’exigence que certain trafic ne sorte jamais directement, et seuls le premier et le troisième divulguent un identifiant côté tunnel. Aucune des trois lignes n’est une affirmation sur le comportement d’un fournisseur précis : la possibilité d’atteindre un réflecteur privé dépend du routage, des adresses IP autorisées de l’autre extrémité et de la politique du pare-feu aux deux bouts.

Détenir un compte chez le même fournisseur n’établit rien de tout cela. Il vaut aussi la peine de se rappeler qu’une requête routée peut conserver la source LAN du client si rien ne la traduit, donc le champ source doit être tracé plutôt que supposé à partir du schéma de topologie.

Collecter n’est pas sélectionner

WebRTC collecte des adresses candidates à essayer, et un candidat qui apparaît dans une liste de diagnostic peut n’avoir jamais transporté de média. Lire la liste comme « voilà ce que l’autre extrémité a appris » surestime la preuve. La paire sélectionnée est celle qui a réellement porté la session, et elle vit dans un autre champ.

Un vérificateur de sortie HTTPS répond à une autre question : l’adresse source qu’un serveur web a vue pour cette requête. C’est un recoupement utile précisément parce qu’il utilise un protocole différent et souvent une destination différente d’un réflecteur UDP, et un désaccord entre les deux pointe généralement vers une règle de routage plutôt que vers un défaut.

Décidez la politique, puis lisez la réponse

Écrivez l’intention avant de tester : quel trafic doit utiliser le tunnel, lequel peut sortir directement, quelles familles d’adresses sont concernées et ce qui doit se passer quand le tunnel est coupé. Sans cette base, chaque observation est ambiguë, car vous ne pouvez pas séparer une fuite d’un chemin que vous avez délibérément autorisé.

Posez ensuite une question à la fois. Quel chemin prend cette destination. Quelle adresse ce réflecteur rapporte. Quelle paire candidate la session a-t-elle choisie. Gardez les réponses à côté de la politique et datez-les, car une mise à jour de firmware peut changer le comportement par défaut d’une manière qui invalide silencieusement la conclusion de l’an dernier.

Le routeur reste un point d’application solide, car il voit un trafic qu’un client ne peut pas contourner sans se reconfigurer lui-même. Ce n’est pas la promesse que chaque champ de chaque protocole applicatif ne révèle rien, et ce n’est pas un substitut à l’écriture des chemins que vous avez choisi d’autoriser.