Tor klar før VPN-en: rett rekkjefølgje på oppstartsporten

Å overvake ein tor-prosess og deretter starte VPN-en er den vanlegaste måten å byggje denne stakken feil på. Daemonen dukkar opp lenge før han kan bere ein klientstraum, og ei fast ventetid er eit gjet som er kledd ut som ein avhengigheit. Porten må vere tilstanden den neste komponenten faktisk treng. Gå gjennom dei fire trinna nedanfor i rekkjefølgje, og handsam kvart av dei som eit eige vilkår i staden for ei forseinking som skal justerast.

Trinn 1: vel transporten du faktisk har

Byrja med protokollen, fordi resten av designet avheng av han. SOCKS-grensesnittet til Tor implementerer ikkje UDP ASSOCIATE, så alt som blir bore over det, må vere ein TCP-straum. Ein OpenVPN-profil som brukar UDP vil ikkje verke gjennom denne vegen, same korleis supervisoren er skriven. Byta profilen til TCP og stadfesta at den eksterne motparten godtek han før du rører oppstartslogikken.

Stadfesta deretter at klienten din i det heile kan nå ein SOCKS-proxy. OpenVPN 2.6 dokumenterer eit socks-proxy-val for TCP-profilar, og ulike klientar tilbyr ulik proxy-støtte. Ein startar som stille ignorerer proxy-valet, koplar direkte til og ser ut til å verke, noko som er verre enn å mislukkast.

Skriv den valde transporten inn i runbooken, fordi kvar seinare kontroll avheng av han.

Trinn 2: les bootstrap-fasen, ikkje prosesslista

Kontrollprotokollen til Tor svarar på GETINFO status/bootstrap-phase med den nyaste bootstrap-tilstanden, inkludert ein framdriftsprosent og ein samandragstagg. Det svaret er nyttig nettopp fordi ein kontrollør kan kopie til etter at daemonen allereie har fullført bootstrap. Ein supervisor som berre lyttar på hendingar, vil oversjå tilfellet der Tor var klar før supervisoren starta.

Autentiser kontrolltilkoplinga ordentleg. Ein kontrollport er eit administrativt grensesnitt, og kven som helst som kan snakke med han, kan rekonfigurere daemonen. Hald han på localhost, hald cookie- eller passordautentisering påslått, og fjern ikkje nokon av dei for å gjere eit oppstartsskript enklare.

Les fasen éin gong ved oppstart, og abonner deretter på framdriftshendingar for sanntidsvisninga.

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

Eit svar med framdrift 100 og taggen done tyder at daemonen har fullført sin eigen oppstart. Det tyder enno ikkje at det finst ein brukande krins til målet ditt.

Trinn 3: vent på ei klientkrins-hending

Hendingeprotokollen til Tor definerer CIRCUIT_ESTABLISHED, som melder at klienten har ein krins han kan bruke. Det er klarsignalet ein berarport vil ha, fordi det er nærare evna du treng enn ein prosentdel er. Abonner på hendinga og registrer overgangen, slik at loggen viser når beraren vart brukande og ikkje når prosessen dukka opp.

Handsam hendinga som løyve til å prøve, ikkje som garanti for ein viss destinasjon. Ein utgangspolicy kan framleis avvise den eksterne motparten, og handtrykket til VPN-en sjølv kan framleis mislukkast av grunnar som ikkje har noko med Tor å gjere.

Hald dei to vilkåra fråskilde i koden. Éin boolsk verdi kalla ready vil slå dei saman og gjere neste hending uleseleg.

Trinn 4: portér VPN-en på sitt eige handtrykk

VPN-en har sitt eige klare-vilkår, og det er det einaste som provar at tunnelen kom opp. Vent til klienten rapporterer ein tilkopla tilstand med ein tildelt adresse, og kontroller deretter at proxy-kravet vart verande i kraft. Ei gjentakingsløkje som slepp socks-proxy-valet etter éin feil, koplar direkte til og slår stille heile designet.

Avgjer kva som skjer når motparten ikkje er tilgjengeleg, før du treng å vite det. Ei avgrensa gjentaking med ein synleg feil er enklare å drive enn ei endelaus løkje, og ho gjev overvakingssystemet noko å varsle om. Den same avgjerda gjeld for beraren: viss Tor startar på nytt, må VPN-en rivast ned og portérast på nytt i staden for å bli ståande på ein daud krins.

Til slutt, hald applikasjonen sine eigne reglar på plass medan VPN-en er nede. Ein supervisor som ventar rett, gjer ingenting for å hindre ein urelatert prosess i å sende trafikk direkte.

Kontroller dei fire overgangane du må overleve

Fire tilfelle dekkjer designet: ein kald start der Tor kjem opp først, ein supervisor som koplar seg til ein allereie klar Tor, ein utilgjengeleg VPN-motpart og tap av beraren medan tunnelen er oppe. Kvar av dei har ein annan venta overgang, og kvar av dei gjev ei annan logglinje viss porten er skriven rett.

Køyr dei med vilje, éin om gongen, og les tilstandsendringane i staden for prosesslista.

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 beraren fell, bør VPN-en følgje han ned innan eitt gjentakingsintervall i staden for å henge att med ein utdatert tunnel. Når Tor kjem tilbake, bør porten berre opne seg att etter krinshendinga, ikkje etter prosessoppstarten. Logg kva vilkår som mangla ved kvar feil, og den neste på vakt slepp å rekonstruere rekkjefølgja frå tidsstempel.