Tor pronto prima della VPN: ordinare bene il cancello di avvio

Sorvegliare un processo tor e poi avviare la VPN è il modo più comune di costruire male questa pila. Il demone compare molto prima di poter trasportare un flusso client, e un’attesa fissa è una supposizione travestita da dipendenza. Il cancello deve essere lo stato che il componente successivo richiede davvero. Percorri i quattro passi qui sotto in ordine e tratta ciascuno come una condizione separata invece che come un ritardo da regolare.

Passo 1: scegli il trasporto che hai davvero

Parti dal protocollo, perché il resto del progetto dipende da esso. L’interfaccia SOCKS di Tor non implementa UDP ASSOCIATE, quindi qualunque cosa vi transiti deve essere un flusso TCP. Un profilo OpenVPN che usa UDP non funzionerà su questo percorso, per come è scritto il supervisore. Passa il profilo a TCP e conferma che il peer remoto lo accetti prima di toccare la logica di avvio.

Poi conferma che il tuo client riesca davvero a raggiungere un proxy SOCKS. OpenVPN 2.6 documenta un’opzione socks-proxy per i profili TCP, e client diversi espongono un supporto proxy diverso. Un lanciatore che ignora silenziosamente l’opzione proxy si connetterà direttamente e sembrerà funzionare, il che è peggio di un fallimento.

Scrivi il trasporto scelto nel runbook, perché ogni verifica successiva dipende da esso.

Passo 2: leggi la fase bootstrap, non l’elenco dei processi

Il protocollo di controllo di Tor risponde a GETINFO status/bootstrap-phase con lo stato di bootstrap più recente, inclusi una percentuale di avanzamento e un tag di riepilogo. Quella risposta è utile proprio perché un controller può collegarsi dopo che il demone ha già completato il bootstrap. Un supervisore che ascolta solo gli eventi perderà il caso in cui Tor era già pronto prima dell’avvio del supervisore.

Autentica correttamente la connessione di controllo. Una porta di controllo è un’interfaccia amministrativa, e chiunque possa parlarle può riconfigurare il demone. Tienila su localhost, mantieni attiva l’autenticazione tramite cookie o password, e non rimuovere nessuna delle due per semplificare uno script di avvio.

Leggi la fase una volta all’avvio, poi sottoscrivi gli eventi di avanzamento per la vista dal vivo.

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

Una risposta con avanzamento 100 e il tag done significa che il demone ha completato il proprio avvio. Non significa ancora che esista un circuito utilizzabile verso la tua destinazione.

Passo 3: attendi un evento di circuito del client

Il protocollo degli eventi di Tor definisce CIRCUIT_ESTABLISHED, che segnala che il client dispone di un circuito che può usare. È il segnale di prontezza che un cancello di trasporto vuole, perché è più vicino alla capacità che ti serve di quanto lo sia una percentuale. Sottoscrivi l’evento e registra la transizione, così il log mostra quando il trasporto è diventato utilizzabile e non quando è comparso il processo.

Tratta l’evento come permesso di provare, non come garanzia su una destinazione specifica. Una politica di uscita può ancora rifiutare il peer remoto, e l’handshake della VPN stessa può ancora fallire per motivi che non hanno nulla a che fare con Tor.

Tieni separate le due condizioni nel codice. Un solo booleano chiamato ready le fonderà e renderà illeggibile il prossimo incidente.

Passo 4: vincola la VPN al suo handshake

La VPN ha la propria condizione di prontezza, ed è l’unica che dimostra che il tunnel è salito. Attendi che il client segnali uno stato connesso con un indirizzo assegnato, poi verifica che il requisito del proxy sia rimasto in vigore. Un ciclo di tentativi che scarta l’opzione socks-proxy dopo un fallimento si connetterà direttamente e sconfiggerà silenziosamente l’intero progetto.

Decidi cosa succede quando il peer non è raggiungibile prima di doverlo sapere. Un tentativo limitato con un fallimento visibile è più facile da gestire di un ciclo infinito, e dà al sistema di monitoraggio qualcosa su cui allertare. La stessa decisione vale per il trasporto: se Tor si riavvia, la VPN va smontata e rivincolata, non lasciata in funzione su un circuito morto.

Infine, mantieni in vigore la politica dell’applicazione mentre la VPN è giù. Un supervisore che attende correttamente non fa nulla per impedire a un processo non correlato di inviare traffico direttamente.

Verifica le quattro transizioni che devi sopravvivere

Quattro casi coprono il progetto: un avvio a freddo in cui Tor sale per primo, un supervisore che si aggancia a un Tor già pronto, un peer VPN non disponibile e la perdita del trasporto con il tunnel attivo. Ognuno ha una transizione attesa diversa, e ognuno produce una riga di log diversa se il cancello è scritto bene.

Eseguili di proposito, uno alla volta, e leggi i cambi di stato invece dell’elenco dei processi.

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

Quando il trasporto cade, la VPN dovrebbe seguirlo in basso entro un intervallo di tentativi invece di restare agganciata a un tunnel obsoleto. Quando Tor ritorna, il cancello dovrebbe riaprirsi solo dopo l’evento di circuito, non dopo l’avvio del processo. Registra quale condizione mancava a ogni fallimento, e la persona di turno successiva non dovrà ricostruire l’ordine dai timestamp.