Tor listo antes da VPN: ordenar ben a porta de arrinque

Vixiar un proceso tor e despois iniciar a VPN é a forma máis habitual de construír mal esta pila. O daemon aparece moito antes de poder transportar un fluxo de cliente, e unha espera fixa é unha conxectura disfrazada de dependencia. A porta debe ser o estado que o seguinte compoñente realmente necesita. Percorra os catro pasos seguintes en orde e trate cada un como unha condición separada en lugar dun atraso que axustar.

Paso 1: escolla o transporte que realmente ten

Empece polo protocolo, porque o resto do deseño depende del. A interface SOCKS de Tor non implementa UDP ASSOCIATE, así que todo o que se transporte por ela ten que ser un fluxo TCP. Un perfil de OpenVPN que use UDP non funcionará por esta vía, por ben escrito que estea o supervisor. Cambie o perfil a TCP e confirme que o par remoto o acepta antes de tocar a lóxica de arranque.

Despois confirme que o seu cliente pode chegar a un proxy SOCKS. OpenVPN 2.6 documenta unha opción socks-proxy para perfís TCP, e distintos clientes ofrecen distinto soporte de proxy. Un lanzador que ignora en silencio a opción de proxy conectarase directamente e parecerá funcionar, o que é peor que fallar.

Escriba o transporte escollido no runbook, porque cada comprobación posterior depende del.

Paso 2: lea a fase de bootstrap, non a lista de procesos

O protocolo de control de Tor responde a GETINFO status/bootstrap-phase co estado de bootstrap máis recente, incluído unha porcentaxe de progreso e unha etiqueta de resumo. Esa resposta é útil precisamente porque un controlador pode conectarse despois de que o daemon xa rematase o bootstrap. Un supervisor que só escoita eventos perderase o caso no que Tor xa estaba listo antes de que arrincase o supervisor.

Autentique a conexión de control correctamente. Unha porta de control é unha interface administrativa, e calquera que poida falar con ela pode reconfigurar o daemon. Mantéñaa en localhost, manteña activada a autenticación por cookie ou contrasinal, e non elimine ningunha das dúas para simplificar un script de arranque.

Lea a fase unha vez ao arrincar e logo subscriba os eventos de progreso para a vista en 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

Unha resposta con progreso 100 e a etiqueta done significa que o daemon rematou o seu propio arranque. Aínda non significa que exista un circuíto utilizable cara ao seu destino.

Paso 3: espere un evento de circuíto do cliente

O protocolo de eventos de Tor define CIRCUIT_ESTABLISHED, que informa de que o cliente ten un circuíto que pode usar. Ese é o sinal de dispoñibilidade que quere unha porta de transporte, porque está máis preto da capacidade que necesita que unha porcentaxe. Subscríbase ao evento e rexistre a transición, para que o rexistro mostre cando o transporte pasou a ser utilizable e non cando apareceu o proceso.

Trate o evento como permiso para intentalo, non como unha garantía sobre ningún destino concreto. Unha política de saída aínda pode rexeitar o par remoto, e o apretón de mans da propia VPN aínda pode fallar por motivos que nada teñen que ver con Tor.

Manteña as dúas condicións separadas no código. Un só booleano chamado ready uniraas e fará ilexible o seguinte incidente.

Paso 4: condicione a VPN ao seu propio apretón de mans

A VPN ten a súa propia condición de dispoñibilidade, e é a única que demostra que o túnel se levantou. Espere a que o cliente informe dun estado conectado cun enderezo asignado e logo comprobe que o requisito de proxy seguiu vixente. Un bucle de reintentos que descarta a opción socks-proxy tras un fallo conectarase directamente e derrotará en silencio todo o deseño.

Decida que ocorre cando o par non é accesible antes de necesitar sabelo. Un reintento acoutado cun fallo visible é máis fácil de operar que un bucle infinito, e dálle ao sistema de monitorización algo sobre o que alertar. A mesma decisión vale para o transporte: se Tor se reinicia, a VPN debe desmontarse e volver condicionarse, non quedar funcionando sobre un circuíto morto.

Por último, manteña a política propia da aplicación mentres a VPN está caída. Un supervisor que espera correctamente non fai nada para impedir que un proceso non relacionado envíe tráfico directamente.

Comprobe as catro transicións que debe sobrevivir

Catro casos cobren o deseño: un arrinque en frío no que Tor aparece primeiro, un supervisor que se engancha a un Tor xa listo, un par de VPN non dispoñible e a perda do transporte co túnel levantado. Cada un ten unha transición esperada distinta, e cada un produce unha liña de rexistro distinta se a porta está ben escrita.

Execúteos a propósito, un a un, e lea os cambios de estado en lugar da lista de procesos.

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

Cando cae o transporte, a VPN debería seguilo cara abaixo dentro dun intervalo de reintento en lugar de quedarse cun túnel obsoleto. Cando Tor volve, a porta debería reabrirse só despois do evento de circuíto, non despois do inicio do proceso. Rexistre que condición faltaba en cada fallo, e a seguinte persoa de garda non terá que reconstruír a orde a partir das marcas de tempo.