Tor prett virun der VPN: d'Startpaart richteg uerdnen
En lafende tor-Prozess ass keen Träger. Paart d'VPN op en dokumentéiert Client-prett-Zeechen, duerno op seng eege Peer, a halt d'Alternativen getrennt.
Ee tor-Prozess ze beobachten an duerno d'VPN ze starten ass dee heefegste Wee, dëse Stack falsch ze bauen. Den Daemon erschéngt vill éier hien e Client-Stroum ka droen, an eng fest Waardzäit ass eng Vermutung, déi sech als Ofhängegkeet verkleet. D'Paart muss deen Zoustand sinn, deen déi nächst Komponent wierklech brauch. Gitt déi véier Schrëtt hei drënner an der Rei duerch a behandelt jiddereen als eege Bedingung amplaz als Verzögerung, déi een astelle muss.
Schrëtt 1: wielt de Transport, deen Dir tatsächlech hutt
Fänkt mam Protokoll un, well de Rescht vum Design dovun ofhänkt. Dem Tor seng SOCKS-Schnittstell implementéiert keen UDP ASSOCIATE, dofir muss alles, wat driwwer gedroe gëtt, en TCP-Stroum sinn. En OpenVPN-Profil, deen UDP benotzt, wäert iwwer dëse Wee net funktionéieren, egal wéi de Supervisor geschriwwen ass. Wiesselt de Profil op TCP an bestätegt, datt de wäite Peer en acceptéiert, ier Dir d'Startlogik beréiert.
Bestätegt duerno, datt Äre Client iwwerhaapt en SOCKS-Proxy erreeche kann. OpenVPN 2.6 dokumentéiert eng socks-proxy-Optioun fir TCP-Profiler, a verschidde Cliente bidden ënnerschiddlech Proxy-Ënnerstëtzung. En Uruff, deen d'Proxy-Optioun stëll ignoréiert, verbënnt sech direkt a gesäit aus wéi wann en funktionéiert, wat schlëmmer ass wéi ze scheiteren.
Schreift den ausgewielten Transport an de Runbook, well all spéider Kontroll dovun ofhänkt.
Schrëtt 2: liest d'Bootstrap-Phase, net d'Prozesslëscht
Dem Tor säi Kontrollprotokoll äntwert op GETINFO status/bootstrap-phase mam leschte Bootstrap-Zoustand, abegraff engem Fortschrëttsprozentsaz an engem Zesummefaassungs-Tag. Déi Äntwert ass just dofir nëtzlech, well e Controller sech nach uschléisse kann, nodeems den Daemon de Bootstrap schonn ofgeschloss huet. En Iwwerwaacher, deen nëmmen op Evenementer lauschtert, verpasst de Fall, wou Tor schonn prett war, ier den Iwwerwaacher ugefaangen huet.
Authentifizéiert d'Kontrollverbindung richteg. E Kontrollport ass eng administrativ Schnittstell, a jidderee kann den Daemon nei konfiguréieren, dee mat hir schwätze kann. Halt en op localhost, halt d'Cookies- oder Passwuert-Authentifizéierung aktiv, a läscht keng vun den zwou, fir en Startskript méi einfach ze maachen.
Liest d'Phase eng Kéier beim Start a melzt Iech duerno fir Fortschrëttsevenementer an, fir d'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/torrcEng Äntwert mat Fortschrëtt 100 an dem Tag done bedeit, datt den Daemon säin eegene Start ofgeschloss huet. Et bedeit nach net, datt et en notzleche Circuit an Äert Zil gëtt.
Schrëtt 3: waart op en Evenement vum Client-Circuit
Dem Tor säin Evenementsprotokoll definéiert CIRCUIT_ESTABLISHED, wat mellt, datt de Client e Circuit huet, deen en notze kann. Dat ass de Prett-Zeechen, wat eng Träger-Paart wëll, well et méi no bei der Fäegkeet ass, déi Dir braucht, wéi ee Prozentsaz. Meld Iech beim Evenement un a schreift den Iwwergang op, sou datt de Log weist, wéini den Träger notzlech gouf an net wéini de Prozess erschéng.
Behandelt d'Evenement als Erlaabnis ze probéieren, net als Garantie fir en bestëmmten Zil. Eng Ausgangspolitik kann de wäite Peer ëmmer nach refuséieren, an den Handshake vun der VPN selwer kann ëmmer nach aus Grënn scheiteren, déi näischt mat Tor ze dinn hunn.
Halt déi zwou Bedingungen am Code getrennt. En eenzege boolesche Wäert mam Numm ready wäert se zesummeféieren an den nächsten Tëschefall onliesbar maachen.
Schrëtt 4: paart d'VPN um hirem eegenen Handshake
D'VPN huet hir eege Prett-Bedingung, an nëmmen déi beweist, datt den Tunnel eropkomm ass. Waart, bis de Client en ageschaltene Zoustand mat enger zougewisener Adress mellt, a kontrolléiert duerno, datt d'Proxy-Fuerderung a Kraaft bliwwen ass. Eng Widderhuelungsschleef, déi d'socks-proxy-Optioun no engem Feeler fale léisst, verbënnt sech direkt a schloe stëll dat ganzt Design.
Entscheet, wat geschitt, wann de Peer net erreechbar ass, ier Dir et wësse musst. Eng begrenzt Widderhuelung mat engem sichtbare Feeler ass méi einfach ze bedreiwen wéi eng endlos Schleef, an et gëtt dem Monitoring-System eppes fir ze alarméieren. Déi selwecht Entscheedung gëllt fir den Träger: wann Tor nei start, muss d'VPN ofgerappt an nei gepaart ginn, amplaz op engem doudege Circuit lafe gelooss ze ginn.
Um Schluss hält d'Applikatioun hir eege Politik a Kraaft, wärend d'VPN ënnen ass. En Iwwerwaacher, dee richteg waart, mécht näischt, fir ze verhënneren, datt en onbedeelegte Prozess Verkéier direkt schéckt.
Kontrolléiert déi véier Iwwergäng, déi Dir musst iwwerstoen
Véier Fäll decken d'Design of: en kill Start, wou Tor als éischten eropkënnt, en Iwwerwaacher, dee sech un en schonn prett Tor ukoppelt, en net erreechbare VPN-Peer an de Verloscht vum Träger, wärend den Tunnel erop ass. Jiddereen huet en aneren erwaarten Iwwergang, a jiddereen produzéiert eng aner Loglinn, wann d'Paart richteg geschriwwen ass.
Fuert se bewosst aus, eng nom aneren, a liest d'Zoustandsännerungen amplaz vun der Prozesslëscht.
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/ipWann den Träger fält, soll d'VPN him bannent engem Widderhuelungsintervall no ënnen nokommen, amplaz mat engem veralteten Tunnel hänken ze bleiwen. Wann Tor zréckkënnt, soll d'Paart nëmmen nom Circuit-Evenement nees opgoen, net nom Start vum Prozess. Loggt, wéi eng Bedingung bei all Feeler gefehlt huet, an déi nächst Persoun am Déngscht muss d'Reiefolleg net aus Zäitstempel rekonstruéieren.