Port VPN redirigé : ce que les visiteurs et le fournisseur peuvent voir

Rediriger un port donne à des inconnus une route vers un service via l'adresse publique du fournisseur. Ce seul changement touche à la fois l'exposition et la reconnaissance, et aucun des deux ne publie le nom de qui exploite le service. Garder les deux séparés évite les erreurs opposées de traiter la redirection comme de l’anonymat et de la traiter comme une identification. Trois questions les séparent nettement, et les réponses viennent de preuves différentes.

Trois objets, trois questions différentes

Gardez l’adresse publique séparée de l’application qui répond derrière elle, et gardez les deux séparées de la personne ou de l’organisation qui exploite la chose. Chacune a son public et ses preuves. Les mélanger produit des conclusions qui sonnent bien et sont fausses.

Parcourez-les dans cet ordre. La première est une question de joignabilité, la deuxième une question d’identité de l’application, et la troisième une question d’attribution que les deux premières n’éclairent qu’en partie. Quand quelqu’un demande si la redirection de port est privée, demandez laquelle des trois il veut dire. Les réponses diffèrent vraiment, et une page de politique n’en traite généralement qu’une.

Ce qu’un visiteur peut relier entre points de terminaison

Un visiteur se connecte au point de terminaison et voit ce que l'application présente légitimement : un nom d’hôte, un nom de certificat, une page de connexion, du contenu publié. Ces détails identifient le service même lorsque son adresse d’accès habituelle est cachée derrière le tunnel. Deux points de terminaison qui présentent le même site nommé donnent aux observateurs une base pour les relier. Rien dans ce comportement n’est une fuite, puisque l’application a été conçue pour être vue.

La correspondance des certificats, des redirections et du contenu des pages entre deux points de terminaison est un signal fort qu’ils appartiennent à un même service. Cela reste une affirmation sur le service, non sur une personne, jusqu’à ce qu’un autre enregistrement relie les deux.

Les recommandations de l’IETF sur la vie privée décrivent comment les identifiants persistants permettent de corréler des interactions dans le temps. La corrélation n’est pas une attribution, car plusieurs personnes peuvent administrer un même service et une adresse peut passer entre des abonnés sans lien. C’est cette distinction qui empêche une constatation de corrélation de devenir une accusation.

Ce que le fournisseur de redirection doit savoir

Pour livrer une connexion entrante, le système du fournisseur doit détenir la relation active entre le point d’entrée public et la destination interne. Ce fait opérationnel diffère de ce que voit un visiteur, et diffère encore de ce que le fournisseur choisit de conserver. Gardez les deux questions séparées quand vous lisez une page de politique, car l’une est inévitable et l’autre est une décision. Une déclaration selon laquelle aucun 'historique de navigation' n’est conservé ne dit rien de l'historique des correspondances.

La persistance des correspondances historiques, des associations de compte ou des enregistrements de connexion est une question qui relève de la politique et de la mise en œuvre réelles du fournisseur. La redirection ne prouve pas que chaque catégorie est journalisée. Demandez précisément quels champs subsistent après le retrait de la correspondance, et pendant combien de temps.

La joignabilité entrante est aussi distincte du routage sortant du client, du DNS et du comportement en cas de défaillance. Ajouter une correspondance ne décrit pas comment sort le reste du trafic du client.

La durée de la correspondance change l’exposition

Une correspondance peut persister le temps d’une session, d’une réservation ou selon une politique du fournisseur qui la modifie. Il ne faut présumer ni l’attribution permanente ni la rotation constante ; lisez le comportement documenté du produit et notez ce que vous observez. Deux observations séparées d’une semaine disent plus sur la 'rotation' que n’importe quelle phrase marketing de la page produit. Inscrivez l’intervalle observé à côté du point de terminaison dans vos notes, car l’intervalle fait partie de l’exposition.

La durée de vie change la corrélation possible. Un point de terminaison stable invite à un suivi de longue durée d’un seul service, tandis qu’un point rotatif rend chaque observation plus difficile à joindre à la précédente. Aucune des deux propriétés n’est une garantie sur les enregistrements du fournisseur, et aucune ne remplace la décision sur ce que le service lui-même publie.

Publiez délibérément, puis fermez les deux portes

Confirmez que le fournisseur autorise le protocole dont vous avez besoin, que l’écouteur cible est bien celui que vous vouliez, et que les contrôles de l’hôte et de l’application limitent encore l’accès. Avant de publier, regardez ce que le service présentera à un inconnu. Ces deux commandes montrent le certificat et les en-têtes qu’un visiteur reçoit.

openssl s_client -connect pub.example.net:443 -brief < /dev/null
curl -sSI https://pub.example.net/

Publier quelque chose ne justifie pas d’exposer ses pages d’administration ni d’abandonner la connexion de l’application, et la traduction n’apporte pas TLS à un service qui n’en a jamais eu. Maintenez le protocole chiffré et ses contrôles d’identité du serveur en place, quelle que soit la manière dont le trafic arrive. Vérifiez ensuite les en-têtes de réponse, car une bannière ou une page de débogage peut dire à un inconnu plus que le service n’en a l’intention. Ce que renvoient les deux commandes est la même vue qu’obtient un observateur.

Retirer le service signifie deux fermetures, pas une : retirez la correspondance par son propriétaire, puis traitez l’écouteur et le droit comme des éléments distincts. Un point de terminaison mis en favori qui cesse de répondre ne révoque pas un identifiant et ne récupère pas d’informations déjà livrées.