Tor klaar voor de VPN: de startpoort correct ordenen

Een tor-proces observeren en dan de VPN starten is de meest gebruikelijke manier om deze stapel verkeerd te bouwen. De daemon verschijnt lang voordat hij een clientstream kan dragen, en een vaste wachttijd is een gok verkleed als afhankelijkheid. De poort moet de toestand zijn die de volgende component echt nodig heeft. Doorloop de vier stappen hieronder in volgorde en behandel elk als een aparte voorwaarde en niet als een vertraging om af te stellen.

Stap 1: kies het transport dat je werkelijk hebt

Begin met het protocol, omdat de rest van het ontwerp daarvan afhangt. Tors SOCKS-interface implementeert geen UDP ASSOCIATE, dus alles wat daaroverheen gaat, moet een TCP-stroom zijn. Een OpenVPN-profiel dat UDP gebruikt, werkt niet via dit pad, hoe de supervisor ook is geschreven. Zet het profiel om naar TCP en bevestig dat de externe peer het accepteert voordat je de opstartlogica aanraakt.

Bevestig daarna dat je client überhaupt een SOCKS-proxy kan bereiken. OpenVPN 2.6 documenteert een socks-proxy-optie voor TCP-profielen, en verschillende clients bieden verschillende proxy-ondersteuning. Een starter die de proxy-optie stilzwijgend negeert, verbindt direct en lijkt te werken, wat erger is dan falen.

Schrijf het gekozen transport in het runbook, omdat elke latere controle daarvan afhangt.

Stap 2: lees de bootstrap-fase, niet de proceslijst

Het Tor-besturingsprotocol antwoordt op GETINFO status/bootstrap-phase met de meest recente bootstrap-toestand, inclusief een voortgangspercentage en een samenvattingslabel. Dat antwoord is juist nuttig omdat een controller kan aankoppelen nadat de daemon de bootstrap al heeft afgerond. Een supervisor die alleen op gebeurtenissen luistert, mist het geval waarin Tor al klaar was voordat de supervisor begon.

Authenticeer de besturingsverbinding goed. Een besturingspoort is een administratieve interface, en iedereen die ermee kan praten, kan de daemon opnieuw configureren. Houd hem op localhost, houd cookie- of wachtwoordauthenticatie ingeschakeld, en verwijder geen van beide om een opstartscript eenvoudiger te maken.

Lees de fase één keer bij het starten en abonneer je daarna op voortgangsgebeurtenissen voor de live weergave.

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

Een antwoord met voortgang 100 en het label done betekent dat de daemon zijn eigen start heeft voltooid. Dat betekent nog niet dat er een bruikbaar circuit naar je bestemming bestaat.

Stap 3: wacht op een clientcircuitgebeurtenis

Het Tor-gebeurtenisprotocol definieert CIRCUIT_ESTABLISHED, dat meldt dat de client een circuit heeft dat hij kan gebruiken. Dat is het gereedheidssignaal dat een dragerpoort wil, omdat het dichter bij de capaciteit die je nodig heb ligt dan een percentage. Abonneer je op de gebeurtenis en leg de overgang vast, zodat het log toont wanneer de drager bruikbaar werd en niet wanneer het proces verscheen.

Behandel de gebeurtenis als toestemming om te proberen, niet als garantie voor een bepaalde bestemming. Een exitbeleid kan de externe peer nog steeds weigeren, en de handshake van de VPN zelf kan nog steeds mislukken om redenen die niets met Tor te maken hebben.

Houd de twee voorwaarden apart in de code. Een enkele boolean met de naam ready voegt ze samen en maakt het volgende incident onleesbaar.

Stap 4: poort de VPN op zijn eigen handshake

De VPN heeft zijn eigen gereedheidsvoorwaarde, en alleen die bewijst dat de tunnel omhoogkwam. Wacht tot de client een verbonden toestand met een toegewezen adres meldt, en controleer daarna dat de proxy-eis van kracht bleef. Een herhaallus die de socks-proxy-optie na één fout laat vallen, verbindt direct en verslaat stil het hele ontwerp.

Beslis wat er gebeurt als de peer onbereikbaar is voordat je het moet weten. Een begrensde herhaling met een zichtbare fout is eenvoudiger te bedienen dan een eindeloze lus, en geeft het monitoringsysteem iets om op te alarmeren. Dezelfde beslissing geldt voor de drager: als Tor opnieuw start, moet de VPN worden afgebroken en opnieuw worden gepoort, niet worden achtergelaten op een dood circuit.

Houd tot slot de eigen beleidsregels van de applicatie in stand terwijl de VPN uit staat. Een supervisor die correct wacht, doet niets om te voorkomen dat een niet-gerelateerd proces verkeer direct verstuurt.

Controleer de vier overgangen die je moet overleven

Vier gevallen dekken het ontwerp: een koude start waarin Tor eerst omhoogkomt, een supervisor die aankoppelt bij een al klaar Tor, een niet-beschikbare VPN-peer en verlies van de drager terwijl de tunnel omhoog staat. Elk heeft een andere verwachte overgang, en elk levert een andere logregel op als de poort goed is geschreven.

Voer ze bewust uit, één voor één, en lees de toestandsveranderingen en niet de proceslijst.

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

Wanneer de drager wegvalt, moet de VPN binnen één herhaalinterval met hem mee naar beneden gaan en niet met een verouderde tunnel blijven hangen. Wanneer Tor terugkeert, moet de poort pas na de circuitgebeurtenis weer opengaan, niet na de start van het proces. Noteer welke voorwaarde bij elke fout ontbrak, en de volgende dienstdoende persoon hoeft de volgorde niet uit tijdstempels te reconstrueren.