Tor valmis enne VPN-i: käivitusvärava õige järjekord

tor-protsessi jälgimine ja seejärel VPN-i käivitamine on kõige tavalisem viis selle virna vigaselt ehitamiseks. Deemon ilmub kaua enne, kui suudab edastada kliendi voogu, ja fikseeritud paus on sõltuvuseks maskeeritud oletus. Värav peab olema olek, mida järgmine komponent tegelikult vajab. Käige alljärgnevad neli sammu järjekorras läbi ja käsitlege igaüht eraldi tingimusena, mitte häälestatava viivitusena.

Samm 1: valige transport, mis teil tegelikult on

Alustage protokollist, sest ülejäänud kujundus sõltub sellest. Tori SOCKS-liides ei rakenda UDP ASSOCIATE'i, seega kõik, mida selle kaudu edastatakse, peab olema TCP voog. UDP-d kasutav OpenVPN profiil ei tööta sellel teel, ükskõik kuidas superviisor on kirjutatud. Lülitage profiil TCP-le ja kinnitage, et kaugpartner võtab selle vastu, enne kui puudutate käivitusloogikat.

Seejärel kinnitage, et teie klient suudab üldse SOCKS-proksini jõuda. OpenVPN 2.6 dokumenteerib TCP-profiilide jaoks valikut socks-proxy, ja erinevad kliendid pakuvad erinevat proksi tuge. Käivitaja, mis vaikselt eirab proksi valikut, ühendub otse ja näib töötavat, mis on hullem kui ebaõnnestumine.

Kirjutage valitud transport runbooki, sest iga hilisem kontroll sõltub sellest.

Samm 2: lugege bootstrap-faasi, mitte protsesside loendit

Tori juhtprotokoll vastab GETINFO status/bootstrap-phase päringule kõige värskema bootstrap-olekuga, sealhulgas edenemise protsent ja kokkuvõtte silt. See vastus on kasulik just seetõttu, et kontroller võib ühenduda pärast seda, kui deemon on bootstrapi juba lõpetanud. Superviisor, mis kuulab ainult sündmusi, jätab vahele juhtumi, kus Tor oli valmis enne superviisori käivitumist.

Autentige juhtühendus korralikult. Juhtport on haldusliides ja igaüks, kes sellega rääkida saab, võib deemonit ümber seadistada. Hoidke see localhostil, hoidke küpsise- või parooliautentimine sisse lülitatud ja ärge eemaldage kumbagi, et käivituskripti lihtsamaks teha.

Lugege faasi üks kord käivitamisel ja tellige seejärel edenemissündmused reaalvaate jaoks.

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

Vastus edenemisega 100 ja sildiga done tähendab, et deemon lõpetas oma käivituse. See ei tähenda veel, et teie sihtkohani oleks kasutatav ahel.

Samm 3: oodake kliendi ahela sündmust

Tori sündmusprotokoll määratleb CIRCUIT_ESTABLISHED, mis teatab, et kliendil on ahel, mida ta saab kasutada. See on valmidussignaal, mida kandjavärav tahab, sest see on lähemal vajalikule võimele kui protsent. Tellige sündmus ja registreerige üleminek, et logi näitaks, millal kandja muutus kasutatavaks, mitte millal protsess ilmus.

Käsitlege sündmust lubana proovida, mitte garantiina ühegi konkreetse sihtkoha kohta. Väljumispoliitika võib kaugpartneri ikkagi tagasi lükata ja VPN-i enda käepigistus võib ikkagi nurjuda põhjustel, millel pole Toriga mingit seost.

Hoidke kaks tingimust koodis eraldi. Üks tõeväärtus nimega ready ühendab need ja muudab järgmise juhtumi loetamatuks.

Samm 4: tõstke VPN-i värav selle enda käepigistusele

VPN-il on oma valmidustingimus ja ainult see tõestab, et tunnel tõusis. Oodake, kuni klient teatab ühendatud olekust koos määratud aadressiga, seejärel kontrollige, et proksi nõue jäi kehtima. Uuesti proovimise tsükkel, mis ühe ebaõnnestumise järel loobub valikust socks-proxy, ühendub otse ja nurjab vaikselt kogu kujunduse.

Otsustage, mis juhtub siis, kui partner pole kättesaadav, enne kui peate seda teadma. Piiratud korduskatse nähtava ebaõnnestumisega on lihtsam käitada kui lõputu tsükkel ja annab jälgimissüsteemile midagi, mille peale häiret anda. Sama otsus kehtib kandja kohta: kui Tor taaskäivitub, tuleb VPN maha võtta ja uuesti väravast läbi lasta, mitte jätta surnud ahela peale tööle.

Lõpuks hoidke rakenduse enda poliitika jõus, kui VPN on maas. Korrektselt ootav superviisor ei tee midagi, et takistada mitteseotud protsessil liiklust otse saata.

Kontrollige nelja üleminekut, mille peate üle elama

Neli juhtumit katavad kujunduse: külmkäivitus, kus Tor tuleb esimesena üles, superviisor, mis haakub juba valmis Toriga, kättesaamatu VPN-i partner ja kandja kadu, kui tunnel on üleval. Igal neist on erinev oodatav üleminek ja igaüks tekitab erineva logirea, kui värav on korralikult kirjutatud.

Käivitage neid meelega, ükshaaval, ja lugege olekumuutusi, mitte protsesside loendit.

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

Kui kandja langeb, peaks VPN sellega kaasa langema ühe korduskatse intervalli jooksul, mitte jääma vananenud tunneliga rippuma. Kui Tor naaseb, peaks värav uuesti avanema alles pärast ahela sündmust, mitte pärast protsessi käivitumist. Logige, milline tingimus igal ebaõnnestumisel puudus, ja järgmine valves olev inimene ei pea järjekorda ajatemplitest taastama.