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