Relé de saída Tor versus servidor de saída VPN: o que cada um sabe
Um relé de saída Tor e um servidor de saída VPN mostram ambos um endereço público, mas dividem o conhecimento de forma diferente. Compare visibilidade, cobertura e política de portas.
Os dois desenhos escondem o seu endereço atrás de um único IP público, e um site que imprime o endereço que vê não consegue distingui-los. A diferença é quem aprende o quê pelo caminho, quanto tráfego é coberto e quais portas podem funcionar. Um relé de saída Tor é o último salto de um circuito de três relés; um servidor de saída VPN encerra o seu túnel e abre ele mesmo a conexão de saída. Veja como decido qual deles uma tarefa precisa, e o que verifico antes de supor que um se comporta como o outro.
Dois caminhos que terminam num endereço
O Tor constrói um circuito por um guarda, um relé intermédio e uma saída, e cifra a carga em camadas para que cada relé descasque apenas a sua. A saída estabelece a conexão TCP comum ao destino, e é por isso que o destino vê o endereço de saída. O seu cliente nunca fala diretamente com o destino, e o guarda também não o vê.
Uma VPN é um túnel para um único ponto final. O servidor do operador remove o túnel e abre a conexão de saída, então o destino também vê um único endereço, desta vez o do operador. O resultado observável é o mesmo; o conhecimento não. Um teste que imprime um IP responde em que sistema está e nada diz sobre a repartição de confiança que realmente difere.
Quem acaba sabendo o quê
O ponto final VPN vê o endereço de origem, o destino, o momento e o volume num só lugar. Essa concentração é o desenho: um operador, uma superfície de registos, um lugar para intimar ou configurar mal. Tudo o que ganha vem de confiar nessa parte e da política de saída do ponto final.
O Tor divide esse conhecimento. O guarda conhece o seu endereço mas não o destino; a saída conhece o destino mas não o seu endereço. Não se espera que um relé aprenda ambos. É uma propriedade estrutural, não uma promessa contra um observador global, um relé que correlaciona tempos ou um ponto final comprometido, por isso trate-a como uma distribuição diferente do mesmo risco e não como um anonimato que não pode falhar.
| What is known | Tor exit relay | VPN exit server |
|---|---|---|
| Your public address | Seen by the guard relay, not the exit | Seen at the endpoint |
| Final destination | Seen at the exit | Seen at the endpoint |
| Coverage | Applications configured for Tor, chiefly Tor Browser | Whatever the route policy includes |
| Plain HTTP payload | Readable at the exit | Readable at the endpoint |
A cobertura é uma decisão do navegador ou da rota
O navegador Tor encaminha o seu próprio tráfego e acrescenta proteções que um cliente VPN genérico não reproduz: resistência a impressões digitais, isolamento de primeira parte, um tamanho de janela fixo e uma ação de Nova identidade que descarta o estado da sessão. Outras aplicações não usam esse circuito a menos que estejam configuradas para isso, e uma instalação de Tor para todo o sistema é um projeto separado da instalação do navegador.
Uma VPN tem a forma oposta. A cobertura segue a tabela de rotas, por isso um perfil WireGuard com AllowedIPs = 0.0.0.0/0 captura tudo e uma lista de túnel dividido captura apenas os prefixos que nomeia. É nesse mecanismo que também vivem as fugas: consultas DNS, IPv6 e WebRTC podem cada uma seguir um caminho que a política de rotas não incluía. Verifique a partir de dentro da aplicação que falhou, não de um separador do navegador que talvez use outra interface.
Política de portas, destinos bloqueados e HTTPS
Um relé de saída pode recusar portas de saída, e a política predefinida rejeita uma lista de portas propensas a abuso, entre elas a porta SMTP 25. Por isso um cliente de correio configurado através do Tor falha na saída, o que parece uma falha de rede e não é. Os operadores que mantêm um relé definem isso explicitamente:
# torrc — refuse outbound SMTP from this relay
ExitPolicy reject *:25Os destinos também bloqueiam, e bloqueiam os dois sistemas de forma diferente. Os endereços de saída Tor são publicados, pelo que um site pode recusar a lista inteira; os pontos finais VPN ficam em intervalos de centros de dados recusados com a mesma leveza. Quando uma página falha, separe os três candidatos antes de mudar seja o que for: política de saída ou de egresso, um destino que recusa a origem ou um portal cativo que sequestra o primeiro pedido.
Nenhum dos dois sistemas substitui a cifra de transporte. O HTTP simples é legível tanto no relé de saída como no ponto final VPN, por isso mantenha o HTTPS ativo e leia o aviso do certificado em vez de o descartar. Duas verificações resolvem depressa a questão do encaminhamento: curl -s https://check.torproject.org/api/ip devolve IsTor quando o pedido passou por um circuito, e curl -s https://ifconfig.me mostra o endereço de saída que uma VPN apresentaria. Executar ambos diz-lhe que caminho a shell está realmente a usar.
Não use um como o outro
O endereço de um relé de saída não é um perfil VPN. Apontar um cliente OpenVPN ou WireGuard para um relé na porta 443 não cria túnel, porque ali não escuta nenhum serviço VPN; o relé é um salto no circuito de outra pessoa. No sentido inverso, um ponto final VPN não é um ponto de entrada para o Tor, e as definições de pontes do navegador Tor não são um lugar para colar um nome de anfitrião de VPN comercial. Se executar o Tor sobre uma VPN, o guarda vê o endereço da VPN em vez do seu, o que muda a repartição sem fundir os dois papéis.
Antes de escolher, responda a quatro perguntas por ordem: quem opera o ponto final e o que retém, o que a ferramenta cobre neste dispositivo, que portas e destinos a política de saída permite e o que a aplicação acrescenta para além do caminho de rede. Uma tarefa que precisa de acesso de rede comum para muitos programas quer uma VPN. Uma tarefa que precisa das proteções ao nível do navegador e do modelo de circuito quer o navegador Tor, mantido atualizado. Se a resposta for «ambos», execute-os numa ordem deliberada e anote que endereço cada lado vê.