Tor готов до VPN: правильный порядок стартового шлюза

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

Похожие статьи