Un accès bloqué, un Tor Browser qui ne se connecte pas et deux produits proposés comme solutions : un pont et un VPN. Ils échouent à des endroits différents et réparent des choses différentes. Un pont est un point d’entrée vers Tor qui n’est pas publié dans l’annuaire des relais, tandis qu’un VPN est un tunnel vers un opérateur que vous avez choisi. Choisir entre les deux commence par nommer ce qui est réellement cassé.

Deux outils, deux tâches différentes

Un pont change la façon dont le Tor Browser atteint le réseau Tor. Le client construit toujours un circuit, utilise toujours un relais de sortie pour le web public et dépend toujours des autorités d’annuaire pour tout sauf ce premier saut. Un VPN change la façon dont la machine locale atteint un point de sortie que vous choisissez, et tout ce qui suit ce point relève de l’opérateur.

Cette différence décide quelle panne chaque outil peut traiter. Si les connexions vers des adresses d’entrée Tor connues sont bloquées, un pont offre une autre entrée, et la documentation des ponts du Tor Project décrit les manières prises en charge d’en obtenir un. Si le réseau inspecte tout le trafic, un pont peut aider ou non, car les transports enfichables changent la forme d’une connexion au lieu de garantir que personne ne peut la reconnaître. Si le réseau local surveille les destinations, la réponse est une tout autre question. Amenez le symptôme avant d’amener un produit.

Ce qu’un pont cache réellement

Un pont est un relais absent de l’annuaire public, distribué par des canaux séparés comme le flux de demande intégré ou le courriel. Il cache le point d’entrée à quiconque lit la liste publique, et c’est là tout son but.

Il ne cache pas la destination au site que vous visitez, car le relais de sortie fait toujours cette demande. Il ne rend pas non plus le réseau local aveugle, puisque la connexion quitte toujours la machine avec une adresse et un motif temporel. Un pont est d’abord un outil d’accessibilité et ensuite un outil de confidentialité.

Ce que change Tor acheminé par un VPN

Faire passer Tor par un VPN déplace le premier saut : le réseau local voit le point de sortie du VPN, et l’opérateur du VPN voit une connexion vers une entrée Tor. Le circuit lui-même ne change pas à partir de ce point.

Cet arrangement déplace qui peut observer la connexion d’entrée et ajoute un autre compte, client et mode de défaillance à maintenir. Il change aussi ce que l’opérateur du VPN pourrait corréler, et c’est une question de politique plutôt que de technique. Un VPN ne couvre pas par défaut tous les programmes de la machine, si bien qu’un client de messagerie ou un outil de synchronisation séparé peut continuer à emprunter le chemin ordinaire. Traitez tout indicateur de connexion comme une preuve concernant un programme, non l’appareil.

Vérifiez le programme qui vous concerne

Testez l’application concernée plutôt que la présence d’une icône. Un port SOCKS à l’écoute et un circuit qui fonctionne sont deux faits distincts, et seul le second signifie quelque chose.

tor --verify-config
curl --socks5-hostname 127.0.0.1:9150 https://check.torproject.org/api/ip

La première commande vérifie que le processus Tor accepte sa configuration, et la seconde indique quelle adresse de sortie le réseau voit réellement. Si la seconde échoue alors que la première passe, le problème n’est pas le circuit mais le réglage local du proxy. Répétez la vérification avec l’outil qui échouait, car une extension de navigateur peut avoir sa propre configuration de proxy.

Conservez les preuves avec le ticket : le transport utilisé, le type d’entrée et la sortie observée. Ces trois lignes règlent la plupart des discussions de connectivité sans une nouvelle comparaison de produits.

Articles similaires