Tor gatavs pirms VPN: pareiza palaišanas vārtu secība

Uzraudzīt tor procesu un pēc tam palaist VPN ir visizplatītākais veids, kā šo kopumu uzbūvēt nepareizi. Dēmons parādās ilgi pirms tam, kad spēj pārnest klienta plūsmu, un fiksēta gaidīšana ir atkarībā ietērpts minējums. Vārtiem jābūt stāvoklim, kas nākamajai komponentei patiešām vajadzīgs. Izstaigājiet četrus soļus zemāk pēc kārtas un izturieties pret katru kā pret atsevišķu nosacījumu, nevis kā pret regulējamu aizkavi.

1. solis: izvēlieties transportu, kas jums tiešām ir

Sāciet ar protokolu, jo pārējais dizains no tā ir atkarīgs. Tor SOCKS saskarne neievieš UDP ASSOCIATE, tāpēc visam, kas tiek pārnests caur to, jābūt TCP plūsmai. OpenVPN profils, kas izmanto UDP, šajā ceļā nedarbosies neatkarīgi no tā, kā uzrakstīts pārraugs. Pārslēdziet profilu uz TCP un pirms palaišanas loģikas aizskaršanas pārliecinieties, ka attālais partneris to pieņem.

Pēc tam pārliecinieties, ka jūsu klients vispār sasniedz SOCKS starpniekserveri. OpenVPN 2.6 dokumentē socks-proxy opciju TCP profiliem, un dažādi klienti piedāvā atšķirīgu starpniekservera atbalstu. Palaidējs, kas klusi ignorē starpniekservera opciju, savienojas tieši un izskatās strādājam, kas ir sliktāk nekā neizdošanās.

Pierakstiet izvēlēto transportu runbook, jo katra vēlākā pārbaude no tā ir atkarīga.

2. solis: lasiet bootstrap fāzi, nevis procesu sarakstu

Tor kontroles protokols uz GETINFO status/bootstrap-phase atbild ar jaunāko bootstrap stāvokli, tostarp progresa procentu un kopsavilkuma atzīmi. Šī atbilde ir noderīga tieši tāpēc, ka kontrolieris var pievienoties pēc tam, kad dēmons jau ir pabeidzis bootstrap. Pārraugs, kas klausās tikai notikumos, palaidīs garām gadījumu, kad Tor jau bija gatavs pirms pārrauga palaišanas.

Pareizi autentificējiet kontroles savienojumu. Kontroles ports ir administratīva saskarne, un ikviens, kas ar to var runāt, var pārkonfigurēt dēmonu. Turiet to localhost, turiet iespējotu autentifikāciju ar sīkfailu vai paroli un nenoņemiet nevienu no tiem, lai vienkāršotu palaišanas skriptu.

Izlasiet fāzi vienreiz palaišanas laikā, pēc tam abonējiet progresa notikumus tiešajam skatam.

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

Atbilde ar progresu 100 un atzīmi done nozīmē, ka dēmons ir pabeidzis savu palaišanu. Tas vēl nenozīmē, ka jūsu galamērķim pastāv izmantojams loks.

3. solis: gaidiet klienta loka notikumu

Tor notikumu protokols definē CIRCUIT_ESTABLISHED, kas ziņo, ka klientam ir loks, ko tas var izmantot. Tas ir gatavības signāls, ko vēlas nesēja vārti, jo tas ir tuvāk vajadzīgajai spējai nekā procents. Abonējiet notikumu un pierakstiet pāreju, lai žurnāls rādītu, kad nesējs kļuva izmantojams, nevis kad parādījās process.

Uztveriet notikumu kā atļauju mēģināt, nevis kā garantiju par konkrētu galamērķi. Izejas politika joprojām var atteikt attālo partneri, un paša VPN roku saprašanās joprojām var neizdoties tādu iemeslu dēļ, kuriem nav nekāda sakara ar Tor.

Turiet abus nosacījumus kodā atsevišķi. Viens Būla lielums ar nosaukumu ready tos apvienos un padarīs nākamo incidentu neizlasāmu.

4. solis: pieslēdziet VPN pie tā paša roku saprašanās

VPN ir savs gatavības nosacījums, un tikai tas pierāda, ka tunelis ir pacēlies. Gaidiet, līdz klients ziņo par savienotu stāvokli ar piešķirtu adresi, pēc tam pārbaudiet, vai starpniekservera prasība palika spēkā. Atkārtošanas cilpa, kas pēc vienas neizdošanās atmet socks-proxy opciju, savienosies tieši un klusi iznīcinās visu dizainu.

Izlemiet, kas notiek, kad partneris nav sasniedzams, pirms jums tas jāzina. Ierobežota atkārtošana ar redzamu neizdošanos ir vieglāk pārvaldāma nekā bezgalīga cilpa, un tā dod uzraudzības sistēmai kaut ko, par ko signalizēt. Tas pats lēmums attiecas uz nesēju: ja Tor tiek restartēts, VPN ir jānojauc un atkal jāpieslēdz pie vārtiem, nevis jāatstāj darboties mirušā lokā.

Visbeidzot, saglabājiet pašas lietotnes politiku, kamēr VPN ir izslēgts. Pārraugs, kas gaida pareizi, neko nedara, lai neļautu nesaistītam procesam sūtīt trafiku tieši.

Pārbaudiet četras pārejas, kas jums jāpārdzīvo

Četri gadījumi aptver dizainu: auksta palaišana, kad Tor paceļas pirmais, pārraugs, kas pievienojas jau gatavam Tor, nepieejams VPN partneris un nesēja zaudēšana, kamēr tunelis ir pacēlies. Katram ir atšķirīga gaidāmā pāreja, un katrs rada atšķirīgu žurnāla rindu, ja vārti ir uzrakstīti pareizi.

Palaidiet tos apzināti, pa vienam, un lasiet stāvokļa izmaiņas, nevis procesu sarakstu.

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

Kad nesējs krīt, VPN būtu jānokāpj tam līdzi vienā atkārtošanas intervālā, nevis jāpaliek ar novecojušu tuneli. Kad Tor atgriežas, vārtiem vajadzētu atvērties tikai pēc loka notikuma, nevis pēc procesa palaišanas. Pierakstiet, kura nosacījuma trūka katrā neizdošanās reizē, un nākamajai dežurējošajai personai nebūs jāatjauno secība no laika zīmogiem.