Tor klar før VPN: riktig rekkefølge på oppstartsporten

Å se etter en tor-prosess og deretter starte VPN er den vanligste måten å bygge denne stakken feil på. Daemonen dukker opp lenge før den kan bære en klientstrøm, og en fast pause er en gjetning kledd som en avhengighet. Porten må være tilstanden den neste komponenten faktisk trenger. Gå gjennom de fire trinnene nedenfor i rekkefølge, og behandle hvert av dem som en egen betingelse i stedet for en forsinkelse å justere.

Trinn 1: velg transporten du faktisk har

Start med protokollen, fordi resten av designet avhenger av den. SOCKS-grensesnittet til Tor implementerer ikke UDP ASSOCIATE, så alt som bæres over det, må være en TCP-strøm. En OpenVPN-profil som bruker UDP vil ikke fungere gjennom denne veien, uansett hvordan supervisor er skrevet. Bytt profilen til TCP og bekreft at den eksterne motparten godtar det før du rører oppstartslogikken.

Bekreft deretter at klienten din i det hele tatt kan nå en SOCKS-proxy. OpenVPN 2.6 dokumenterer et socks-proxy-alternativ for TCP-profiler, og ulike klienter gir ulik proxy-støtte. En oppstarter som stille ignorerer proxy-alternativet, kobler direkte til og ser ut til å virke, noe som er verre enn å feile.

Skriv den valgte transporten inn i runbooken, fordi hver senere sjekk avhenger av den.

Trinn 2: les bootstrap-fasen, ikke prosesslisten

Tor-kontrollprotokollen svarer på GETINFO status/bootstrap-phase med den nyeste bootstrap-tilstanden, inkludert en fremdriftsprosent og en sammendragstagg. Det svaret er nyttig nettopp fordi en kontroller kan koble seg på etter at daemonen allerede har fullført bootstrap. En supervisor som bare lytter på hendelser, vil overse tilfellet der Tor var klar før supervisoren startet.

Autentiser kontrolltilkoblingen ordentlig. En kontrollport er et administrativt grensesnitt, og alle som kan snakke med den, kan rekonfigurere daemonen. Hold den på localhost, hold cookie- eller passordautentisering aktivert, og ikke fjern noen av dem for å gjøre et oppstartsskript enklere.

Les fasen én gang ved oppstart, og abonner deretter på fremdriftshendelser for sanntidsvisningen.

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 taggen done betyr at daemonen har fullført sin egen oppstart. Det betyr ennå ikke at det finnes en brukbar krets til målet ditt.

Trinn 3: vent på en klientkrets-hendelse

Tor-hendelsesprotokollen definerer CIRCUIT_ESTABLISHED, som melder at klienten har en krets den kan bruke. Det er klarsignalet en bærerport vil ha, fordi det er nærmere evnen du trenger enn en prosent er. Abonner på hendelsen og registrer overgangen, slik at loggen viser når bæreren ble brukbar i stedet for når prosessen dukket opp.

Behandle hendelsen som tillatelse til å prøve, ikke som en garanti for en bestemt destinasjon. En utgangspolicy kan fortsatt avvise den eksterne motparten, og VPN-ens egen håndtrykk kan fortsatt feile av grunner som ikke har noe med Tor å gjøre.

Hold de to betingelsene atskilt i koden. En enkelt boolsk verdi kalt ready vil slå dem sammen og gjøre neste hendelse uleselig.

Trinn 4: port VPN på dens egen håndtrykk

VPN har sin egen klartilstand, og den er den eneste som beviser at tunnelen kom opp. Vent til klienten rapporterer en tilkoblet tilstand med en tildelt adresse, og kontroller deretter at proxy-kravet forble gjeldende. En nytteløkke som slipper socks-proxy-alternativet etter én feil, kobler direkte til og beseirer stille hele designet.

Bestem hva som skjer når motparten er utilgjengelig, før du trenger å vite det. Et begrenset nytteløp med en synlig feil er enklere å drifte enn en uendelig løkke, og det gir overvåkingssystemet noe å varsle på. Den samme beslutningen gjelder bæreren: hvis Tor starter på nytt, må VPN rives ned og portes på nytt i stedet for å bli stående på en død krets.

Til slutt, hold applikasjonens egen policy på plass mens VPN er nede. En supervisor som venter riktig, gjør ingenting for å hindre en urelatert prosess i å sende trafikk direkte.

Sjekk de fire overgangene du må overleve

Fire tilfeller dekker designet: en kald start der Tor kommer opp først, en supervisor som kobler seg til en allerede klar Tor, en utilgjengelig VPN-motpart, og tap av bæreren mens tunnelen er oppe. Hver av dem har en annen forventet overgang, og hver av dem gir en annen logglinje hvis porten er skrevet riktig.

Kjør dem med vilje, én om gangen, og les tilstandsendringene i stedet for prosesslisten.

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 faller, bør VPN følge den ned innen ett nytteløpsintervall i stedet for å henge igjen med en foreldet tunnel. Når Tor kommer tilbake, bør porten åpnes bare etter kretshendelsen, ikke etter prosessstarten. Logg hvilken betingelse som manglet ved hver feil, og den neste på vakt slipper å rekonstruere rekkefølgen fra tidsstempler.