Ce qu’un nom d’hôte VPN public peut prouver et ce qu’il ne peut pas

Les noms d’hôte et les drapeaux de pays ressemblent à des faits sur un serveur, et ni l’un ni l’autre n’en est un. Un nom renvoie à des adresses qui peuvent changer, et les mots qu’il contient ont été choisis par celui qui l’a enregistré. Le protocole, l’emplacement de sortie et le comportement de journalisation ont chacun besoin de leurs propres preuves. Commencez par ce à quoi le nom résout réellement, puis décidez ce qui reste inconnu.

Le nom résout, et rien d’autre n’est réglé

Un nom d’hôte est un pointeur dans le DNS, et les enregistrements derrière lui peuvent varier selon le résolveur, selon l’heure de la journée et selon la famille d’adresses que le client préfère. Deux personnes qui lisent la même entrée d’annuaire peuvent légitimement atteindre des machines différentes. Le nom vous dit quoi demander, pas ce qui répondra.

Les résultats de recherche changent aussi sans préavis, ce qui compte quand un profil fixe une adresse plutôt que le nom. Un profil qui code en dur l’ancienne adresse continue d’échouer après que l’opérateur a déplacé le service, et l’échec ressemble à un port bloqué. Gardez les adresses résolues à côté du profil pour qu’une comparaison ultérieure ait une base. Rien de tout cela ne dit qui exploite l’autre extrémité.

dig +short vpn.example.net A
dig +short vpn.example.net AAAA
dig +short vpn.example.net A @1.1.1.1

Transport et identité sont des questions distinctes

Une page web ouverte au nom d’hôte teste un seul écouteur sur un seul port. OpenVPN, IPsec et SSTP écoutent ailleurs, sur leurs propres ports et protocoles, donc un serveur web joignable ne dit rien d’eux.

L’entrée d’annuaire et le profil doivent s’accorder sur le transport, le port et les identifiants. L’identité est vérifiée par la chaîne de certificats ou l’empreinte de la clé du pair avec laquelle le client a été configuré, pas par l’orthographe du nom d’hôte. Un nom contenant un mot de projet familier prouve seulement que quelqu’un l’a enregistré. Lisez le certificat que présente le service et comparez l’émetteur et le sujet avec ce que le profil attend.

openssl s_client -connect vpn.example.net:443 -servername vpn.example.net </dev/null 2>/dev/null |
  openssl x509 -noout -subject -issuer -dates

Les mots de pays ne sont pas un audit de localisation

Une étiquette jp ou de dans un annuaire est un enregistrement, et les bases de géolocalisation IP divergent assez souvent pour qu’aucune ne mérite d’être traitée comme une vérité absolue. L’hébergement mutualisé, l’anycast et une simple mauvaise configuration déplacent tous l’emplacement observé loin de l’étiquette.

Le test pratique est le chemin propre de l’application : quelle adresse elle atteint, et ce qu’un contrôle d’adresse de sortie montre depuis l’intérieur de la session. Une adresse de sortie observée est une propriété de la route à cet instant, pas une garantie attachée au nom. Les annuaires de bénévoles ajoutent une couche de plus, car la personne qui a enregistré une fiche n’est pas forcément celle qui exploite la machine. Notez ce que vous avez mesuré et quand, plutôt que ce que la fiche promettait.

Vérifiez le service proposé, puis l’opérateur

Une fois le transport et l’identité réglés, la question restante est le comportement de l’opérateur, et cela exige des preuves documentaires plutôt qu’une déduction. Une politique de confidentialité, un contact publié et un avis de transparence sont des preuves d’intention ; aucun ne prouve la pratique, et l’absence des trois est aussi une information.

Pour un nœud public ou exploité par des bénévoles, partez du principe que la sortie est partagée et que celui qui l’exploite peut voir ce qui y passe. Cette hypothèse, et non le nom d’hôte, doit décider de ce que vous envoyez dans le tunnel.

curl -sSI https://vpn.example.net/ | head -n 5
whois 203.0.113.25 | grep -i -E 'orgname|netname'

Gardez le nom pour ce à quoi il est bon : trouver un point de terminaison et s’y connecter. Tout le reste doit être testé séparément, le jour où cela compte.