Tor a punt abans de la VPN: ordenar correctament la porta d'inici

Vigilar un procés tor i després iniciar la VPN és la manera més habitual de construir malament aquesta pila. El dimoni apareix molt abans que pugui transportar un flux de client, i una espera fixa és una conjectura disfressada de dependència. La porta ha de ser l'estat que el component següent necessita realment. Recorreu els quatre passos següents en ordre i tracteu cadascun com una condició separada en lloc d'un retard per ajustar.

Pas 1: trieu el transport que realment teniu

Comenceu pel protocol, perquè la resta del disseny en depèn. La interfície SOCKS del Tor no implementa UDP ASSOCIATE, així que qualsevol cosa que s'hi transporti ha de ser un flux TCP. Un perfil d'OpenVPN que faci servir UDP no funcionarà per aquest camí, per bé que estigui escrit el supervisor. Canvieu el perfil a TCP i confirmeu que el parell remot l'accepta abans de tocar la lògica d'inici.

Després confirmeu que el vostre client pot arribar a un proxy SOCKS. OpenVPN 2.6 documenta una opció socks-proxy per als perfils TCP, i clients diferents exposen suport de proxy diferent. Un llançador que ignora silenciosament l'opció de proxy es connectarà directament i semblarà funcionar, cosa que és pitjor que fracassar.

Escriviu el transport triat al runbook, perquè cada comprovació posterior en depèn.

Pas 2: llegiu la fase de bootstrap, no la llista de processos

El protocol de control del Tor respon a GETINFO status/bootstrap-phase amb l'estat de bootstrap més recent, incloent-hi un percentatge de progrés i una etiqueta resum. Aquesta resposta és útil precisament perquè un controlador es pot connectar després que el dimoni hagi acabat el bootstrap. Un supervisor que només escolta esdeveniments no veurà el cas en què el Tor ja estava a punt abans que comencés el supervisor.

Autentiqueu la connexió de control correctament. Un port de control és una interfície administrativa, i qualsevol qui hi pugui parlar pot reconfigurar el dimoni. Manteniu-lo a localhost, manteniu activada l'autenticació per galeta o contrasenya, i no elimineu cap de les dues per fer més simple un script d'inici.

Llegiu la fase una vegada en arrencar, i després subscriviu-vos als esdeveniments de progrés per a la vista en directe.

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 resposta amb progrés 100 i l'etiqueta done vol dir que el dimoni ha acabat el seu propi inici. Encara no vol dir que existeixi un circuit utilitzable cap al vostre destí.

Pas 3: espereu un esdeveniment de circuit del client

El protocol d'esdeveniments del Tor defineix CIRCUIT_ESTABLISHED, que informa que el client té un circuit que pot utilitzar. Aquest és el senyal de disponibilitat que vol una porta de transport, perquè és més a prop de la capacitat que necessiteu que no un percentatge. Subscriviu-vos a l'esdeveniment i registreu la transició, perquè el registre mostri quan el transport va passar a ser utilitzable i no quan va aparèixer el procés.

Tracteu l'esdeveniment com un permís per provar, no com una garantia sobre cap destí concret. Una política de sortida encara pot refusar el parell remot, i l'apretada de mans de la mateixa VPN encara pot fallar per motius que no tenen res a veure amb el Tor.

Manteniu les dues condicions separades al codi. Un sol booleà anomenat ready les unirà i farà il·legible el proper incident.

Pas 4: porteueu la VPN per la seva pròpia apretada de mans

La VPN té la seva pròpia condició de disponibilitat, i és l'única que demostra que el túnel s'ha aixecat. Espereu que el client informi d'un estat connectat amb una adreça assignada, i després comproveu que el requisit de proxy ha romàs vigent. Un bucle de reintents que descarta l'opció socks-proxy després d'una fallada es connectarà directament i derrotarà silenciosament tot el disseny.

Decidiu què passa quan el parell no és accessible abans de necessitar saber-ho. Un reintent limitat amb una fallada visible és més fàcil d'operar que un bucle infinit, i dona al sistema de monitoratge alguna cosa per alertar. La mateixa decisió s'aplica al transport: si el Tor es reinicia, la VPN s'ha de desmuntar i tornar a portar, no deixar-se funcionant sobre un circuit mort.

Finalment, manteniu la política pròpia de l'aplicació mentre la VPN està caiguda. Un supervisor que espera correctament no fa res per impedir que un procés no relacionat enviï trànsit directament.

Comproveu les quatre transicions que heu de sobreviure

Quatre casos cobreixen el disseny: un inici en fred en què el Tor apareix primer, un supervisor que s'enganxa a un Tor ja a punt, un parell de VPN no disponible i la pèrdua del transport mentre el túnel és aixecat. Cadascun té una transició esperada diferent, i cadascun produeix una línia de registre diferent si la porta està ben escrita.

Executeu-los deliberadament, un a la vegada, i llegiu els canvis d'estat en lloc de la llista de processos.

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

Quan cau el transport, la VPN ha de baixar amb ell dins d'un interval de reintent en lloc de quedar-se amb un túnel obsolet. Quan el Tor torna, la porta s'ha de reobrir només després de l'esdeveniment de circuit, no després de l'inici del procés. Registreu quina condició faltava a cada fallada, i la propera persona de guàrdia no haurà de reconstruir l'ordre a partir de les marques de temps.