Tor pronto antes da VPN: ordenar bem o portão de arranque

Observar um processo tor e depois iniciar a VPN é a forma mais comum de construir mal esta pilha. O daemon aparece muito antes de conseguir transportar um fluxo de cliente, e uma espera fixa é um palpite disfarçado de dependência. O portão deve ser o estado de que o componente seguinte realmente precisa. Percorra os quatro passos abaixo por ordem e trate cada um como uma condição separada em vez de um atraso a afinar.

Passo 1: escolha o transporte que realmente tem

Comece pelo protocolo, porque o resto do desenho depende dele. A interface SOCKS do Tor não implementa UDP ASSOCIATE, pelo que tudo o que passa por ela tem de ser um fluxo TCP. Um perfil de OpenVPN que use UDP não funcionará por este caminho, por muito bem escrito que esteja o supervisor. Mude o perfil para TCP e confirme que o par remoto o aceita antes de tocar na lógica de arranque.

Depois confirme que o seu cliente consegue sequer chegar a um proxy SOCKS. O OpenVPN 2.6 documenta uma opção socks-proxy para perfis TCP, e clientes diferentes expõem suporte de proxy diferente. Um lançador que ignora silenciosamente a opção de proxy liga-se diretamente e parece funcionar, o que é pior do que falhar.

Escreva o transporte escolhido no runbook, porque cada verificação posterior depende dele.

Passo 2: leia a fase de bootstrap, não a lista de processos

O protocolo de controlo do Tor responde a GETINFO status/bootstrap-phase com o estado de bootstrap mais recente, incluindo uma percentagem de progresso e uma etiqueta de resumo. Essa resposta é útil precisamente porque um controlador se pode ligar depois de o daemon já ter concluído o bootstrap. Um supervisor que só escuta eventos perderá o caso em que o Tor já estava pronto antes de o supervisor arrancar.

Autentique corretamente a ligação de controlo. Uma porta de controlo é uma interface administrativa, e qualquer pessoa que consiga falar com ela pode reconfigurar o daemon. Mantenha-a em localhost, mantenha a autenticação por cookie ou palavra-passe ativa, e não remova nenhuma das duas para simplificar um script de arranque.

Leia a fase uma vez no arranque e depois subscreva os eventos de progresso para a vista em direto.

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

Uma resposta com progresso 100 e a etiqueta done significa que o daemon concluiu o próprio arranque. Ainda não significa que exista um circuito utilizável até ao seu destino.

Passo 3: espere por um evento de circuito do cliente

O protocolo de eventos do Tor define CIRCUIT_ESTABLISHED, que reporta que o cliente tem um circuito que pode usar. Esse é o sinal de prontidão que um portão de transporte quer, porque está mais próximo da capacidade de que precisa do que uma percentagem. Subscreva o evento e registe a transição, para que o registo mostre quando o transporte ficou utilizável e não quando o processo apareceu.

Trate o evento como permissão para tentar, não como garantia sobre um destino concreto. Uma política de saída ainda pode recusar o par remoto, e o handshake da própria VPN ainda pode falhar por razões que nada têm a ver com o Tor.

Mantenha as duas condições separadas no código. Um único booleano chamado ready vai juntá-las e tornar o incidente seguinte ilegível.

Passo 4: condicione a VPN ao seu próprio handshake

A VPN tem a sua própria condição de prontidão, e é a única que prova que o túnel subiu. Espere que o cliente reporte um estado ligado com um endereço atribuído, e depois verifique que o requisito de proxy se manteve em vigor. Um ciclo de repetições que descarta a opção socks-proxy após uma falha liga-se diretamente e derrota silenciosamente todo o desenho.

Decida o que acontece quando o par não está acessível antes de precisar de o saber. Uma repetição limitada com uma falha visível é mais fácil de operar do que um ciclo infinito, e dá ao sistema de monitorização algo sobre o que alertar. A mesma decisão aplica-se ao transporte: se o Tor reiniciar, a VPN tem de ser desmontada e novamente condicionada, não deixada a correr sobre um circuito morto.

Por fim, mantenha a política própria da aplicação enquanto a VPN está em baixo. Um supervisor que espera corretamente não faz nada para impedir que um processo não relacionado envie tráfego diretamente.

Verifique as quatro transições que tem de sobreviver

Quatro casos cobrem o desenho: um arranque a frio em que o Tor aparece primeiro, um supervisor que se liga a um Tor já pronto, um par de VPN indisponível e a perda do transporte com o túnel em cima. Cada um tem uma transição esperada diferente, e cada um produz uma linha de registo diferente se o portão estiver bem escrito.

Execute-os de propósito, um de cada vez, e leia as mudanças de estado em vez da lista 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

Quando o transporte cai, a VPN deve segui-lo para baixo dentro de um intervalo de repetição em vez de ficar com um túnel obsoleto. Quando o Tor regressa, o portão só deve reabrir depois do evento de circuito, não depois do início do processo. Registe que condição faltava em cada falha, e a próxima pessoa de serviço não terá de reconstruir a ordem a partir das marcas temporais.