Tor bereit vor dem VPN: das Start-Gate richtig ordnen

Auf einen tor-Prozess zu warten und dann das VPN zu starten, ist der häufigste Weg, diesen Stack falsch zu bauen. Der Daemon erscheint lange bevor er einen Client-Stream tragen kann, und ein festes Warten ist eine Vermutung im Gewand einer Abhängigkeit. Das Gate muss der Zustand sein, den die nächste Komponente tatsächlich braucht. Gehen Sie die vier Schritte unten der Reihe nach durch und behandeln Sie jeden als eigene Bedingung statt als Verzögerung zum Einstellen.

Schritt 1: den Transport wählen, den Sie tatsächlich haben

Beginnen Sie mit dem Protokoll, denn der Rest des Entwurfs hängt davon ab. Die SOCKS-Schnittstelle von Tor implementiert kein UDP ASSOCIATE, daher muss alles, was darüber läuft, ein TCP-Stream sein. Ein OpenVPN-Profil mit UDP funktioniert über diesen Weg nicht, egal wie der Supervisor geschrieben ist. Stellen Sie das Profil auf TCP um und bestätigen Sie, dass der Gegenpeer es akzeptiert, bevor Sie die Startlogik anfassen.

Bestätigen Sie dann, dass Ihr Client überhaupt einen SOCKS-Proxy erreichen kann. OpenVPN 2.6 dokumentiert eine socks-proxy-Option für TCP-Profile, und verschiedene Clients bieten unterschiedliche Proxy-Unterstützung. Ein Starter, der die Proxy-Option still ignoriert, verbindet direkt und sieht aus, als würde er funktionieren, was schlimmer ist als ein Fehlschlag.

Schreiben Sie den gewählten Transport ins Runbook, denn jede spätere Prüfung hängt davon ab.

Schritt 2: die Bootstrap-Phase lesen, nicht die Prozessliste

Das Tor-Kontrollprotokoll beantwortet GETINFO status/bootstrap-phase mit dem jüngsten Bootstrap-Zustand, einschließlich eines Fortschrittsprozentsatzes und eines Zusammenfassungs-Tags. Diese Antwort ist gerade deshalb nützlich, weil ein Controller sich erst verbinden kann, nachdem der Daemon den Bootstrap bereits abgeschlossen hat. Ein Supervisor, der nur auf Ereignisse hört, verpasst den Fall, in dem Tor schon bereit war, bevor der Supervisor startete.

Authentifizieren Sie die Kontrollverbindung ordentlich. Ein Kontrollport ist eine administrative Schnittstelle, und wer mit ihm sprechen kann, kann den Daemon umkonfigurieren. Halten Sie ihn auf localhost, lassen Sie die Cookie- oder Passwort-Authentifizierung aktiviert und entfernen Sie keine von beiden, um ein Startskript einfacher zu machen.

Lesen Sie die Phase einmal beim Start und abonnieren Sie dann Fortschrittsereignisse für die Live-Ansicht.

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

Eine Antwort mit Fortschritt 100 und dem Tag done bedeutet, dass der Daemon seinen eigenen Start abgeschlossen hat. Das heißt noch nicht, dass ein nutzbarer Kanal zu Ihrem Ziel existiert.

Schritt 3: auf ein Client-Kanalereignis warten

Das Tor-Ereignisprotokoll definiert CIRCUIT_ESTABLISHED, das meldet, dass der Client einen Kanal hat, den er nutzen kann. Das ist das Bereitschaftssignal, das ein Träger-Gate will, weil es der Fähigkeit, die Sie brauchen, näher liegt als ein Prozentsatz. Abonnieren Sie das Ereignis und zeichnen Sie den Übergang auf, damit das Protokoll zeigt, wann der Träger nutzbar wurde, und nicht, wann der Prozess erschien.

Behandeln Sie das Ereignis als Erlaubnis zum Versuch, nicht als Garantie für ein bestimmtes Ziel. Eine Exit-Policy kann den Gegenpeer weiterhin ablehnen, und der Handshake des VPN selbst kann aus Gründen scheitern, die nichts mit Tor zu tun haben.

Halten Sie die beiden Bedingungen im Code getrennt. Ein einzelner boolescher Wert namens ready verschmilzt sie und macht den nächsten Vorfall unlesbar.

Schritt 4: das VPN an seinem eigenen Handshake ausrichten

Das VPN hat seine eigene Bereitschaftsbedingung, und nur sie beweist, dass der Tunnel hochkam. Warten Sie, bis der Client einen verbundenen Zustand mit zugewiesener Adresse meldet, und prüfen Sie dann, dass die Proxy-Anforderung in Kraft blieb. Eine Wiederholungsschleife, die die socks-proxy-Option nach einem Fehlschlag fallen lässt, verbindet direkt und untergräbt still den ganzen Entwurf.

Entscheiden Sie, was passiert, wenn der Gegenpeer nicht erreichbar ist, bevor Sie es wissen müssen. Ein begrenzter Wiederholungsversuch mit sichtbarem Fehlschlag ist leichter zu betreiben als eine Endlosschleife, und er gibt dem Monitoringsystem etwas zum Alarmieren. Dieselbe Entscheidung gilt für den Träger: Wenn Tor neu startet, muss das VPN abgebaut und erneut gegatet werden, statt auf einem toten Kanal weiterzulaufen.

Behalten Sie schließlich die eigene Richtlinie der Anwendung bei, solange das VPN unten ist. Ein Supervisor, der korrekt wartet, tut nichts, um zu verhindern, dass ein unabhängiger Prozess Datenverkehr direkt sendet.

Prüfen Sie die vier Übergänge, die Sie überstehen müssen

Vier Fälle decken den Entwurf ab: ein Kaltstart, bei dem Tor zuerst hochkommt, ein Supervisor, der sich an ein bereits bereites Tor anhängt, ein nicht erreichbarer VPN-Gegenpeer und der Verlust des Trägers, während der Tunnel steht. Jeder hat einen anderen erwarteten Übergang, und jeder erzeugt eine andere Protokollzeile, wenn das Gate richtig geschrieben ist.

Führen Sie sie bewusst aus, eins nach dem anderen, und lesen Sie die Zustandsänderungen statt der Prozessliste.

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

Wenn der Träger wegfällt, sollte das VPN ihm innerhalb eines Wiederholungsintervalls nach unten folgen, statt mit einem veralteten Tunnel hängen zu bleiben. Wenn Tor zurückkehrt, sollte das Gate erst nach dem Kanalereignis wieder öffnen, nicht nach dem Prozessstart. Protokollieren Sie, welche Bedingung bei jedem Fehlschlag fehlte, und die nächste Bereitschaftsperson muss die Reihenfolge nicht aus Zeitstempeln rekonstruieren.