VPN através do Tor: primeiro a verificação do transporte

Tor primeiro significa que o cliente VPN fica atrás de um proxy SOCKS, pelo que o próprio túnel é construído através do Tor e o tráfego das aplicações sai do ponto final da VPN. Essa é uma ordem específica, e não é o que a maioria das pessoas constrói. Abrir o Tor Browser ao lado de um cliente VPN normal não obriga nenhum dos dois programas a usar o caminho do outro.

Percorra as verificações por ordem. Cada uma decide se vale a pena começar a seguinte.

Que ordem está realmente a construir

Duas ordens confundem-se na mesma conversa. Tor primeiro significa que o cliente VPN chega ao seu servidor através de um proxy SOCKS, pelo que o túnel é construído sobre o Tor. VPN primeiro significa que o tráfego do Tor sai pelo túnel, que é o que a maioria das pessoas constrói por acidente e depois descreve como a outra. A primeira concentra a fronteira de encaminhamento no operador da VPN, a segunda concentra-a na entrada e na saída do Tor. Nenhuma delas é o que se obtém ao manter as duas aplicações abertas ao mesmo tempo.

Anote qual das ordens a tarefa exige antes de configurar seja o que for, porque as duas requerem definições de software diferentes e falham em locais diferentes. Uma ordem mal rotulada envia-o a depurar a camada errada durante uma hora. Tudo o que se segue assume Tor primeiro.

Verifique o transporte antes de tudo o resto

A interface SOCKS do Tor transporta fluxos TCP e não fornece uma associação UDP geral. Uma VPN cujo transporte seja UDP não pode tratar esse proxy como uma interface de rede comum, e nenhuma definição do cliente altera o que o proxy está disposto a encaminhar. O WireGuard na sua forma habitual é a vítima óbvia. Um perfil OpenVPN em modo TCP é a solução comum, e continua a ser preciso dizer-lhe explicitamente para usar o proxy.

ss -lntp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 -o /dev/null -w '%{http_code}\n' https://example.com

Confirme que o proxy escuta e consegue transportar um pedido HTTPS simples antes de depurar um túnel através dele. Se o pedido simples falhar, o cliente VPN nunca terá sucesso e os seus registos não lhe dirão porquê.

Reescreva o mapa do observador

A entrada do Tor pode ver a origem que se liga ao Tor, a menos que algo anterior a tenha alterado, pelo que esse salto aprende o seu endereço. O fornecedor da VPN recebe uma ligação que chega do lado do Tor mas ainda pode conhecer uma conta, um registo de pagamento ou uma credencial que enviou dentro do túnel. Os destinos alcançados através da VPN veem a sua saída em vez da saída do Tor, e isso concentra a fronteira final de encaminhamento num único operador.

Também não recria um caminho distribuído até cada destino. O Tor Browser constrói um circuito novo por site; uma VPN transportada sobre o Tor constrói um único túnel, e cada site por trás dele partilha esse ponto final. Trate a diferença como um facto de conceção e não como uma limitação a eliminar.

Conte as camadas de falha quando algo quebra

Uma configuração avariada tem pelo menos quatro camadas independentes: a ligação SOCKS, o aperto de mão TLS com o servidor da VPN, o próprio aperto de mão da VPN e, depois, o encaminhamento ou a resolução de nomes dentro do túnel. Cada uma falha com um sintoma diferente e cada uma exige uma reparação diferente. Relaxar as verificações de certificados porque o túnel não sobe é o diagnóstico errado clássico, e transforma um problema de transporte num problema de segurança.

Registe a primeira camada que falha e pare aí. Uma recusa do proxy e uma chave rejeitada não são variações do mesmo acontecimento.

Pare se o modelo de ameaça precisar das defesas do Tor Browser

Encaminhar aplicações arbitrárias através de uma VPN transportada pelo Tor não dá a essas aplicações as funções de impressão digital e isolamento do Tor Browser. As suas contas, identificadores e comportamento de rede continuam relevantes, e um túnel não normaliza nenhum deles. Se o objetivo é um navegador que se mistura com outros utilizadores, esta ordem não o proporciona.

O próprio Tor Project alerta contra combinações que os utilizadores não conseguem configurar corretamente, e esta aplica-se à maioria das pessoas. É um desenho deliberado para um modelo de ameaça estreito, não um atalho para tráfego anónimo em todo o dispositivo.