Tor spreman prije VPN-a: pravilan redoslijed startne kapije

Praćenje tor procesa i zatim pokretanje VPN-a najčešći je način da se ovaj stack izgradi pogrešno. Demon se pojavljuje mnogo prije nego što može prenositi klijentski tok, a fiksna pauza je nagađanje obučeno u zavisnost. Kapija mora biti stanje koje sljedeća komponenta stvarno treba. Prođite kroz četiri koraka ispod redom i tretirajte svaki od njih kao zaseban uslov, a ne kao odgodu koju treba podesiti.

Korak 1: izaberite transport koji stvarno imate

Počnite od protokola, jer ostatak dizajna zavisi od njega. SOCKS interfejs u Toru ne implementira UDP ASSOCIATE, pa sve što se prenosi preko njega mora biti TCP tok. OpenVPN profil koji koristi UDP neće raditi kroz ovu putanju bez obzira na to kako je supervizor napisan. Prebacite profil na TCP i potvrdite da ga udaljeni peer prihvata prije nego što dirnete logiku pokretanja.

Zatim potvrdite da vaš klijent uopšte može doći do SOCKS proxyja. OpenVPN 2.6 dokumentuje opciju socks-proxy za TCP profile, a različiti klijenti nude različitu podršku za proxy. Pokretač koji tiho ignoriše proxy opciju spojit će se direktno i izgledati kao da radi, što je gore od neuspjeha.

Zapišite izabrani transport u runbook, jer svaka kasnija provjera zavisi od njega.

Korak 2: čitajte bootstrap fazu, a ne listu procesa

Tor kontrolni protokol odgovara na GETINFO status/bootstrap-phase najnovijim bootstrap stanjem, uključujući procenat napretka i sažeti tag. Taj odgovor je koristan upravo zato što se kontroler može povezati nakon što je demon već završio bootstrap. Supervizor koji sluša samo događaje propustit će slučaj kada je Tor bio spreman prije nego što je supervizor počeo.

Autentificirajte kontrolnu vezu kako treba. Kontrolni port je administrativni interfejs i svako ko može razgovarati s njim može rekonfigurisati demon. Držite ga na localhostu, držite autentifikaciju kolačićem ili lozinkom uključenom i ne uklanjajte nijednu od njih da biste pojednostavili startnu skriptu.

Pročitajte fazu jednom pri pokretanju, a zatim se pretplatite na događaje napretka za prikaz už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 s napretkom 100 i tagom done znači da je demon završio vlastito pokretanje. To još ne znači da postoji upotrebljivo kolo do vašeg odredišta.

Korak 3: čekajte događaj klijentskog kola

Tor protokol događaja definiše CIRCUIT_ESTABLISHED, koji javlja da klijent ima kolo koje može koristiti. To je signal spremnosti koji kapija nosača želi, jer je bliži sposobnosti koja vam treba nego procenat. Pretplatite se na događaj i zabilježite prelaz, tako da dnevnik pokaže kada je nosač postao upotrebljiv, a ne kada se proces pojavio.

Tretirajte događaj kao dozvolu za pokušaj, a ne kao garanciju za bilo koje konkretno odredište. Izlazna politika i dalje može odbiti udaljeni peer, a rukovanje samog VPN-a i dalje može propasti iz razloga koji nemaju veze s Torom.

Držite dva uslova odvojeno u kodu. Jedna logička vrijednost nazvana ready spojit će ih i učiniti sljedeći incident nečitljivim.

Korak 4: vežite VPN na njegovo vlastito rukovanje

VPN ima svoj uslov spremnosti i to je jedini koji dokazuje da je tunel podignut. Čekajte da klijent prijavi povezano stanje s dodijeljenom adresom, a zatim provjerite da je zahtjev za proxy ostao na snazi. Petlja ponovnog pokušaja koja nakon jednog neuspjeha odbaci opciju socks-proxy spojit će se direktno i tiho uništiti cijeli dizajn.

Odlucite šta se dešava kada peer nije dostupan prije nego što to budete morali znati. Ograničeno ponavljanje s vidljivim neuspjehom lakše je za rad od beskonačne petlje i daje sistemu za nadzor nešto na šta može upozoriti. Ista odluka važi i za nosač: ako se Tor ponovo pokrene, VPN se mora srušiti i ponovo vezati, a ne ostaviti da radi na mrtvom kolu.

Konačno, držite vlastitu politiku aplikacije na mjestu dok je VPN neaktivan. Supervizor koji ispravno čeka ne čini ništa da spriječi nepovezani proces da šalje saobraćaj direktno.

Provjerite četiri prelaza koje morate preživjeti

Četiri slučaja pokrivaju dizajn: hladan start u kojem Tor nastaje prvi, supervizor koji se priključuje već spremnom Toru, nedostupan VPN peer i gubitak nosača dok je tunel podignut. Svaki ima drugačiji očekivani prelaz i svaki proizvodi drugačiju liniju dnevnika ako je kapija ispravno napisana.

Pokrenite ih namjerno, jedan po jedan, i čitajte promjene stanja, a ne listu procesa.

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

Kada nosač padne, VPN bi trebao sići za njim u roku od jednog intervala ponovnog pokušaja, umjesto da ostane s bajatim tunelom. Kada se Tor vrati, kapija bi se trebala ponovo otvoriti samo nakon događaja kola, a ne nakon pokretanja procesa. Zabilježite koji je uslov nedostajao pri svakom neuspjehu i sljedeća osoba na dužnosti neće morati rekonstruisati redoslijed iz vremenskih oznaka.