Service Onion ou service VPN : des modèles d'accès différents

On décrit un service Onion et un service accessible uniquement par VPN comme deux variantes d'une même idée : masquer le port, partager l'adresse secrète. Ils diffèrent par ce à quoi l'adresse est liée, qui peut l'atteindre et ce qui doit se passer avant qu'une requête n'arrive. L'un est un point de rendez-vous à l'intérieur de Tor ; l'autre est une route à l'intérieur d'un réseau privé. Les traiter comme interchangeables produit des conceptions qui ne sont ni privées ni maintenables.

Le mythe : les deux modèles ne sont qu'une porte cachée

La propriété commune est réelle mais mince : aucune des deux conceptions ne place l'interface d'administration sur un port public directement accessible. Tout le reste diverge. Une adresse Onion est dérivée de la clé propre du service, donc le nom est lié à une identité ; une adresse VPN n'est qu'une adresse dans un réseau auquel on vous a admis. L'une cache le service dans une couche superposée, l'autre vous admet dans une topologie privée. Traiter la seconde comme un synonyme de la première, c'est là que commence la confusion.

Aucune des deux propriétés n'est un contrôle de sécurité pour l'application elle-même. Un emplacement caché ne corrige pas le logiciel derrière lui, et une route privée n'ajoute pas d'authentification à la page de connexion. Les deux conceptions ont toujours besoin des permissions propres à l'application, et toutes deux ont toujours besoin de quelqu'un responsable des mises à jour et de la restauration.

Vers quoi pointe réellement une adresse Onion

Une adresse Onion de version v3 encode la clé publique du service, ce qui explique que personne ne puisse choisir une adresse pour un service qu'il ne contrôle pas. Le client se connecte via Tor à un point de rendez-vous, et le service atteint le même point de son côté ; aucun nœud de sortie ordinaire ne porte cette connexion jusqu'au service. Le nom est une identité, pas un enregistrement DNS.

dig +short example.onion
curl --socks5-hostname 127.0.0.1:9050 http://example.onion/
systemctl status tor

C'est pourquoi ajouter une route ou une entrée hosts pour un nom onion ne sert à rien. La résolution n'est pas le mécanisme ; le client Tor et ses circuits le sont. Si le service est destiné à un petit groupe de personnes, l'autorisation de client onion peut exiger une clé avant que la connexion soit acceptée, mais ce n'est toujours pas la connexion à l'application. Publier l'adresse est aussi un acte délibéré, puisque quiconque l'apprend peut tenter une connexion sauf si vous l'avez restreinte.

Arrêtez-vous si la seule raison du modèle onion est d'éviter de configurer l'authentification. La couche superposée ne l'offre pas, et vous la construirez de toute façon plus tard.

Ce qu'accorde réellement une route VPN

Un VPN admet un appareil dans un réseau et lui donne une route vers une passerelle ou un sous-réseau. Le service derrière cette passerelle voit une adresse issue du pool du tunnel et applique l'autorisation dont il dispose. La route ne dit rien sur l'identité de l'utilisateur ; elle dit où les paquets peuvent aller.

ip route get 10.20.30.40
wg show
curl -sv https://files.internal.example/ -o /dev/null

Ce modèle convient à un groupe connu avec des appareils gérés, car la passerelle peut imposer l'état de l'appareil et le réseau peut être audité. Il convient mal à des visiteurs anonymes ou ponctuels, qu'il faudrait d'abord enrôler. La connexion propre à l'application décide toujours de ce qu'un utilisateur connecté peut lire. Confondre portée et permission, c'est ainsi qu'un VPN finit par accorder un sous-réseau entier à tous ceux qui peuvent se connecter.

Arrêtez-vous si le public est inconnu ou change constamment. Enrôler des inconnus dans un réseau privé pour leur montrer une page est un engagement important comparé à la publication d'un service.

Choisir entre les deux, et ce qui reste identique

Choisissez le modèle onion lorsque le public est technique, que le service ne doit avoir aucune adresse publique et que vous pouvez accepter les exigences du client Tor. Choisissez le modèle VPN lorsque le public est un groupe défini dont vous gérez les appareils et dont vous voulez journaliser l'accès au niveau du réseau. Aucun des deux choix ne supprime le besoin d'authentification de l'application, de correctifs ou d'un chemin de restauration. Aucun n'est automatiquement plus privé au sens qui compte pour vos utilisateurs.

Dans les deux conceptions, notez qui peut atteindre le service, comment ces personnes sont identifiées et ce qui se passe lorsqu'un identifiant est perdu. La réponse pour un service onion comprend ses clés d'autorisation de client et l'adresse elle-même ; la réponse pour un VPN comprend le compte, l'appareil et la politique de la passerelle. Ce sont des inventaires différents, et un seul d'entre eux sera évident pour le prochain administrateur.

La comparaison s'arrête là où commence l'application. Une adresse cachée et une route privée sont des choix de transport, et l'application doit encore décider ce qu'une requête est autorisée à faire. Gardez ces décisions dans des documents séparés et aucune des deux conceptions n'absorbera discrètement le travail de l'autre.