Relais Tor contre serveur VPN : pourquoi ils ne sont pas interchangeables

Vous avez une adresse, le port répond et un client l’accepte sans se plaindre. Rien de tout cela ne fait d’un relais Tor un point de terminaison VPN, et l’erreur coûte cher parce que le profil s’importe proprement et échoue plus tard au handshake. J’utilise les quatre vérifications ci-dessous dans l’ordre ; chacune a une condition d’arrêt, et s’arrêter tôt est tout l’intérêt. Si la première vérification échoue, les autres ne peuvent pas vous aider.

Vérifiez ce que le port sert réellement

Un port ouvert prouve un écouteur, rien de plus. L’ORPort d’un relais parle les propres cellules de Tor après un handshake TLS, donc une sonde TLS réussie ne vous dit presque rien sur l’acceptation d’un protocole VPN à cet endroit :

nc -vz 203.0.113.20 443
openssl s_client -connect 203.0.113.20:443 -brief < /dev/null

Lisez le certificat plutôt que le fait qu’il existe. Les relais présentent un certificat auto-signé au nom délibérément banal, parce que le trafic du relais doit ressembler à du HTTPS ordinaire ; le certificat d’un serveur VPN porte le nom que votre profil attend. Si le pair ne répond jamais au premier paquet du protocole VPN, aucune modification du profil ne changera le résultat.

Arrêtez-vous ici si l’adresse ne termine pas le handshake que votre client envoie. C’est une réponse de protocole, pas un problème de configuration, et c’est la raison la plus fréquente pour laquelle un profil importé reste bloqué sur 'connecting' pour toujours.

Vérifiez le rôle du relais, pas la taille du réseau

Les rôles du relais font des tâches différentes. Un guard est le premier saut pour les clients, un relais intermédiaire achemine les circuits entre autres relais, un exit est celui qui touche les destinations, et un pont est un point d’entrée non public distribué via BridgeDB. Le glossaire de Tor maintient ces définitions séparées, et être joignable fait partie de chaque rôle tandis que l’autorisation de servir des clients arbitraires ne fait partie d’aucun.

La politique d’exit mérite d’être lue car c’est la seule partie qui ressemble à une règle de transfert, et elle régit les destinations que l’exit autorise vers l’extérieur, non les clients autorisés à entrer. Une politique d’exit restrictive qui bloque le port 25 dit quelque chose sur le contrôle des abus sortants, pas sur la possibilité de pointer un client OpenVPN vers la machine.

Arrêtez-vous si vous raisonnez par réputation : comme les relais transfèrent du trafic, l’adresse doit accepter le vôtre. Tor choisit les chemins par consensus et par son propre protocole ; un client VPN n’est pas un participant et n’a aucun circuit à rejoindre.

Vérifiez si l’écouteur SOCKS est local ou public

Le client Tor expose une interface SOCKS aux applications de la même machine, sur le loopback par défaut. Cet écouteur est une commodité locale, pas un service qu’un relais offrirait à internet, et le traiter comme un proxy public est la façon dont les gens finissent par faire tourner un relais ouvert qu’ils ne voulaient pas :

ss -ltnp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org

L’adresse de liaison est l’indice. Un SocksPort sur 127.0.0.1:9050 fait son travail ; celui qui écoute sur 0.0.0.0 et reste joignable de l’extérieur est un proxy ouvert, et les contrôles de politique d’accès de Tor existent précisément parce que cette exposition est un problème et non une fonctionnalité.

Pour une application qui a besoin de Tor, pointez-la vers le port loopback et laissez Tor résoudre les noms, ce que fait la forme socks5h ci-dessus. Ne remplacez pas l’adresse du relais par ce port ; le relais n’offre pas l’interface que votre application demande.

Vérifiez que le profil VPN correspond à un point de terminaison réel

Un profil VPN est un ensemble d’attentes : OpenVPN a besoin du certificat du serveur ou de la CA, d’un certificat client et d’une clé, et généralement d’une clé TLS, tandis que WireGuard a besoin de la clé publique du pair, d’un point de terminaison et d’IP autorisées. Rien de cela ne peut être dérivé d’une adresse et d’un port ouvert, ce qui explique qu’un profil construit ainsi échoue au premier échange plutôt qu’à la connexion.

Quand on vous remet un profil, vérifiez-le contre un point de terminaison que vous contrôlez ou un fournisseur que vous pouvez identifier :

wg show
openvpn --config client.ovpn --verb 4

Dans le journal OpenVPN, une erreur de négociation TLS nomme directement la discordance ; dans wg show, un pair sans ligne de handshake n’en a jamais terminé un. Les deux sont plus instructifs que l’indicateur tournant du client, et les deux pointent vers le matériel de clé ou le protocole plutôt que vers Tor.

Vérifiez quelle protection vous avez réellement besoin

C’est la vérification qui décide de l’architecture. Le navigateur Tor vous donne une isolation des circuits et des défenses contre les empreintes qu’un VPN n’a pas ; un VPN change l’adresse que voit une destination et vous authentifie auprès d’un fournisseur. Choisir entre les deux est une question de modèle de menace, pas de compatibilité, et les confondre produit une configuration qui semble privée et ne l’est pas.

L’enchaînement a un ordre. Un VPN transportant du trafic Tor est un agencement pris en charge, parce que le client Tor n’a besoin que de TCP sortant. Un client VPN tunnelisé dans Tor n’est pas la même chose et n’est pas ce que le client Tor implémente, donc ne planifiez pas là-dessus.

Avant d’importer quoi que ce soit, confirmez les quatre points :

• Le port termine le handshake de votre protocole, pas seulement une connexion TCP.
• Vous connaissez le rôle de l’hôte et ne traitez pas le transfert comme une autorisation.
• L’écouteur SOCKS que vous utilisez est en loopback et vous appartient, pas un port public sur le relais de quelqu’un d’autre.
• Les clés ou certificats du profil appartiennent au point de terminaison auquel vous vous connectez.