Tor pripravljen pred VPN: pravilen vrstni red zagonskih vrat

Opazovanje procesa tor in nato zagon VPN je najpogostejši način, kako ta sklad zgraditi narobe. Demon se pojavi veliko preden lahko prenaša odjemalski tok, fiksna pavza pa je ugibanje, oblečeno v odvisnost. Vrata morajo biti stanje, ki ga naslednja komponenta zares potrebuje. Pojdite skozi štiri korake spodaj po vrsti in vsakega obravnavajte kot ločen pogoj, ne kot zakasnitev, ki jo je treba nastaviti.

Korak 1: izberite transport, ki ga res imate

Začnite s protokolom, ker je preostanek zasnove odvisen od njega. Vmesnik SOCKS v Toru ne izvaja UDP ASSOCIATE, zato mora biti vse, kar se prenaša prek njega, tok TCP. Profil OpenVPN, ki uporablja UDP, po tej poti ne bo deloval, ne glede na to, kako je napisan nadzornik. Preklopite profil na TCP in potrdite, da ga oddaljeni partner sprejme, preden se dotaknete zagonske logike.

Nato potrdite, da vaš odjemalec sploh doseže proxy SOCKS. OpenVPN 2.6 dokumentira možnost socks-proxy za profile TCP, različni odjemalci pa ponujajo različno podporo proxy. Zaganjalnik, ki možnost proxy tiho prezre, se poveže neposredno in bo videti, da deluje, kar je slabše od neuspeha.

Zapišite izbrani transport v runbook, ker je vsako poznejše preverjanje odvisno od njega.

Korak 2: berite fazo bootstrap, ne seznama procesov

Krmilni protokol Tora odgovori na GETINFO status/bootstrap-phase z najnovejšim stanjem bootstrap, vključno z odstotkom napredka in zbirno oznako. Ta odgovor je koristen prav zato, ker se krmilnik lahko poveže po tem, ko je demon bootstrap že končal. Nadzornik, ki posluša samo dogodke, bo zgrešil primer, ko je bil Tor pripravljen pred zagonom nadzornika.

Pravilno overite krmilno povezavo. Krmilna vrata so administrativni vmesnik in vsakdo, ki se lahko pogovarja z njimi, lahko znova konfigurira demona. Držite jih na localhost, pustite overjanje s piškotkom ali geslom vključeno in ne odstranite nobenega od obeh, da bi poenostavili zagonsko skripto.

Preberite fazo enkrat ob zagonu, nato pa se naročite na dogodke napredka za pogled v živo.

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

Odgovor z napredkom 100 in oznako done pomeni, da je demon končal svoj zagon. To še ne pomeni, da do vašega cilja obstaja uporabno vezje.

Korak 3: počakajte na dogodek odjemalskega vezja

Protokol dogodkov Tora opredeljuje CIRCUIT_ESTABLISHED, ki sporoča, da ima odjemalec vezje, ki ga lahko uporabi. To je signal pripravljenosti, ki ga želi vrata nosilca, ker je bližje zmožnosti, ki jo potrebujete, kot odstotek. Naročite se na dogodek in zabeležite prehod, da bo dnevnik kazal, kdaj je nosilec postal uporaben, in ne kdaj se je pojavil proces.

Dogodek obravnavajte kot dovoljenje za poskus, ne kot jamstvo za določen cilj. Izhodna politika lahko še vedno zavrne oddaljenega partnerja, rokovanje same VPN pa lahko še vedno ne uspe iz razlogov, ki nimajo nobene zveze s Torom.

Oba pogoja držite v kodi ločeno. Ena sama logična vrednost z imenom ready ju bo združila in naredila naslednji incident neberljiv.

Korak 4: pripnite VPN na njegovo lastno rokovanje

VPN ima svoj pogoj pripravljenosti in samo ta dokazuje, da se je tunel dvignil. Počakajte, da odjemalec sporoči povezano stanje z dodeljenim naslovom, nato preverite, ali je zahteva po proxyju ostala v veljavi. Zanka ponovnih poskusov, ki po enem neuspehu opusti možnost socks-proxy, se bo povezala neposredno in tiho premagala celotno zasnovo.

Odločite, kaj se zgodi, ko partner ni dosegljiv, preden morate to vedeti. Omejeno ponavljanje z vidnim neuspehom je lažje upravljati kot neskončna zanka in nadzornemu sistemu daje nekaj, na kar lahko sproži alarm. Ista odločitev velja za nosilca: če se Tor znova zažene, je treba VPN razstaviti in znova pripeti, ne pa pustiti, da teče na mrtvem vezju.

Nazadnje, ohranite lastno politiko aplikacije, dokler je VPN izklopljen. Nadzornik, ki čaka pravilno, ne stori ničesar, da bi preprečil nepovezanemu procesu pošiljanje prometa neposredno.

Preverite štiri prehode, ki jih morate preživeti

Štirje primeri pokrivajo zasnovo: hladen zagon, ko Tor vstane prvi, nadzornik, ki se pripne na že pripravljen Tor, nedosegljiv partner VPN, in izguba nosilca, ko je tunel dvignjen. Vsak ima drugačen pričakovan prehod in vsak ustvari drugo vrstico dnevnika, če so vrata napisana pravilno.

Zaženite jih namerno, enega za drugim, in berite spremembe stanja, ne seznama procesov.

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

Ko nosilec pade, bi moral VPN za njim pasti v enem intervalu ponavljanja, namesto da bi ostal z zastarelim tunelom. Ko se Tor vrne, bi se vrata morala znova odpreti šele po dogodku vezja, ne po zagonu procesa. Zabeležite, kateri pogoj je pri vsakem neuspehu manjkal, in naslednji dežurni ne bo moral obnoviti vrstnega reda iz časovnih oznak.