Tor gereed voor die VPN: die opstarthek in die regte volgorde plaas

Om op 'n tor-proses te wag en dan die VPN te begin, is die mees algemene manier om hierdie stapel verkeerd te bou. Die daemon verskyn lank voordat dit 'n kliëntstroom kan dra, en 'n vaste slaap is 'n raaiskoot wat as 'n afhanklikheid vermom is. Die hek moet die toestand wees wat die volgende komponent werklik nodig het. Volg die vier stappe hieronder in volgorde, en behandel elkeen as 'n afsonderlike voorwaarde eerder as 'n vertraging om te fynstel.

Stap 1: kies die vervoer wat jy werklik het

Begin met die protokol, want die res van die ontwerp hang daarvan af. Tor se SOCKS-koppelvlak implementeer nie UDP ASSOCIATE nie, so enigiets wat daaroor gedra word, moet 'n TCP-stroom wees. 'n OpenVPN-profiel wat UDP gebruik, sal nie deur hierdie pad werk nie, maak nie saak hoe die toesighouer geskryf is nie. Skakel die profiel oor na TCP en bevestig dat die afstand-eweknie dit aanvaar voordat jy aan die opstartlogika raak.

Bevestig dan dat jou kliënt enigsins 'n SOCKS-volmag kan bereik. OpenVPN 2.6 dokumenteer 'n socks-proxy-opsie vir TCP-profiele, en verskillende kliënte bied verskillende volmagondersteuning. 'n Bekleërmaker wat die volmagopsie stilweg ignoreer, sal direk koppel en dit sal lyk of dit werk, wat erger is as om te misluk.

Skryf die gekose vervoer in die runbook, want elke latere kontrole hang daarvan af.

Stap 2: lees die bootstrap-fase, nie die proseslys nie

Die Tor-beheerprotokol antwoord GETINFO status/bootstrap-phase met die mees onlangse bootstrap-toestand, insluitend 'n vorderingspersentasie en 'n opsomming-etiket. Daardie antwoord is juis nuttig omdat 'n beheerder kan aansluit nadat die daemon reeds klaar gebootstrap het. 'n Toesighouer wat net vir gebeurtenisse luister, sal die geval mis waar Tor gereed was voordat die toesighouer begin het.

Verifieer die beheerverbinding behoorlik. 'n Beheerpoort is 'n administratiewe koppelvlak, en enigiemand wat daarmee kan praat, kan die daemon herkonfigureer. Hou dit op localhost, hou koekie- of wagwoordverifikasie geaktiveer, en moenie een van die twee verwyder om 'n opstartskrip eenvoudiger te maak nie.

Lees die fase een keer by opstart, en teken dan in op vorderingsgebeurtenisse vir die lewende aansig.

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

Antwoord met vordering 100 en die done-etiket beteken die daemon het sy eie opstart voltooi. Dit beteken nog nie dat daar 'n bruikbare stroombaan vir jou bestemming bestaan nie.

Stap 3: wag vir 'n kliënt-stroombaangebeurtenis

Die Tor-gebeurtenisprotokol definieer CIRCUIT_ESTABLISHED, wat rapporteer dat die kliënt 'n stroombaan het wat hy kan gebruik. Dit is die gereedheidsein wat 'n draerhek wil hê, want dit is nader aan die vermoë wat jy nodig het as wat 'n persentasie is. Teken in op die gebeurtenis en teken die oorgang op, sodat die log wys wanneer die draer bruikbaar geword het eerder as wanneer die proses verskyn het.

Behandel die gebeurtenis as toestemming om te probeer, nie as 'n waarborg oor enige bepaalde bestemming nie. 'n Uittreebeleid kan steeds die afstand-eweknie weier, en die VPN se eie handdruk kan steeds misluk om redes wat niks met Tor te doen het nie.

Hou die twee voorwaardes apart in die kode. 'n Enkele booleaanse waarde met die naam ready sal hulle saamvat en die volgende voorval onleesbaar maak.

Stap 4: hek die VPN op sy eie handdruk

Die VPN het sy eie gereedheidstoestand, en dit is die enigste een wat bewys die tonnel het opgekom. Wag tot die kliënt 'n gekoppelde toestand met 'n toegewysde adres rapporteer, en kontroleer dan dat die volmagvereiste van krag gebly het. 'n Herprobeerlus wat die socks-proxy-opsie ná een mislukking laat vaar, sal direk koppel en die hele ontwerp stilweg verydel.

Besluit wat gebeur wanneer die eweknie onbereikbaar is voordat jy dit moet weet. 'n Begrensde herprobeer met 'n sigbare mislukking is makliker om te bedryf as 'n oneindige lus, en dit gee die moniteringstelsel iets om oor te waarsku. Dieselfde besluit geld vir die draer: as Tor herbegin, moet die VPN afgebreek en weer gehek word eerder as om op 'n dooie stroombaan te bly loop.

Laastens, hou die toepassing se eie beleid in plek terwyl die VPN af is. 'n Toesighouer wat korrek wag, doen niks om te verhoed dat 'n onverwante proses verkeer direk stuur nie.

Kontroleer die vier oorgange wat jy moet oorleef

Vier gevalle dek die ontwerp: 'n koue begin waar Tor eerste opkom, 'n toesighouer wat by 'n reeds gereed Tor aansluit, 'n onbeskikbare VPN-eweknie, en verlies van die draer terwyl die tonnel op is. Elkeen het 'n ander verwagte oorgang, en elkeen lewer 'n ander logreël as die hek behoorlik geskryf is.

Voer hulle doelbewus uit, een op 'n slag, en lees die toestandsveranderings eerder as die proseslys.

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 die draer val, moet die VPN binne een herprobeerinterval saam met hom afgaan eerder as om met 'n verouderde tonnel te bly hang. Wanneer Tor terugkeer, moet die hek eers ná die stroombaangebeurtenis oopgaan, nie ná die prosesbegin nie. Teken aan watter voorwaarde by elke mislukking ontbreek het, en die volgende persoon op diens sal nie die volgorde uit tydstempels hoef te rekonstrueer nie.