Retransmisor de saída de Tor fronte ao servidor de saída VPN: que sabe cada un
Un retransmisor de saída de Tor e un servidor de saída VPN mostran ambos un enderezo público, pero reparten o coñecemento de forma distinta. Compare visibilidade, cobertura e política de portos.
Ambos deseños agochan o seu enderezo tras unha única IP pública, e un sitio web que imprime o enderezo que ve non pode distinguiros. A diferenza é quen aprende que polo camiño, canto tráfico queda cuberto e que portos poden funcionar. Un retransmisor de saída de Tor é o último salto dun circuíto de tres retransmisores; un servidor de saída VPN termina o seu túnel e fai el mesmo a conexión saínte. Velaquí como decido que sistema necesita unha tarefa e que comprobo antes de supor que un se comporta como o outro.
Dous camiños que terminan nun enderezo
Tor constrúe un circuíto a través dun gardián, un retransmisor intermedio e unha saída, e cifra a carga por capas para que cada retransmisor só descarezca a súa. A saída establece a conexión TCP ordinaria co destino, e por iso o destino ve o enderezo de saída. O seu cliente nunca fala directamente co destino, e o gardián tampouco o ve.
Unha VPN é un túnel cara a un punto final. O servidor do operador elimina o túnel e abre a conexión saínte, así que o destino tamén ve un único enderezo, esta vez o do operador. O resultado observable é o mesmo; o coñecemento non. Unha proba que imprime unha IP responde en que sistema está e nada sobre o reparto de confianza que realmente difire.
Quen acaba sabendo que
O punto final VPN ve o enderezo de orixe, o destino, o momento e o volume nun só lugar. Esa concentración é o deseño: un operador, unha superficie de rexistros, un lugar ao que citar ou mal configurar. Todo o que gaña provén de confiar nesa parte e da política de saída do punto final.
Tor divide ese coñecemento. O gardián coñece o seu enderezo pero non o destino; a saída coñece o destino pero non o seu enderezo. Non se supón que un retransmisor aprenda ambos. É unha propiedade estrutural, non unha promesa contra un observador global, un retransmisor que correlaciona tempos ou un punto final comprometido, así que tráteo como unha distribución distinta do mesmo risco e non como un anonimato que non pode fallar.
| 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 é unha decisión do navegador ou da ruta
O navegador Tor encamiña o seu propio tráfico e engade proteccións que un cliente VPN xenérico non reproduce: resistencia ás pegadas, illamento de primeira parte, un tamaño de xanela fixo e unha acción de Identidade nova que descarta o estado da sesión. Outras aplicacións non usan ese circuíto salvo que estean configuradas para iso, e unha instalación de Tor para todo o sistema é un proxecto aparte de instalar o navegador.
Unha VPN ten a forma oposta. A cobertura segue a táboa de rutas, así que un perfil de WireGuard con AllowedIPs = 0.0.0.0/0 captúrao todo e unha lista de túnel dividido só captura os prefixos que nomea. Aí é onde tamén viven as fugas: as consultas DNS, IPv6 e WebRTC poden tomar cada unha un camiño que a política de rutas non incluía. Compruébeo desde dentro da aplicación que fallou, non desde unha pestana do navegador que quizais use outra interface.
Política de portos, destinos bloqueados e HTTPS
Un retransmisor de saída pode rexeitar portos saíntes, e a política predeterminada rexeita unha lista de portos propensos ao abuso, entre eles o porto SMTP 25. Por iso un cliente de correo configurado a través de Tor falla na saída, o que parece un fallo de rede e non o é. Os operadores que manteñen un retransmisor establéceo explicitamente:
# torrc — refuse outbound SMTP from this relay
ExitPolicy reject *:25Os destinos tamén bloquean, e bloquean os dous sistemas de forma distinta. Os enderezos de saída de Tor son públicos, así que un sitio pode rexeitar toda a lista; os puntos finais VPN están en rangos de centros de datos que se rexeitan coa mesma lixeireza. Cando unha páxina falla, separe os tres candidatos antes de cambiar nada: política de saída ou de egreso, un destino que rexeita a orixe ou un portal cativo que secuestra a primeira petición.
Ningún dos dous sistemas substitúe o cifrado de transporte. O HTTP simple é lexible tanto no retransmisor de saída como no punto final VPN, así que manteña HTTPS activado e lea o aviso do certificado en lugar de descartalo. Dúas comprobacións resolven axiña a cuestión do encamiñamento: curl -s https://check.torproject.org/api/ip devolve IsTor cando a petición pasou por un circuíto, e curl -s https://ifconfig.me mostra o enderezo de saída que presentaría unha VPN. Executar ambas dille que camiño usa realmente a consola.
Non use un como o outro
O enderezo dun retransmisor de saída non é un perfil VPN. Apuntar un cliente OpenVPN ou WireGuard a un retransmisor no porto 443 non crea ningún túnel, porque alí non escoita ningún servizo VPN; o retransmisor é un salto no circuíto doutra persoa. No outro sentido, un punto final VPN non é un punto de entrada para Tor, e a configuración de pontes do navegador Tor non é un lugar onde pegar un nome de host de VPN comercial. Se executa Tor sobre unha VPN, o gardián ve o enderezo da VPN en lugar do seu, o que cambia o reparto sen fusionar os dous papeis.
Antes de escoller, responda catro preguntas en orde: quen opera o punto final e que retén, que cobre a ferramenta neste dispositivo, que portos e destinos permite a política de saída e que engade a aplicación máis alá do camiño de rede. Unha tarefa que necesita acceso de rede ordinario para moitos programas quere unha VPN. Unha tarefa que necesita as proteccións de nivel de navegador e o modelo de circuíto quere o navegador Tor, mantido ao día. Se a resposta é «ambos», execúteos nunha orde deliberada e anote que enderezo ve cada lado.