Relé de salida de Tor frente a servidor de salida VPN: qué sabe cada uno

Ambos diseños ocultan su dirección tras una única IP pública, y un sitio web que imprime la dirección que ve no puede distinguirlos. La diferencia es quién aprende qué por el camino, cuánto tráfico queda cubierto y qué puertos pueden funcionar. Un relé de salida de Tor es el último salto de un circuito de tres relés; un servidor de salida VPN termina su túnel y realiza él mismo la conexión saliente. Así decido qué sistema necesita una tarea y qué compruebo antes de suponer que uno se comporta como el otro.

Dos caminos que terminan en una dirección

Tor construye un circuito a través de un guardián, un relé intermedio y una salida, y cifra la carga por capas para que cada relé solo descortece la suya. La salida establece la conexión TCP ordinaria con el destino, y por eso el destino ve la dirección de salida. Su cliente nunca habla directamente con el destino, y el guardián tampoco lo ve.

Una VPN es un túnel hacia un punto final. El servidor del operador elimina el túnel y abre la conexión saliente, así que el destino también ve una sola dirección, esta vez la del operador. El resultado observable es el mismo; el conocimiento no. Una prueba que imprime una IP responde en qué sistema está y nada sobre el reparto de confianza que realmente difiere.

Quién acaba sabiendo qué

El punto final VPN ve la dirección de origen, el destino, el momento y el volumen en un solo lugar. Esa concentración es el diseño: un operador, una superficie de registros, un lugar al que citar o mal configurar. Todo lo que gana proviene de confiar en esa parte y de la política de salida del punto final.

Tor divide ese conocimiento. El guardián conoce su dirección pero no el destino; la salida conoce el destino pero no su dirección. No se supone que un relé aprenda ambos. Es una propiedad estructural, no una promesa contra un observador global, un relé que correlaciona tiempos o un punto final comprometido, así que trátelo como una distribución distinta del mismo riesgo y no como un anonimato que no puede fallar.

La cobertura es una decisión del navegador o de la ruta

El navegador Tor enruta su propio tráfico y añade protecciones que un cliente VPN genérico no reproduce: resistencia a las huellas, aislamiento de primera parte, un tamaño de ventana fijo y una acción de Identidad nueva que descarta el estado de la sesión. Otras aplicaciones no usan ese circuito salvo que estén configuradas para ello, y una instalación de Tor para todo el sistema es un proyecto aparte de instalar el navegador.

Una VPN tiene la forma opuesta. La cobertura sigue la tabla de rutas, así que un perfil de WireGuard con AllowedIPs = 0.0.0.0/0 lo captura todo y una lista de túnel dividido solo captura los prefijos que nombra. Ahí es donde también viven las fugas: las consultas DNS, IPv6 y WebRTC pueden tomar cada una un camino que la política de rutas no incluía. Compruébelo desde dentro de la aplicación que falló, no desde una pestaña del navegador que quizá use otra interfaz.

Política de puertos, destinos bloqueados y HTTPS

Un relé de salida puede rechazar puertos salientes, y la política predeterminada rechaza una lista de puertos propensos al abuso, entre ellos el puerto SMTP 25. Por eso un cliente de correo configurado a través de Tor falla en la salida, lo que parece un fallo de red y no lo es. Los operadores que mantienen un relé lo establecen explícitamente:

# torrc — refuse outbound SMTP from this relay
ExitPolicy reject *:25

Los destinos también bloquean, y bloquean los dos sistemas de forma distinta. Las direcciones de salida de Tor son públicas, así que un sitio puede rechazar toda la lista; los puntos finales VPN están en rangos de centros de datos que se rechazan con la misma ligereza. Cuando una página falla, separe los tres candidatos antes de cambiar nada: política de salida o de egreso, un destino que rechaza el origen o un portal cautivo que secuestra la primera petición.

Ninguno de los dos sistemas sustituye el cifrado de transporte. El HTTP simple es legible tanto en el relé de salida como en el punto final VPN, así que mantenga HTTPS activado y lea el aviso del certificado en lugar de descartarlo. Dos comprobaciones resuelven rápido la cuestión del enrutamiento: curl -s https://check.torproject.org/api/ip devuelve IsTor cuando la petición pasó por un circuito, y curl -s https://ifconfig.me muestra la dirección de salida que presentaría una VPN. Ejecutar ambas le dice qué camino usa realmente el intérprete de comandos.

No use uno como el otro

La dirección de un relé de salida no es un perfil VPN. Apuntar un cliente OpenVPN o WireGuard a un relé en el puerto 443 no crea un túnel, porque allí no escucha ningún servicio VPN; el relé es un salto en el circuito de otra persona. En el otro sentido, un punto final VPN no es un punto de entrada para Tor, y la configuración de puentes del navegador Tor no es un lugar donde pegar un nombre de host de VPN comercial. Si ejecuta Tor sobre una VPN, el guardián ve la dirección de la VPN en lugar de la suya, lo que cambia el reparto sin fusionar los dos papeles.

Antes de elegir, responda cuatro preguntas en orden: quién opera el punto final y qué retiene, qué cubre la herramienta en este dispositivo, qué puertos y destinos permite la política de salida y qué añade la aplicación más allá del camino de red. Una tarea que necesita acceso de red ordinario para muchos programas quiere una VPN. Una tarea que necesita las protecciones de nivel de navegador y el modelo de circuito quiere el navegador Tor, mantenido al día. Si la respuesta es «ambos», ejecútelos en un orden deliberado y anote qué dirección ve cada lado.