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