Tor passe-t-il par le VPN ? Ce que change le tunnel divisé

Voici la croyance qui mérite d'être testée : un badge connecté signifie que le trafic de Tor est d'abord passé par le VPN. L'inférence échoue plus souvent qu'elle ne le devrait, et elle échoue en silence. Un sélecteur de tunnel divisé peut laisser le processus Tor hors du tunnel pendant que l'appareil reste connecté, et les deux observations sont vraies en même temps. L'icône signale une interface ; le chemin qu'ont suivi vos paquets est une autre question. Répondez-y à partir du routage et du sélecteur, pas du badge.

Ce qu'un badge connecté prouve, et ce qu'il ne prouve pas

Un VPN connecté signifie qu'une interface est active et qu'un tunnel vers le pair existe. La connexion d'entrée de Tor est un autre flux, créé par un autre processus, et son entrée dans ce tunnel dépend du sélecteur et de la table de routage qui lui sont appliqués. Excluez le processus et le VPN se connecte quand même, Tor construit quand même un circuit, et l'ordre que vous vouliez n'a pas eu lieu. Les deux observations répondent à des questions différentes, et c'est pourquoi aucune seule ne tranche l'ordre.

Cet écart n'est pas un défaut de l'un ou l'autre outil. C'est précisément à cela que sert une règle d'exclusion, et la règle a probablement été écrite pour une raison dont quelqu'un se souvient encore.

Quel sélecteur le client applique à une connexion

Ce qui décide du chemin, c'est le sélecteur que le client applique à chaque connexion : un nom de processus, un préfixe de destination ou une entrée de route, selon le client. Un raccourci du bureau ne correspond à aucun d'eux, car c'est un lanceur, pas une unité de politique. Lisez le jeu de règles du client et nommez l'unité qu'il teste réellement avant de raisonner sur Tor. Si le client sélectionne par destination, la question devient quels préfixes se trouvent dans le tunnel, et non quel programme tourne.

Une règle fondée sur la destination qui ne porte que des préfixes de bureau privé est une forme courante, et elle laisse les connexions d'entrée ordinaires de Tor directes par conception. C'est la politique qui fonctionne comme configurée, et ce n'est pas l'ordre VPN-avant-Tor, aussi sain que le badge paraisse. Écrivez le sélecteur et les préfixes exclus sur la même ligne de vos notes, car ce couple est la règle.

Ce qui arrive à Tor quand le tunnel tombe

Retirez maintenant le tunnel et regardez ce que fait Tor, car une politique qui ne tient que tant que le réseau est sain n'est pas celle que vous avez décrite. Le client peut refuser le trafic direct pendant la panne, le permettre en silence, ou se reconnecter et réappliquer la règle un instant plus tard. Une déconnexion manuelle et un plantage sont des événements différents, et le plantage est celui que personne n'a répété. Testez avec un trafic inoffensif et notez lequel des trois résultats vous avez réellement observé.

Lisez aussi le comportement documenté du client, mais traitez la documentation comme une hypothèse jusqu'à ce que votre test lui donne raison. Les fournisseurs décrivent le défaut ; votre profil décide de l'exception.

Pourquoi l'adresse de sortie ne peut pas répondre à la question d'entrée

Un site atteint via Tor rapporte l'adresse du relais de sortie, ce qui vous dit d'où le circuit est sorti et rien sur la façon dont le premier saut a quitté votre appareil. Les gens citent cette adresse comme preuve de l'ordre VPN-d'abord, et elle ne peut pas porter ce poids. La question d'entrée est locale : quelle interface a porté la connexion jusqu'au premier relais, et quelle adresse source le pair VPN aurait vue. Répondez-y par une recherche de route ou une capture de paquets sur l'appareil, pas par un site web.

Deux chemins différents peuvent produire le même pays de sortie, donc un résultat concordant prouve encore moins qu'il n'y paraît. Comparez les interfaces, pas la géographie.

Des applications qui n'ont jamais hérité des réglages du navigateur

Une visionneuse de documents, un client de synchronisation et un gestionnaire de paquets font chacun leurs propres connexions, et aucun n'hérite des réglages de proxy du navigateur. Chacun suit le sélecteur du client, sa propre configuration ou le proxy système, et la combinaison est rarement écrite. C'est ainsi qu'une liste d'exceptions grandit : une application à la fois, chaque ajout raisonnable, jusqu'à ce que personne ne puisse dire ce que la liste couvre. Tenez plutôt un court schéma par application, nommant le sélecteur, la route et le comportement en cas d'échec.

Si la couche VPN supplémentaire ne sert aucun but que vous puissiez énoncer, retirer la couche est plus facile à vérifier que de tenir une longue liste d'exceptions. Par ailleurs, la note du Projet Tor sur les VPN aborde la même question d'ordre par l'autre bout. Moins de pièces mobiles signifie moins d'hypothèses à retester après la prochaine mise à jour du client.