Tor připraven před VPN: správné pořadí startovní brány

Běžící proces tor není přenašeč. Zavěste VPN na dokumentovaný signál připravenosti klienta, pak na jeho vlastní protějšek, a záložní cesty držte oddělené.

Sledování procesu tor a následné spuštění VPN je nejběžnější způsob, jak tento stack postavit špatně. Démon se objeví dlouho předtím, než dokáže přenášet klientský proud, a pevná pauza je odhad oblečený jako závislost. Brána musí být stav, který další komponenta skutečně potřebuje. Projděte čtyři kroky níže v pořadí a každý z nich berte jako samostatnou podmínku, nikoli jako prodlevu k vyladění.

Krok 1: vyberte přenos, který skutečně máte

Začněte protokolem, protože na něm závisí zbytek návrhu. Rozhraní SOCKS v Toru neimplementuje UDP ASSOCIATE, takže cokoli se přes něj přenáší, musí být proud TCP. Profil OpenVPN, který používá UDP, touto cestou nebude fungovat, ať je supervizor napsaný jakkoli. Přepněte profil na TCP a potvrďte, že jej vzdálený protějšek přijímá, než se dotknete startovní logiky.

Pak potvrďte, že se váš klient vůbec dostane k proxy SOCKS. OpenVPN 2.6 dokumentuje volbu socks-proxy pro profily TCP a různí klienti nabízejí různou podporu proxy. Spouštěč, který volbu proxy tiše ignoruje, se připojí přímo a bude vypadat, že funguje, což je horší než selhání.

Zapište zvolený přenos do runbooku, protože na něm závisí každá další kontrola.

Krok 2: čtěte fázi bootstrap, ne seznam procesů

Kontrolní protokol Toru odpovídá na GETINFO status/bootstrap-phase nejnovějším stavem bootstrap, včetně procenta pokroku a souhrnného štítku. Tato odpověď je užitečná právě proto, že kontroler se může připojit poté, co démon už bootstrap dokončil. Supervizor, který poslouchá jen události, přehlédne případ, kdy byl Tor připraven dřív, než supervizor začal.

Ověřte kontrolní připojení správně. Kontrolní port je administrativní rozhraní a kdokoli s ním může mluvit, může překonfigurovat démona. Držte jej na localhostu, nechte zapnuté ověřování cookie nebo heslem a neodstraňujte ani jedno z nich jen proto, aby byl startovní skript jednodušší.

Přečtěte fázi jednou při startu a poté se přihlaste k odběru událostí pokroku pro živý pohled.

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

Odpověď s pokrokem 100 a štítkem done znamená, že démon dokončil vlastní start. Zatím to neznamená, že k vašemu cíli existuje použitelný okruh.

Krok 3: čekejte na událost klientského okruhu

Protokol událostí Toru definuje CIRCUIT_ESTABLISHED, který hlásí, že klient má okruh, který může použít. To je signál připravenosti, který brána přenašeče chce, protože je blíž schopnosti, kterou potřebujete, než procento. Přihlaste se k odběru události a zaznamenejte přechod, aby protokol ukazoval, kdy se přenašeč stal použitelným, a ne kdy se objevil proces.

Berte událost jako svolení zkusit, ne jako záruku pro konkrétní cíl. Výstupní politika může vzdálený protějšek stále odmítnout a handshake samotné VPN může stále selhat z důvodů, které s Torem nemají nic společného.

Držte obě podmínky v kódu oddělené. Jediný boolean s názvem ready je slije a udělá příští incident nečitelným.

Krok 4: zavěste VPN na její vlastní handshake

VPN má svou vlastní podmínku připravenosti a jen ta dokazuje, že tunel vznikl. Počkejte, až klient ohlásí připojený stav s přidělenou adresou, a pak zkontrolujte, že požadavek na proxy zůstal v platnosti. Smyčka opakování, která po jednom selhání zahodí volbu socks-proxy, se připojí přímo a tiše zničí celý návrh.

Rozhodněte, co se stane, když je protějšek nedostupný, dřív než to budete potřebovat vědět. Omezené opakování s viditelným selháním se provozuje snáz než nekonečná smyčka a dává monitorovacímu systému něco, na co může upozornit. Stejné rozhodnutí platí pro přenašeč: pokud se Tor restartuje, VPN se musí strhnout a znovu zavěsit, ne zůstat běžet na mrtvém okruhu.

Nakonec držte vlastní politiku aplikace na místě, dokud je VPN dole. Supervizor, který správně čeká, neudělá nic, co by zabránilo nesouvisejícímu procesu posílat provoz přímo.

Zkontrolujte čtyři přechody, které musíte přežít

Čtyři případy pokrývají návrh: studený start, kdy Tor nastoupí první, supervizor, který se připojí k už připravenému Toru, nedostupný protějšek VPN a ztráta přenašeče, když je tunel nahoře. Každý má jiný očekávaný přechod a každý vytvoří jiný řádek protokolu, pokud je brána napsaná správně.

Spouštějte je záměrně, jeden po druhém, a čtěte změny stavu, ne seznam procesů.

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

Když přenašeč spadne, VPN má za ním klesnout během jednoho intervalu opakování, místo aby zůstala s prošlým tunelem. Když se Tor vrátí, brána se má znovu otevřít až po události okruhu, ne po startu procesu. Zaznamenejte, která podmínka při každém selhání chyběla, a příští službukonající nebude muset rekonstruovat pořadí z časových značek.

Související články