Tor listo antes de la VPN: ordenar bien la puerta de arranque

Vigilar un proceso tor y luego iniciar la VPN es la forma más común de construir mal esta pila. El demonio aparece mucho antes de que pueda transportar un flujo de cliente, y una espera fija es una conjetura disfrazada de dependencia. La puerta debe ser el estado que el siguiente componente realmente necesita. Recorra los cuatro pasos siguientes en orden y trate cada uno como una condición separada en lugar de un retardo que ajustar.

Paso 1: elija el transporte que realmente tiene

Empiece por el protocolo, porque el resto del diseño depende de él. La interfaz SOCKS de Tor no implementa UDP ASSOCIATE, así que cualquier cosa que se transporte por ella tiene que ser un flujo TCP. Un perfil de OpenVPN que use UDP no funcionará por esta vía, por bien escrito que esté el supervisor. Cambie el perfil a TCP y confirme que el par remoto lo acepta antes de tocar la lógica de arranque.

Después confirme que su cliente puede alcanzar un proxy SOCKS. OpenVPN 2.6 documenta una opción socks-proxy para perfiles TCP, y distintos clientes ofrecen distinto soporte de proxy. Un lanzador que ignora en silencio la opción de proxy se conectará directamente y parecerá funcionar, lo que es peor que fallar.

Escriba el transporte elegido en el runbook, porque cada comprobación posterior depende de él.

Paso 2: lea la fase de bootstrap, no la lista de procesos

El protocolo de control de Tor responde a GETINFO status/bootstrap-phase con el estado de bootstrap más reciente, incluido un porcentaje de progreso y una etiqueta de resumen. Esa respuesta es útil precisamente porque un controlador puede conectarse después de que el demonio ya haya terminado el bootstrap. Un supervisor que solo escucha eventos se perderá el caso en que Tor ya estaba listo antes de que arrancara el supervisor.

Autentique la conexión de control correctamente. Un puerto de control es una interfaz administrativa, y cualquiera que pueda hablar con él puede reconfigurar el demonio. Manténgalo en localhost, mantenga activada la autenticación por cookie o contraseña, y no elimine ninguna de las dos para simplificar un script de arranque.

Lea la fase una vez al arrancar y luego suscríbase a los eventos de progreso para la 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

Una respuesta con progreso 100 y la etiqueta done significa que el demonio terminó su propio arranque. Todavía no significa que exista un circuito utilizable hacia su destino.

Paso 3: espere un evento de circuito del cliente

El protocolo de eventos de Tor define CIRCUIT_ESTABLISHED, que informa de que el cliente tiene un circuito que puede usar. Esa es la señal de disponibilidad que quiere una puerta de transporte, porque está más cerca de la capacidad que necesita que un porcentaje. Suscríbase al evento y registre la transición, para que el registro muestre cuándo el transporte pasó a ser utilizable y no cuándo apareció el proceso.

Trate el evento como permiso para intentarlo, no como una garantía sobre ningún destino concreto. Una política de salida todavía puede rechazar al par remoto, y el handshake de la propia VPN todavía puede fallar por motivos que nada tienen que ver con Tor.

Mantenga las dos condiciones separadas en el código. Un solo booleano llamado ready las unirá y hará ilegible el siguiente incidente.

Paso 4: condicione la VPN a su propio handshake

La VPN tiene su propia condición de disponibilidad, y es la única que demuestra que el túnel se levantó. Espere a que el cliente informe de un estado conectado con una dirección asignada y luego compruebe que el requisito de proxy siguió vigente. Un bucle de reintentos que descarta la opción socks-proxy tras un fallo se conectará directamente y derrotará en silencio todo el diseño.

Decida qué ocurre cuando el par no es accesible antes de necesitar saberlo. Un reintento acotado con un fallo visible es más fácil de operar que un bucle infinito, y da al sistema de monitorización algo sobre lo que alertar. La misma decisión vale para el transporte: si Tor se reinicia, la VPN debe desmontarse y volver a condicionarse, no quedarse funcionando sobre un circuito muerto.

Por último, mantenga la política propia de la aplicación mientras la VPN está caída. Un supervisor que espera correctamente no hace nada para impedir que un proceso no relacionado envíe tráfico directamente.

Compruebe las cuatro transiciones que debe sobrevivir

Cuatro casos cubren el diseño: un arranque en frío en el que Tor aparece primero, un supervisor que se engancha a un Tor ya listo, un par de VPN no disponible y la pérdida del transporte con el túnel levantado. Cada uno tiene una transición esperada distinta, y cada uno produce una línea de registro distinta si la puerta está bien escrita.

Ejecútelos a propósito, uno a la vez, y lea los cambios de estado en lugar de la 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

Cuando cae el transporte, la VPN debería seguirlo hacia abajo dentro de un intervalo de reintento en lugar de quedarse con un túnel obsoleto. Cuando Tor vuelve, la puerta debería reabrirse solo después del evento de circuito, no después del inicio del proceso. Registre qué condición faltaba en cada fallo, y la siguiente persona de guardia no tendrá que reconstruir el orden a partir de las marcas de tiempo.