Tor prêt avant le VPN : bien ordonner la porte de démarrage

Surveiller un processus tor puis démarrer le VPN est la façon la plus courante de construire mal cette pile. Le démon apparaît bien avant de pouvoir transporter un flux client, et une attente fixe est une supposition déguisée en dépendance. La porte doit être l’état dont le composant suivant a réellement besoin. Parcourez les quatre étapes ci-dessous dans l’ordre et traitez chacune comme une condition distincte plutôt que comme un délai à régler.

Étape 1 : choisissez le transport que vous avez réellement

Commencez par le protocole, car le reste de la conception en dépend. L’interface SOCKS de Tor n’implémente pas UDP ASSOCIATE, donc tout ce qui passe par elle doit être un flux TCP. Un profil OpenVPN qui utilise UDP ne fonctionnera pas par ce chemin, quelle que soit la façon dont le superviseur est écrit. Basculez le profil vers TCP et confirmez que le pair distant l’accepte avant de toucher à la logique de démarrage.

Confirmez ensuite que votre client peut du tout atteindre un proxy SOCKS. OpenVPN 2.6 documente une option socks-proxy pour les profils TCP, et différents clients exposent un support de proxy différent. Un lanceur qui ignore silencieusement l’option de proxy se connectera directement et semblera fonctionner, ce qui est pire qu’un échec.

Écrivez le transport choisi dans le runbook, car chaque vérification ultérieure en dépend.

Étape 2 : lisez la phase bootstrap, pas la liste des processus

Le protocole de contrôle de Tor répond à GETINFO status/bootstrap-phase avec l’état de bootstrap le plus récent, y compris un pourcentage de progression et une étiquette de résumé. Cette réponse est utile précisément parce qu’un contrôleur peut se connecter après que le démon a déjà terminé le bootstrap. Un superviseur qui ne fait qu’écouter des événements manquera le cas où Tor était prêt avant le démarrage du superviseur.

Authentifiez correctement la connexion de contrôle. Un port de contrôle est une interface administrative, et quiconque peut lui parler peut reconfigurer le démon. Gardez-le sur localhost, gardez l’authentification par cookie ou mot de passe active, et ne supprimez ni l’une ni l’autre pour simplifier un script de démarrage.

Lisez la phase une fois au démarrage, puis abonnez-vous aux événements de progression pour la vue en direct.

printf 'AUTHENTICATE\r\nGETINFO status/bootstrap-phase\r\nQUIT\r\n' | nc 127.0.0.1 9051
ss -ltn | grep -E '9050|9051'
tor --verify-config -f /etc/tor/torrc

Une réponse avec une progression de 100 et l’étiquette done signifie que le démon a terminé son propre démarrage. Cela ne signifie pas encore qu’un circuit utilisable existe vers votre destination.

Étape 3 : attendez un événement de circuit client

Le protocole d’événements de Tor définit CIRCUIT_ESTABLISHED, qui signale que le client dispose d’un circuit qu’il peut utiliser. C’est le signal de disponibilité qu’une porte de transport souhaite, car il est plus proche de la capacité dont vous avez besoin qu’un pourcentage. Abonnez-vous à l’événement et enregistrez la transition, afin que le journal montre quand le transport est devenu utilisable et non quand le processus est apparu.

Traitez l’événement comme une autorisation d’essayer, pas comme une garantie sur une destination particulière. Une politique de sortie peut encore refuser le pair distant, et le handshake du VPN lui-même peut encore échouer pour des raisons qui n’ont rien à voir avec Tor.

Gardez les deux conditions séparées dans le code. Un seul booléen nommé ready les fusionnera et rendra le prochain incident illisible.

Étape 4 : conditionnez le VPN à son propre handshake

Le VPN a sa propre condition de disponibilité, et c’est la seule qui prouve que le tunnel est monté. Attendez que le client signale un état connecté avec une adresse attribuée, puis vérifiez que l’exigence de proxy est restée en vigueur. Une boucle de nouvelle tentative qui abandonne l’option socks-proxy après un échec se connectera directement et déjouera silencieusement toute la conception.

Décidez ce qui se passe lorsque le pair est injoignable avant d’avoir besoin de le savoir. Une nouvelle tentative bornée avec un échec visible est plus facile à exploiter qu’une boucle infinie, et elle donne au système de supervision quelque chose sur quoi alerter. La même décision vaut pour le transport : si Tor redémarre, le VPN doit être démonté et reconditionné plutôt que laissé en marche sur un circuit mort.

Enfin, maintenez la politique propre à l’application pendant que le VPN est arrêté. Un superviseur qui attend correctement ne fait rien pour empêcher un processus sans rapport d’envoyer du trafic directement.

Vérifiez les quatre transitions que vous devez survivre

Quatre cas couvrent la conception : un démarrage à froid où Tor monte en premier, un superviseur qui s’accroche à un Tor déjà prêt, un pair VPN indisponible et la perte du transport alors que le tunnel est monté. Chacun a une transition attendue différente, et chacun produit une ligne de journal différente si la porte est bien écrite.

Exécutez-les délibérément, une à la fois, et lisez les changements d’état plutôt que la liste des processus.

journalctl -u tor@default -n 30 --no-pager
systemctl status [email protected]
curl -sS --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip

Quand le transport tombe, le VPN devrait le suivre vers le bas dans un intervalle de nouvelle tentative plutôt que de rester avec un tunnel périmé. Quand Tor revient, la porte ne devrait se rouvrir qu’après l’événement de circuit, pas après le démarrage du processus. Consignez quelle condition manquait à chaque échec, et la personne de garde suivante n’aura pas à reconstruire l’ordre à partir des horodatages.