Tor handa bago ang VPN: ayusin nang tama ang gate ng pagsisimula

Ang pagmamasid sa isang prosesong tor at pagkatapos ay pagsisimula ng VPN ang pinakakaraniwang paraan ng maling pagbuo ng stack na ito. Lumilitaw ang daemon nang matagal bago ito makapagdala ng stream ng kliyente, at ang nakapirming paghihintay ay isang haka-haka na nakabihis bilang dependency. Ang gate ay dapat ang estado na talagang kailangan ng susunod na bahagi. Dumaan sa apat na hakbang sa ibaba nang sunod-sunod, at ituring ang bawat isa bilang hiwalay na kondisyon sa halip na isang pagkaantala na aayusin.

Hakbang 1: piliin ang transportasyong mayroon ka talaga

Magsimula sa protocol, dahil nakadepende rito ang natitirang disenyo. Ang SOCKS interface ng Tor ay hindi nagpapatupad ng UDP ASSOCIATE, kaya anumang dinadala sa pamamagitan nito ay dapat na stream ng TCP. Ang isang profile ng OpenVPN na gumagamit ng UDP ay hindi gagana sa rutang ito, gaano man isinulat ang superbisor. Ilipat ang profile sa TCP at tiyakin na tinatanggap ito ng malayong kapares bago mo hawakan ang lohika ng pagsisimula.

Pagkatapos ay tiyakin na ang iyong kliyente ay nakakaabot talaga sa isang proxy ng SOCKS. Ang OpenVPN 2.6 ay nagdodokumento ng opsiyon na socks-proxy para sa mga profile ng TCP, at iba't ibang kliyente ang nag-aalok ng iba't ibang suporta sa proxy. Ang isang launcher na tahimik na binabalewala ang opsiyon ng proxy ay kokonekta nang direkta at magmumukhang gumagana, na mas masama kaysa sa mabigo.

Isulat ang piniling transportasyon sa runbook, dahil nakadepende rito ang bawat susunod na pagsusuri.

Hakbang 2: basahin ang yugto ng bootstrap, hindi ang listahan ng proseso

Sinasagot ng control protocol ng Tor ang GETINFO status/bootstrap-phase ng pinakabagong estado ng bootstrap, kasama ang porsyento ng pag-usad at isang tag ng buod. Kapaki-pakinabang ang sagot na iyon dahil maaaring kumonekta ang isang controller pagkatapos nang matapos ng daemon ang bootstrap. Ang isang superbisor na nakikinig lamang sa mga pangyayari ay makakaligtaan ang kaso kung saan handa na ang Tor bago pa nagsimula ang superbisor.

Ipatotoo nang maayos ang koneksyon ng kontrol. Ang port ng kontrol ay isang administratibong interface, at sinumang makakausap nito ay maaaring muling i-configure ang daemon. Panatilihin ito sa localhost, panatilihing naka-enable ang pagpapatotoo sa cookie o password, at huwag alisin ang alinman sa dalawa para gawing mas simple ang isang startup script.

Basahin ang yugto nang isang beses sa pagsisimula, pagkatapos ay mag-subscribe sa mga pangyayari ng pag-usad para sa live na view.

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

Ang sagot na may pag-usad 100 at tag na done ay nangangahulugang natapos ng daemon ang sarili nitong pagsisimula. Hindi pa nito ibig sabihin na may magagamit na circuit patungo sa iyong destinasyon.

Hakbang 3: hintayin ang pangyayari ng circuit ng kliyente

Tinutukoy ng protocol ng pangyayari ng Tor ang CIRCUIT_ESTABLISHED, na nag-uulat na ang kliyente ay may circuit na magagamit nito. Iyon ang senyales ng kahandaan na hinahanap ng isang gate ng carrier, dahil mas malapit ito sa kakayahang kailangan mo kaysa sa isang porsyento. Mag-subscribe sa pangyayari at itala ang paglipat, upang ipakita ng log kung kailan naging magagamit ang carrier at hindi kung kailan lumitaw ang proseso.

Ituring ang pangyayari bilang pahintulot na subukan, hindi bilang garantiya tungkol sa isang partikular na destinasyon. Maaari pa ring tanggihan ng patakaran ng labasan ang malayong kapares, at maaari pa ring mabigo ang handshake ng VPN mismo dahil sa mga dahilan na walang kinalaman sa Tor.

Panatilihing hiwalay ang dalawang kondisyon sa code. Ang isang boolean na pinangalanang ready ay pagsasamahin ang mga ito at gagawing hindi mabasa ang susunod na insidente.

Hakbang 4: i-gate ang VPN sa sarili nitong handshake

Ang VPN ay may sariling kondisyon ng kahandaan, at iyon lamang ang nagpapatunay na umakyat ang tunnel. Hintayin na iulat ng kliyente ang konektadong estado na may nakatalagang address, pagkatapos ay suriin na nanatiling may bisa ang pangangailangan sa proxy. Ang isang loop ng muling pagtatangka na nagtatapon ng opsiyon na socks-proxy pagkatapos ng isang pagkabigo ay kokonekta nang direkta at tahimik na talunin ang buong disenyo.

Magpasya kung ano ang mangyayari kapag hindi maabot ang kapares bago mo kailangang malaman ito. Ang limitadong muling pagtatangka na may nakikitang pagkabigo ay mas madaling patakbuhin kaysa sa isang walang katapusang loop, at nagbibigay ito sa sistema ng pagsubaybay ng isang bagay na maaaring alertuhan. Ang parehong desisyon ay nalalapat sa carrier: kung mag-restart ang Tor, kailangang buwagin ang VPN at i-gate muli sa halip na iwan itong tumatakbo sa isang patay na circuit.

Sa huli, panatilihin ang sariling patakaran ng aplikasyon habang sira ang VPN. Ang isang superbisor na naghihintay nang tama ay walang ginagawa para pigilan ang isang walang kaugnayang proseso na magpadala ng trapiko nang direkta.

Suriin ang apat na paglipat na dapat mong malampasan

Apat na kaso ang sumasaklaw sa disenyo: isang malamig na pagsisimula kung saan unang umaakyat ang Tor, isang superbisor na kumokonekta sa isang Tor na handa na, isang hindi magagamit na kapares ng VPN, at pagkawala ng carrier habang nakataas ang tunnel. Bawat isa ay may ibang inaasahang paglipat, at bawat isa ay gumagawa ng ibang linya ng log kung ang gate ay wastong naisulat.

Patakbuhin ang mga ito nang sinasadya, isa-isa, at basahin ang mga pagbabago ng estado sa halip na ang listahan ng proseso.

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

Kapag bumagsak ang carrier, dapat sumunod pababa ang VPN sa loob ng isang pagitan ng muling pagtatangka sa halip na manatiling nakabitin sa isang lumang tunnel. Kapag bumalik ang Tor, dapat muling bumukas ang gate pagkatapos lamang ng pangyayari ng circuit, hindi pagkatapos ng pagsisimula ng proseso. Itala kung aling kondisyon ang kulang sa bawat pagkabigo, at ang susunod na taong naka-duty ay hindi na kailangang buuin muli ang pagkakasunod-sunod mula sa mga timestamp.