Tor гатовы да VPN: правільна парадкаваць шлюз запуску

Назіраць за працэсам tor, а потым запускаць VPN — гэта самы распаўсюджаны спосаб няправільна пабудаваць гэты стек. Дэман з'яўляецца задоўга да таго, як ён здольны пераносіць кліенцкі паток, а фіксаваная паўза — гэта здагадка, апранутая як залежнасць. Шлюзам павінен быць стан, які насамрэч патрэбны наступнаму кампаненту. Прайдзіце чатыры крокі ніжэй па парадку і разглядайце кожны з іх як асобную ўмову, а не як затрымку для наладкі.

Крок 1: выберыце транспарт, які вы насамрэч маеце

Пачніце з пратакола, бо астатняя частка дызайну залежыць ад яго. Інтэрфейс SOCKS у Tor не рэалізуе UDP ASSOCIATE, таму ўсё, што пераносіцца праз яго, павінна быць патокам TCP. Профіль OpenVPN, які выкарыстоўвае UDP, не будзе працаваць праз гэты шлях, як бы ні быў напісаны супервізар. Пераключыце профіль на TCP і пераканайцеся, што аддалены вузел яго прымае, перш чым кранаць логіку запуску.

Затым пераканайцеся, што ваш кліент наогул можа дасягнуць проксі SOCKS. OpenVPN 2.6 дакументуе опцыю socks-proxy для профіляў TCP, а розныя кліенты па-рознаму падтрымліваюць проксі. Лончар, які маўкліва ігнаруе опцыю проксі, злучыцца напрамую і будзе выглядаць працуючым, што горш за няўдачу.

Запішыце абраны транспарт у 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 вяртаецца, шлюз павінен адкрывацца толькі пасля падзеі ланцуга, а не пасля запуску працэсу. Запісвайце, якой умовы не хапала пры кожнай няўдачы, і наступнаму дзяжурнаму не давядзецца аднаўляць парадак з часовых метак.