tor процесін бақылап, содан кейін VPN-ді іске қосу — бұл стекті дұрыс емес құрудың ең көп тараған жолы. Демон клиент ағынын тасымалдай алуынан әлдеқайда бұрын пайда болады, ал қозғалмайтын кідіріс тәуелділікке оралған болжам. Қақпа келесі құрамдасқа шынымен қажет күй болуы керек. Төмендегі төрт қадамды тәртіппен өтіп, әрқайсысын реттелетін кідіріс емес, жеке шарт ретінде қарастырыңыз.

1-қадам: шын мәнінде бар тасымалды таңдаңыз

Протоколдан бастаңыз, өйткені дизайнның қалған бөлігі соған тәуелді. Tor-дың SOCKS интерфейсі UDP ASSOCIATE мүмкіндігін жүзеге асырмайды, сондықтан ол арқылы тасымалданатынның бәрі TCP ағыны болуы керек. UDP қолданатын OpenVPN профилі бұл жолмен жұмыс істемейді, қадағалаушы қалай жазылса да. Профильді TCP-ге ауыстырып, қосу логикасына тиіспей тұрып, қашықтағы теңдестің оны қабылдайтынын растаңыз.

Содан кейін клиентіңіздің жалпы SOCKS проксиге жете алатынын растаңыз. OpenVPN 2.6 TCP профильдері үшін socks-proxy опциясын құжаттайды, ал түрлі клиенттер проксиді түрліше қолдайды. Прокси опциясын үнсіз елемейтін іске қосқыш тікелей қосылып, жұмыс істеп тұрғандай көрінеді, бұл сәтсіздіктен де нашар.

Таңдалған тасымалды runbook-қа жазыңыз, өйткені кейінгі әрбір тексеріс соған тәуелді.

2-қадам: bootstrap фазасын оқыңыз, процестер тізімін емес

Tor-дың басқару протоколы GETINFO status/bootstrap-phase сұрағына ең соңғы bootstrap күйімен жауап береді, оның ішінде прогресс пайызы мен қорытынды тегі бар. Бұл жауап дәл сол себепті пайдалы: контроллер демон bootstrap-ты әлдеқашан бітіргеннен кейін қосыла алады. Тек оқиғаларды тыңдайтын қадағалаушы Tor қадағалаушы басталмай тұрып дайын болған жағдайды өткізіп алады.

Басқару қосылымын дұрыс аутентификациялаңыз. Басқару порты әкімшілік интерфейс, және онымен сөйлесе алатын кез келген адам демонды қайта конфигурациялай алады. Оны localhost-та ұстаңыз, cookie немесе құпиясөзбен аутентификацияны қосулы ұстаңыз және іске қосу скриптін қарапайым ету үшін екеуінің ешқайсысын жоймаңыз.

Фазаны іске қосу кезінде бір рет оқыңыз, содан кейін тікелей көрініс үшін прогресс оқиғаларына жазылыңыз.

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

Прогресі 100 және done тегі бар жауап демонның өз іске қосылуын аяқтағанын білдіреді. Бұл әзірге сіздің межелі орныңызға пайдалануға болатын тізбек бар дегенді білдірмейді.

3-қадам: клиент тізбегінің оқиғасын күтіңіз

Tor оқиғалар протоколы CIRCUIT_ESTABLISHED оқиғасын анықтайды, ол клиенттің пайдалана алатын тізбегі бар екенін хабарлайды. Бұл тасымалдаушы қақпасы қалайтын дайындық сигналы, өйткені ол қажетті мүмкіндікке пайызға қарағанда әлдеқайда жақын. Оқиғаға жазылып, ауысуды жазып алыңыз, сонда журнал тасымалдаушының қашан пайдалы болғанын көрсетеді, процестің қашан пайда болғанын емес.

Оқиғаны сынап көруге рұқсат ретінде қарастырыңыз, белгілі бір межелі орын туралы кепілдік ретінде емес. Шығу саясаты қашықтағы теңдесті әлі де қабылдамауы мүмкін, ал VPN-нің өз қол алысуы әлі де Tor-ға қатысы жоқ себептермен сәтсіз аяқталуы мүмкін.

Кодта екі шартты бөлек ұстаңыз. ready деп аталатын бір логикалық мән оларды біріктіріп, келесі оқиғаны оқылмайтын етеді.

4-қадам: VPN-ді өз қол алысуына қақпалаңыз

VPN-нің өз дайындық шарты бар және туннельдің көтерілгенін дәлелдейтін жалғыз сол. Клиент тағайындалған мекенжаймен қосылған күй туралы хабарлағанша күтіңіз, содан кейін прокси талабы күшінде қалғанын тексеріңіз. Бір сәтсіздіктен кейін socks-proxy опциясын тастайтын қайта әрекет циклі тікелей қосылып, бүкіл дизайнды үнсіз жеңеді.

Теңдес қолжетімсіз болғанда не болатынын білу қажеттігі туындамай тұрып шешіңіз. Көрінетін сәтсіздігі бар шектеулі қайта әрекет шексіз циклге қарағанда басқаруға оңай және мониторинг жүйесіне дабыл беретін нәрсе береді. Дәл осы шешім тасымалдаушыға да қатысты: егер Tor қайта іске қосылса, VPN-ді бұзып, қайта қақпалау керек, өлі тізбекте жұмыс істеуге қалдыруға болмайды.

Соңында, VPN өшірулі тұрғанда қолданбаның өз саясатын күшінде ұстаңыз. Дұрыс күтіп тұрған қадағалаушы байланыссыз процестің трафикті тікелей жіберуіне жол бермеу үшін ештеңе жасамайды.

Сіз өтуіңіз керек төрт ауысуды тексеріңіз

Төрт жағдай дизайнды қамтиды: Tor бірінші көтерілетін суық іске қосу, әлдеқашан дайын Tor-ға қосылатын қадағалаушы, қолжетімсіз VPN теңдесі және туннель көтеріліп тұрғанда тасымалдаушының жоғалуы. Әрқайсысының күтілетін ауысуы бөлек, және қақпа дұрыс жазылса, әрқайсысы бөлек журнал жолын жасайды.

Оларды әдейі, бір-бірлеп іске қосыңыз және процестер тізімін емес, күй өзгерістерін оқыңыз.

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

Тасымалдаушы құлағанда, VPN ескірген туннельмен ілініп қалмай, бір қайта әрекет аралығында онымен бірге төмен түсуі керек. Tor қайта оралғанда, қақпа процестің басталуынан кейін емес, тізбек оқиғасынан кейін ғана қайта ашылуы керек. Әр сәтсіздікте қандай шарт жетіспегенін жазыңыз, сонда келесі кезекші реттілікті уақыт белгілерінен қайта құруға мәжбүр болмайды.

Қатысты мақалалар