Tor pripravený pred VPN: správne poradie štartovacej brány

Sledovať proces tor a potom spustiť VPN je najčastejší spôsob, ako tento stack postaviť nesprávne. Démon sa objaví dávno predtým, než dokáže prenášať klientsky tok, a pevná pauza je odhad oblečený ako závislosť. Brána musí byť stav, ktorý nasledujúca komponenta naozaj potrebuje. Prejdite štyri kroky nižšie v poradí a každý berte ako samostatnú podmienku, nie ako oneskorenie na doladenie.

Krok 1: vyberte prenos, ktorý skutočne máte

Začnite protokolom, pretože zvyšok návrhu od neho závisí. Rozhranie SOCKS v Tore neimplementuje UDP ASSOCIATE, takže čokoľvek sa cez neho prenáša, musí byť prúd TCP. Profil OpenVPN, ktorý používa UDP, touto cestou nebude fungovať, nech je supervízor napísaný akokoľvek. Prepnite profil na TCP a potvrďte, že vzdialený partner ho prijíma, skôr než sa dotknete spúšťacej logiky.

Potom potvrďte, že váš klient sa vôbec dostane k proxy SOCKS. OpenVPN 2.6 dokumentuje voľbu socks-proxy pre profily TCP a rôzni klienti ponúkajú rôznu podporu proxy. Spúšťač, ktorý voľbu proxy ticho ignoruje, sa pripojí priamo a bude vyzerať, že funguje, čo je horšie ako zlyhanie.

Zapíšte zvolený prenos do runbooku, pretože každá ďalšia kontrola od neho závisí.

Krok 2: čítajte fázu bootstrap, nie zoznam procesov

Kontrolný protokol Toru odpovedá na GETINFO status/bootstrap-phase najnovším stavom bootstrap, vrátane percenta pokroku a súhrnnej značky. Tá odpoveď je užitočná práve preto, že kontrolér sa môže pripojiť až po tom, čo démon už bootstrap dokončil. Supervízor, ktorý počúva len udalosti, prehliadne prípad, keď bol Tor pripravený ešte pred štartom supervízora.

Overte kontrolné pripojenie správne. Kontrolný port je administratívne rozhranie a ktokoľvek s ním môže hovoriť, môže prekonfigurovať démona. Držte ho na localhoste, nechajte zapnuté overovanie cookie alebo heslom a neodstraňujte ani jedno z nich, aby bol spúšťací skript jednoduchší.

Prečítajte fázu raz pri štarte a potom sa prihláste na odber udalostí pokroku pre živý pohľad.

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

Odpoveď s pokrokom 100 a značkou done znamená, že démon dokončil vlastný štart. Zatiaľ to neznamená, že k vášmu cieľu existuje použiteľný okruh.

Krok 3: čakajte na udalosť klientskeho okruhu

Protokol udalostí Toru definuje CIRCUIT_ESTABLISHED, ktorý hlási, že klient má okruh, ktorý môže použiť. To je signál pripravenosti, ktorý brána nosiča chce, pretože je bližšie k schopnosti, ktorú potrebujete, než percento. Prihláste sa na odber udalosti a zaznamenajte prechod, aby protokol ukazoval, kedy sa nosič stal použiteľným, a nie kedy sa objavil proces.

Berte udalosť ako povolenie skúsiť, nie ako záruku pre konkrétny cieľ. Výstupná politika môže vzdialeného partnera stále odmietnuť a handshake samotnej VPN môže stále zlyhať z dôvodov, ktoré s Torom nemajú nič spoločné.

Držte obe podmienky v kóde oddelene. Jediný boolean s názvom ready ich zleje a urobí ďalší incident nečitateľným.

Krok 4: zaveste VPN na jej vlastný handshake

VPN má vlastnú podmienku pripravenosti a iba tá dokazuje, že tunel vznikol. Počkajte, kým klient ohlási pripojený stav s pridelenou adresou, a potom skontrolujte, či požiadavka na proxy zostala v platnosti. Slučka opakovania, ktorá po jednom zlyhaní zahodí voľbu socks-proxy, sa pripojí priamo a ticho zničí celý návrh.

Rozhodnite, čo sa stane, keď je partner nedostupný, skôr než to budete potrebovať vedieť. Obmedzené opakovanie s viditeľným zlyhaním sa prevádzkuje ľahšie než nekonečná slučka a dáva monitorovaciemu systému niečo, na čo môže upozorniť. To isté rozhodnutie platí pre nosič: ak sa Tor restartuje, VPN treba strhnúť a znova zavesiť, nie nechať bežať na mŕtvom okruhu.

Nakoniec držte vlastnú politiku aplikácie na mieste, kým je VPN dole. Supervízor, ktorý čaká správne, nič nerobí, aby zabránil nesúvisiacemu procesu posielať prevádzku priamo.

Skontrolujte štyri prechody, ktoré musíte prežiť

Štyri prípady pokrývajú návrh: studený štart, keď Tor nastúpi prvý, supervízor, ktorý sa pripojí k už pripravenému Toru, nedostupný partner VPN a strata nosiča, keď je tunel hore. Každý má iný očakávaný prechod a každý vytvorí iný riadok protokolu, ak je brána napísaná správne.

Spúšťajte ich zámerne, jeden po druhom, a čítajte zmeny stavu, nie zoznam procesov.

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

Keď nosič padne, VPN má za ním klesnúť v priebehu jedného intervalu opakovania, namiesto toho, aby zostala so zastaraným tunelom. Keď sa Tor vráti, brána sa má znova otvoriť až po udalosti okruhu, nie po štarte procesu. Zaznamenajte, ktorá podmienka pri každom zlyhaní chýbala, a ďalší službukonajúci nebude musieť rekonštruovať poradie z časových značiek.