Tor pasirengęs prieš VPN: teisinga paleidimo vartų tvarka

Stebėti tor procesą ir tada paleisti VPN – tai dažniausias būdas neteisingai sukurti šį rinkinį. Demonas pasirodo gerokai anksčiau, nei gali pernešti kliento srautą, o fiksuota pauzė yra priklausomybe apvilktas spėjimas. Vartai turi būti būsena, kurios iš tikrųjų reikia kitam komponentui. Pereikite keturis žingsnius žemiau iš eilės ir kiekvieną traktuokite kaip atskirą sąlygą, o ne kaip derinamą delsą.

1 žingsnis: pasirinkite transportą, kurį iš tikrųjų turite

Pradėkite nuo protokolo, nes likusi dizaino dalis nuo jo priklauso. Tor SOCKS sąsaja neįgyvendina UDP ASSOCIATE, todėl viskas, kas per ją perduodama, turi būti TCP srautas. OpenVPN profilis, naudojantis UDP, šiuo keliu neveiks, kad ir kaip būtų parašytas supervizorius. Perjunkite profilį į TCP ir prieš liesdami paleidimo logiką patvirtinkite, kad nuotolinis partneris jį priima.

Tada patvirtinkite, kad jūsų klientas apskritai pasiekia SOCKS tarpinį serverį. OpenVPN 2.6 dokumentuoja socks-proxy parinktį TCP profiliams, o skirtingi klientai siūlo skirtingą tarpinio serverio palaikymą. Paleidiklis, kuris tyliai nepaiso tarpinio serverio parinkties, prisijungs tiesiogiai ir atrodys veikiantis, o tai blogiau nei nepavykti.

Užrašykite pasirinktą transportą į runbook, nes kiekvienas vėlesnis patikrinimas nuo jo priklauso.

2 žingsnis: skaitykite bootstrap fazę, o ne procesų sąrašą

Tor valdymo protokolas į GETINFO status/bootstrap-phase atsako naujausia bootstrap būsena, įskaitant progreso procentą ir suvestinės žymą. Tas atsakymas naudingas būtent todėl, kad valdiklis gali prisijungti po to, kai demonas jau baigė bootstrap. Supervizorius, kuris klausosi tik įvykių, praleis atvejį, kai Tor jau buvo pasiruošęs prieš supervizoriaus paleidimą.

Tinkamai autentifikuokite valdymo ryšį. Valdymo prievadas yra administracinė sąsaja, ir kiekvienas, galintis su juo kalbėtis, gali perkonfigūruoti demoną. Laikykite jį localhost adresu, palikite įjungtą autentifikavimą slapuku arba slaptažodžiu ir nepašalinkite nė vieno jų, kad supaprastintumėte paleidimo scenarijų.

Perskaitykite fazę vieną kartą paleidimo metu, tada užsiprenumeruokite progreso įvykius tiesioginei peržiūrai.

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

Atsakymas su 100 progresu ir žyma done reiškia, kad demonas baigė savo paleidimą. Tai dar nereiškia, kad jūsų tikslui egzistuoja naudojama grandinė.

3 žingsnis: laukite kliento grandinės įvykio

Tor įvykių protokolas apibrėžia CIRCUIT_ESTABLISHED, kuris praneša, kad klientas turi grandinę, kurią gali naudoti. Tai pasirengimo signalas, kurio nori nešėjo vartai, nes jis arčiau reikalingo pajėgumo nei procentas. Užsiprenumeruokite įvykį ir užrašykite perėjimą, kad žurnalas rodytų, kada nešėjas tapo naudingas, o ne kada pasirodė procesas.

Traktuokite įvykį kaip leidimą bandyti, o ne kaip garantiją dėl konkrečios paskirties. Išėjimo politika vis tiek gali atmesti nuotolinį partnerį, o pačios VPN rankos paspaudimas vis tiek gali nepavykti dėl priežasčių, neturinčių nieko bendro su Tor.

Laikykite abi sąlygas kode atskirai. Vienas loginis kintamasis pavadinimu ready jas sujungs ir padarys kitą incidentą neįskaitomą.

4 žingsnis: užveskite VPN ant jos pačios rankos paspaudimo

VPN turi savo pasirengimo sąlygą, ir tik ji įrodo, kad tunelis pakilo. Laukite, kol klientas praneš apie prisijungusią būseną su priskirtu adresu, tada patikrinkite, ar tarpinio serverio reikalavimas liko galioti. Bandymų kartoti ciklas, kuris po vienos nesėkmės atsisako socks-proxy parinkties, prisijungs tiesiogiai ir tyliai sužlugdys visą dizainą.

Nuspręskite, kas atsitiks, kai partneris nepasiekiamas, anksčiau, nei jums to prireiks žinoti. Apribotas kartojimas su matoma nesėkme yra lengviau valdomas nei begalinis ciklas, ir jis duoda stebėjimo sistemai, dėl ko aliarmuoti. Tas pats sprendimas galioja nešėjui: jei Tor paleidžiamas iš naujo, VPN reikia išardyti ir vėl užvesti ant vartų, o ne palikti veikti negyvoje grandinėje.

Galiausiai palaikykite pačios programos politiką, kol VPN yra išjungta. Teisingai laukiantis supervizorius nieko nedaro, kad nesustabdytų nesusijusio proceso nuo tiesioginio srauto siuntimo.

Patikrinkite keturis perėjimus, kuriuos turite išgyventi

Keturi atvejai apima dizainą: šaltas paleidimas, kai Tor pakyla pirmas, supervizorius, prisijungiantis prie jau pasiruošusio Tor, nepasiekiamas VPN partneris ir nešėjo praradimas, kai tunelis pakilęs. Kiekvienas turi skirtingą tikėtiną perėjimą, ir kiekvienas sukuria skirtingą žurnalo eilutę, jei vartai parašyti teisingai.

Vykdykite juos sąmoningai, po vieną, ir skaitykite būsenos pokyčius, o ne procesų sąrašą.

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

Kai nešėjas krinta, VPN turėtų nusileisti paskui jį per vieną kartojimo intervalą, o ne likti su pasenusiu tuneliu. Kai Tor grįžta, vartai turėtų atsiverti tik po grandinės įvykio, o ne po proceso paleidimo. Užrašykite, kokios sąlygos trūko kiekvienos nesėkmės metu, ir kitas budintis asmuo neturės atkurti tvarkos iš laiko žymų.