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, држете ја автентикацијата со колаче или лозинка вклучена и не отстранувајте ниту една од двете за да поедноставите стартна скрипта.

Прочитајте ја фазата еднаш при стартување, потоа претплатете се на настаните за напредок за живиот приказ.

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 се враќа, портата треба повторно да се отвори само по настанот за коло, а не по стартувањето на процесот. Запишете кој услов недостасувал при секој неуспех, и следното лице на должност нема да мора да го реконструира редоследот од временски обележувачи.