VPN dans Tor, Tor dans VPN : pourquoi la chaîne casse
Quand un VPN, Tor et un proxy sont empilés, l'ordre décide de ce qui est résolu et de ce qui est transporté. Trouvez la première frontière cassée avant de changer les trois.
Empiler un VPN, Tor et un proxy d'application donne l'impression de multiplier la confidentialité, et cela multiplie le nombre d'endroits où une connexion peut mourir. Le résultat habituel est un navigateur qui tourne pendant que trois outils se déclarent chacun en bonne santé. Changer les trois réglages d'un coup supprime alors le seul indice sur lequel ment.
Dessinez d'abord le chemin prévu, dans l'ordre, en nommant le programme qui ouvre chaque connexion et le nom qui est résolu à chaque étape.
Les couches ne s'additionnent pas, elles interagissent
Un VPN avant Tor signifie que la connexion d'entrée du client Tor voyage à l'intérieur du tunnel. Un VPN porté à travers Tor signifie que le point de sortie du client VPN lui-même doit être joignable via Tor, ce qui est une exigence très différente. Le proxy du navigateur ajoute encore un saut dont le système d'exploitation ne sait rien. Trois agencements, trois listes de dépendances séparées.
Chaque agencement change ce qui peut être résolu, ce qui peut être transporté, et qui voit le premier paquet. Un seul d'entre eux peut être la configuration que vous vouliez.
Ajoutez aussi le chemin direct au schéma. Une route de secours, une exclusion de tunnel divisé ou un contournement de proxy peuvent faire charger une page tout en sautant silencieusement la chaîne que vous vouliez tester, et ce succès trompe plus que l'échec.
L'ordre décide de ce qui peut être transporté
Tor transporte des flux TCP via son interface SOCKS, et un client qui demande au proxy de résoudre le nom d'hôte garde la requête à l'intérieur du circuit. UDP ne voyage pas ainsi dans les configurations ordinaires, c'est pourquoi un tunnel WireGuard ne peut pas être imbriqué dans Tor sans un relais TCP supplémentaire au milieu.
OpenVPN peut être forcé en TCP, donc cet agencement est au moins descriptible. Il est aussi plus lent et plus fragile, et le mode de défaillance quand il casse ressemble à un port bloqué. Attendez-vous à passer plus de temps à distinguer ces deux cas qu'à réparer l'un ou l'autre.
La résolution est l'autre moitié. Avec --socks5-hostname le proxy résout la destination, alors qu'un simple --socks5 interroge d'abord le résolveur local et fait fuiter le nom hors du circuit. Ce seul drapeau décide si la recherche du nom appartient à la chaîne ou à votre fournisseur d'accès.
| Order | What must resolve the endpoint | What usually breaks |
|---|---|---|
| VPN, then Tor | The tunnel's resolver | Entry guards blocked by the VPN provider's filters |
| Tor, then VPN | The SOCKS proxy, remotely | UDP transports, which Tor does not carry |
| App proxy on top | The application itself | Proxy bypass rules and cached connections |
Localiser la première frontière cassée
Testez les étapes dans l'ordre où voyagent les paquets, avec des requêtes inoffensives, et arrêtez-vous à la première qui échoue. Notez quelle commande a été exécutée en premier, car l'ordre fait partie de la preuve. Deux commandes séparent un circuit mort d'une sortie morte :
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
La première indique si une requête aboutit tout court à travers le proxy SOCKS, et la seconde montre l'adresse que le réseau présente actuellement. Si la première échoue et que la seconde réussit, le problème se situe au niveau du client Tor ou avant. Si les deux réussissent et que le navigateur échoue encore, l'application utilise un chemin différent de celui du shell.
Une page d'IP publique ne décrit elle aussi que la dernière sortie visible. Elle ne peut pas dire combien de sauts l'ont précédée, alors associez-la à la sortie d'état prise en charge de chaque outil plutôt que de traiter un seul chiffre comme un schéma.
Quand arrêter d'ajouter des couches
Si vous ne pouvez pas dire en une phrase ce qu'une couche apporte, retirez-la. Une chaîne dont le but n'est pas clair est une chaîne que personne ne peut déboguer à trois heures du matin, et le gain de confidentialité d'un saut inexpliqué est généralement inférieur à la disponibilité que vous perdez.
Si une couche mérite vraiment sa place, testez-la seule d'abord, ajoutez ensuite la suivante et confirmez à nouveau le chemin avec les mêmes deux commandes. Restaurez la chaîne complète avant l'usage ordinaire et gardez la validation TLS et l'authentification activées ; un avertissement de certificat accepté pour faire charger une page est un contournement de routage, pas une réparation. Notez l'ordre sur lequel vous avez atterri pendant qu'il est frais.
Écrivez cet ordre, y compris le résolveur qui répond à chaque étape. Une chaîne qui fonctionne et que vous pouvez décrire survit à la mise à jour suivante, tandis qu'une chaîne qui fonctionne et que vous avez montée par essais disparaît avec elle. Ajoutez la date et les versions, afin qu'une panne ultérieure puisse être comparée à un état connu comme bon au lieu d'être discutée de mémoire. Dix lignes dans un fichier texte économisent une soirée de suppositions.