Tor gata înainte de VPN: ordonarea corectă a porții de pornire

Să urmărești un proces tor și apoi să pornești VPN-ul este cea mai obișnuită cale de a construi greșit acest stack. Daemonul apare mult înainte de a putea transporta un flux de client, iar o pauză fixă este o presupunere îmbrăcată în dependență. Poarta trebuie să fie starea de care următorul component are cu adevărat nevoie. Parcurge cei patru pași de mai jos în ordine și tratează fiecare ca o condiție separată, nu ca o întârziere de reglat.

Pasul 1: alege transportul pe care îl ai cu adevărat

Începe cu protocolul, pentru că restul proiectării depinde de el. Interfața SOCKS a Tor nu implementează UDP ASSOCIATE, așa că tot ce trece prin ea trebuie să fie un flux TCP. Un profil OpenVPN care folosește UDP nu va funcționa pe această cale, oricum ar fi scris supervisorul. Treci profilul pe TCP și confirmă că partenerul îndepărtat îl acceptă înainte de a atinge logica de pornire.

Apoi confirmă că clientul tău poate ajunge măcar la un proxy SOCKS. OpenVPN 2.6 documentează o opțiune socks-proxy pentru profilurile TCP, iar clienți diferiți oferă suport de proxy diferit. Un lansator care ignoră în tăcere opțiunea de proxy se va conecta direct și va părea că funcționează, ceea ce este mai rău decât eșecul.

Scrie transportul ales în runbook, pentru că fiecare verificare ulterioară depinde de el.

Pasul 2: citește faza bootstrap, nu lista de procese

Protocolul de control al Tor răspunde la GETINFO status/bootstrap-phase cu cea mai recentă stare bootstrap, inclusiv un procent de progres și o etichetă de rezumat. Acel răspuns este util exact pentru că un controler se poate conecta după ce daemonul a terminat deja bootstrap. Un supervisor care ascultă doar evenimente va rata cazul în care Tor era deja gata înainte ca supervisorul să pornească.

Autentifică corect conexiunea de control. Un port de control este o interfață administrativă, iar oricine poate vorbi cu el poate reconfigura daemonul. Ține-l pe localhost, păstrează autentificarea prin cookie sau parolă activă și nu elimina niciuna dintre ele ca să simplifici un script de pornire.

Citește faza o dată la pornire, apoi abonează-te la evenimentele de progres pentru vizualizarea live.

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

Un răspuns cu progres 100 și eticheta done înseamnă că daemonul și-a încheiat propria pornire. Încă nu înseamnă că există un circuit utilizabil către destinația ta.

Pasul 3: așteaptă un eveniment de circuit al clientului

Protocolul de evenimente al Tor definește CIRCUIT_ESTABLISHED, care raportează că clientul are un circuit pe care îl poate folosi. Acesta este semnalul de disponibilitate pe care îl vrea o poartă de transport, pentru că este mai aproape de capacitatea de care ai nevoie decât un procent. Abonează-te la eveniment și înregistrează tranziția, ca jurnalul să arate când transportul a devenit utilizabil, nu când a apărut procesul.

Tratează evenimentul ca permisiune de a încerca, nu ca garanție pentru o anumită destinație. O politică de ieșire poate refuza în continuare partenerul îndepărtat, iar handshake-ul VPN-ului însuși poate eșua în continuare din motive care nu au nimic de-a face cu Tor.

Ține cele două condiții separate în cod. O singură valoare booleană numită ready le va uni și va face următorul incident ilizibil.

Pasul 4: condiționează VPN-ul de propriul său handshake

VPN-ul are propria condiție de disponibilitate și doar aceasta dovedește că tunelul a urcat. Așteaptă ca clientul să raporteze o stare conectată cu o adresă alocată, apoi verifică dacă cerința de proxy a rămas în vigoare. O buclă de reîncercări care renunță la opțiunea socks-proxy după un eșec se va conecta direct și va înfrânge în tăcere întregul proiect.

Decide ce se întâmplă când partenerul este inaccesibil înainte de a avea nevoie să știi. O reîncercare limitată cu un eșec vizibil este mai ușor de operat decât o buclă infinită și îi dă sistemului de monitorizare ceva pe care să alerteze. Aceeași decizie se aplică transportului: dacă Tor repornește, VPN-ul trebuie demontat și condiționat din nou, nu lăsat să ruleze pe un circuit mort.

În final, păstrează politica proprie a aplicației în timp ce VPN-ul este oprit. Un supervisor care așteaptă corect nu face nimic pentru a împiedica un proces fără legătură să trimită trafic direct.

Verifică cele patru tranziții pe care trebuie să le supraviețuiești

Patru cazuri acoperă proiectarea: o pornire la rece în care Tor urcă primul, un supervisor care se atașează la un Tor deja gata, un partener VPN indisponibil și pierderea transportului cât timp tunelul este sus. Fiecare are o tranziție așteptată diferită și fiecare produce o linie de jurnal diferită dacă poarta este scrisă corect.

Rulează-le intenționat, unul câte unul, și citește schimbările de stare, nu lista de procese.

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

Când transportul cade, VPN-ul ar trebui să coboare după el într-un interval de reîncercare, nu să rămână cu un tunel învechit. Când Tor revine, poarta ar trebui să se redeschidă doar după evenimentul de circuit, nu după pornirea procesului. Înregistrează ce condiție lipsea la fiecare eșec, iar următoarea persoană de gardă nu va trebui să reconstruiască ordinea din marcaje de timp.