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

Схожі статті