Relé Tor versus servidor VPN: por que não são intercambiáveis

Uma porta aberta num relé Tor não é um endpoint VPN. Verifique primeiro o que a porta serve, o papel do relé, o alcance do ouvinte SOCKS e o perfil.

Você tem um endereço, a porta responde e um cliente aceita-o sem reclamar. Nada disso torna um relé Tor um endpoint VPN, e o erro sai caro porque o perfil é importado sem problemas e falha mais tarde no handshake. Uso as quatro verificações abaixo em ordem; cada uma tem uma condição de parada, e parar cedo é justamente o ponto. Se a primeira verificação falhar, as outras não podem ajudar.

Verifique o que a porta realmente serve

Uma porta aberta prova um ouvinte, nada mais. A ORPort de um relé fala as próprias células do Tor depois de um handshake TLS, então um teste TLS bem-sucedido quase não diz nada sobre se um protocolo VPN é aceito ali:

nc -vz 203.0.113.20 443
openssl s_client -connect 203.0.113.20:443 -brief < /dev/null

Leia o certificado em vez do fato de existir um. Os relés apresentam um certificado autoassinado com um nome deliberadamente despretensioso, porque o tráfego do relé deve parecer um HTTPS comum; o certificado de um servidor VPN carrega o nome que o seu perfil espera. Se o par nunca responder ao primeiro pacote do protocolo VPN, nenhuma edição do perfil mudará o resultado.

Pare aqui se o endereço não conclui o handshake que o seu cliente envia. Isso é uma resposta de protocolo, não um problema de configuração, e é a razão mais comum pela qual um perfil importado fica em 'connecting' para sempre.

Verifique o papel do relé, não o tamanho da rede

Os papéis do relé fazem trabalhos diferentes. Um guard é o primeiro salto para os clientes, um relé intermediário encaminha circuitos entre outros relés, um exit é o que toca os destinos, e uma ponte é um ponto de entrada não público distribuído pelo BridgeDB. O glossário do Tor mantém essas definições separadas, e ser alcançável faz parte de todos os papéis, enquanto a permissão para servir clientes arbitrários não faz parte de nenhum deles.

A política de exit vale a leitura porque é a única parte que se parece com uma regra de encaminhamento, e rege os destinos que o exit permitirá sair, não os clientes autorizados a entrar. Uma política de exit restritiva que bloqueia a porta 25 diz algo sobre o controlo do abuso de saída, não sobre se pode apontar um cliente OpenVPN para a máquina.

Pare se estiver a raciocinar a partir da reputação: como os relés encaminham tráfego, o endereço teria de aceitar o seu. O Tor escolhe caminhos por consenso e pelo seu próprio protocolo; um cliente VPN não é participante e não tem circuito a que se juntar.

Verifique se o ouvinte SOCKS é local ou público

O cliente do Tor expõe uma interface SOCKS às aplicações na mesma máquina, por predefinição no loopback. Esse ouvinte é uma comodidade local, não um serviço que um relé oferece à internet, e tratá-lo como um proxy público é a forma como as pessoas acabam a executar um relé aberto que não pretendiam:

ss -ltnp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org

O endereço de ligação é a pista. Uma SocksPort em 127.0.0.1:9050 está a fazer o seu trabalho; uma que escuta em 0.0.0.0 e é alcançável do exterior é um proxy aberto, e os controles de política de acesso do próprio Tor existem precisamente porque essa exposição é um problema e não uma funcionalidade.

Para uma aplicação que precisa do Tor, aponte-a para a porta loopback e deixe o Tor resolver nomes, que é o que a forma socks5h acima faz. Não substitua o endereço do relé por essa porta; o relé não oferece a interface que a sua aplicação pede.

Verifique se o perfil VPN corresponde a um endpoint real

Um perfil VPN é um conjunto de expectativas: o OpenVPN precisa do certificado do servidor ou da CA, de um certificado de cliente e de uma chave, e normalmente de uma chave TLS, enquanto o WireGuard precisa da chave pública do par, de um endpoint e de IP permitidos. Nada disso pode ser derivado de um endereço e de uma porta aberta, e é por isso que um perfil construído assim falha na primeira troca e não na ligação.

Quando lhe entregam um perfil, verifique-o contra um endpoint que controle ou um fornecedor que consiga identificar:

wg show
openvpn --config client.ovpn --verb 4

No registo do OpenVPN, um erro de negociação TLS nomeia diretamente a discrepância; em wg show, um par sem linha de handshake nunca concluiu nenhum. Ambos são mais informativos do que o indicador giratório do cliente, e ambos apontam para material de chaves ou protocolo e não para o Tor.

Verifique de que proteção precisa realmente

Esta é a verificação que decide a arquitetura. O navegador Tor dá-lhe isolamento de circuitos e defesas contra impressões digitais que um VPN não tem; um VPN muda o endereço que um destino vê e autentica-o num fornecedor. Escolher entre os dois é uma questão de modelo de ameaça, não de compatibilidade, e misturá-los produz uma configuração que parece privada e não é.

O encadeamento tem uma ordem. Um VPN que transporta tráfego do Tor é uma disposição suportada, porque o cliente do Tor só precisa de TCP de saída. Um cliente VPN encaminhado por túnel dentro do Tor não é o mesmo e não é o que o cliente do Tor implementa, por isso não planeie com base nisso.

Antes de importar qualquer coisa, confirme as quatro coisas:

  • A porta conclui o handshake do seu protocolo, não apenas uma ligação TCP.
  • Conhece o papel do anfitrião e não trata o encaminhamento como permissão.
  • O ouvinte SOCKS que usa é de loopback e é seu, não uma porta pública no relé de outra pessoa.
  • As chaves ou certificados do perfil pertencem ao endpoint ao qual se liga.

Artigos relacionados