Tor klar før VPN'en: den rigtige rækkefølge til opstartsporten

At holde øje med en tor-proces og derefter starte VPN'en er den mest almindelige måde at bygge denne stak forkert på. Daemonen dukker op længe før den kan bære en klientstrøm, og en fast pause er et gæt klædt ud som en afhængighed. Porten skal være den tilstand, den næste komponent faktisk har brug for. Gå gennem de fire trin nedenfor i rækkefølge, og behandl hvert af dem som en separat betingelse i stedet for en forsinkelse, der skal justeres.

Trin 1: vælg den transport, du faktisk har

Begynd med protokollen, fordi resten af designet afhænger af den. Tors SOCKS-grænseflade implementerer ikke UDP ASSOCIATE, så alt, der bæres over den, skal være en TCP-strøm. En OpenVPN-profil, der bruger UDP, vil ikke virke ad denne vej, uanset hvordan supervisoren er skrevet. Skift profilen til TCP, og bekræft at den eksterne peer accepterer det, før du rører ved opstartslogikken.

Bekræft derefter, at din klient overhovedet kan nå en SOCKS-proxy. OpenVPN 2.6 dokumenterer en socks-proxy-indstilling til TCP-profiler, og forskellige klienter tilbyder forskellig proxy-understøttelse. En starter, der lydløst ignorerer proxy-indstillingen, opretter forbindelse direkte og ser ud til at virke, hvilket er værre end at fejle.

Skriv den valgte transport ned i runbooken, fordi hver senere kontrol afhænger af den.

Trin 2: læs bootstrap-fasen, ikke proceslisten

Tors kontrolprotokol svarer på GETINFO status/bootstrap-phase med den nyeste bootstrap-tilstand, inklusive en fremdriftsprocent og et sammendragstag. Det svar er nyttigt netop, fordi en controller kan tilslutte sig, efter at daemonen allerede har afsluttet bootstrap. En supervisor, der kun lytter efter hændelser, vil overse det tilfælde, hvor Tor var klar, før supervisoren startede.

Godkend kontrolforbindelsen ordentligt. En kontrolport er en administrativ grænseflade, og enhver, der kan tale med den, kan omkonfigurere daemonen. Hold den på localhost, hold cookie- eller adgangskodegodkendelse aktiveret, og fjern ikke nogen af dem for at gøre et opstartsscript enklere.

Læs fasen én gang ved opstart, og abonnér derefter på fremdriftshændelser til livevisningen.

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

Et svar med fremdrift 100 og tagget done betyder, at daemonen har afsluttet sin egen opstart. Det betyder endnu ikke, at der findes et brugbart kredsløb til din destination.

Trin 3: vent på en klientkredsløbshændelse

Tors hændelsesprotokol definerer CIRCUIT_ESTABLISHED, som rapporterer, at klienten har et kredsløb, den kan bruge. Det er det klarhedssignal, en bærerport ønsker, fordi det er tættere på den evne, du har brug for, end en procentdel er. Abonnér på hændelsen, og registrér overgangen, så loggen viser, hvornår bæreren blev brugbar, i stedet for hvornår processen dukkede op.

Behandl hændelsen som tilladelse til at forsøge, ikke som en garanti for en bestemt destination. En udgangspolitik kan stadig afvise den eksterne peer, og VPN'ens eget håndtryk kan stadig fejle af grunde, der intet har med Tor at gøre.

Hold de to betingelser adskilt i koden. En enkelt boolsk værdi ved navn ready vil smelte dem sammen og gøre den næste hændelse ulæselig.

Trin 4: portér VPN'en på dens eget håndtryk

VPN'en har sin egen klarhedsbetingelse, og den er den eneste, der beviser, at tunnelen kom op. Vent på, at klienten rapporterer en forbundet tilstand med en tildelt adresse, og kontrollér derefter, at proxy-kravet blev holdt i kraft. En gentagelsesløkke, der dropper socks-proxy-indstillingen efter én fejl, opretter forbindelse direkte og besejrer lydløst hele designet.

Beslut, hvad der sker, når peeren er utilgængelig, før du får brug for at vide det. Et begrænset gentagelsesforsøg med en synlig fejl er lettere at drive end en uendelig løkke, og det giver overvågningssystemet noget at alarmslå på. Den samme beslutning gælder for bæreren: hvis Tor genstarter, skal VPN'en rives ned og portes igen i stedet for at blive efterladt på et dødt kredsløb.

Endelig skal du beholde applikationens egen politik, mens VPN'en er nede. En supervisor, der venter korrekt, gør intet for at forhindre en urelateret proces i at sende trafik direkte.

Kontrollér de fire overgange, du skal overleve

Fire tilfælde dækker designet: en kold start, hvor Tor kommer op først, en supervisor, der tilslutter sig en allerede klar Tor, en utilgængelig VPN-peer og tab af bæreren, mens tunnelen er oppe. Hver af dem har en anden forventet overgang, og hver af dem giver en anden loglinje, hvis porten er skrevet korrekt.

Kør dem med vilje, én ad gangen, og læs tilstandsendringerne i stedet for proceslisten.

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

Når bæreren falder, skal VPN'en følge den ned inden for ét gentagelsesinterval i stedet for at hænge fast med en forældet tunnel. Når Tor vender tilbage, skal porten kun åbnes igen efter kredsløbshændelsen, ikke efter processtarten. Log, hvilken betingelse der manglede ved hver fejl, og den næste vagthavende skal ikke rekonstruere rækkefølgen ud fra tidsstempler.