Tor o VPN: decide por quién te obliga a confiar cada camino
Una VPN acumula tu confianza en un solo operador; Tor la reparte entre repetidores. Decide por la cobertura, por quién puede vincularte a un sitio y por lo que puedes verificar.
Elegir entre Tor y una VPN se reduce a qué parte puedes tolerar que vea los dos extremos de una conexión. Una VPN concentra esa visión en un operador que elegiste. Tor la reparte entre repetidores, así que ningún repetidor individual debe llegar a saber quién eres y qué descargaste.
Ninguna de las dos disposiciones te vuelve anónimo por sí sola. Elige la que te permita nombrar en voz alta la confianza que le queda y luego corrige las partes que deja al descubierto.
Cuenta quién puede vincularte a un destino
Con una VPN, cada flujo cubierto llega a la salida del operador antes de llegar al destino. Ese operador ve necesariamente tu dirección de origen y, para todo lo que no esté cifrado a través de él, el destino que pediste. TLS mantiene el contenido de la página fuera de esa visión, pero suele dejar visible el nombre de host mientras se establece la conexión. Una parte puede, por tanto, vincularte a un sitio, y ese vínculo es precisamente la confianza que otorgas.
Tor separa esas mitades entre tres repetidores: un guardián que conoce tu dirección pero no tu destino, un repetidor intermedio que no conoce ninguno de los dos extremos y una salida que conoce el destino pero no a ti. El diseño supone que ningún repetidor combina ambos hechos, lo que es una suposición más débil y más útil que confiar en una sola empresa. No supone que los repetidores sean honestos y no derrota a un observador que vigila ambos extremos del camino.
Ambos diseños comparten un punto débil, y se encuentra en el destino. Si inicias sesión, el servicio vincula esa sesión a tu cuenta sea cual sea la ruta que tomaron los paquetes. El enrutamiento cambia de dónde parece venir una petición, no lo que la página te pide proporcionar.
La cobertura importa más que el diagrama de enrutamiento
Una VPN enruta en la capa de red, así que cada aplicación del dispositivo hereda el túnel a menos que la excluyas a propósito. Esa amplitud es la razón por la que funciona a la vez para un cliente de correo, un gestor de paquetes y un navegador.
El navegador Tor es un paquete, y sus protecciones viven sobre todo dentro del navegador: una huella uniforme, aislamiento entre sitios y scripts limitados por un nivel de seguridad en lugar de por las extensiones que hayas instalado. Señalar Chrome a un puerto SOCKS compra el enrutamiento sin nada de eso, que es una fuente habitual de confianza mal colocada.
El resto del escritorio queda intacto. Un cliente de sincronización, un actualizador o un documento descargado abierto en otro programa se conecta como esté configurado ese programa, y nada de eso pasa por el escucha SOCKS a menos que lo configures allí. Enumera las aplicaciones que hablan con la red y luego pregunta cuáles cubre realmente la herramienta elegida. La cobertura es una propiedad de tu configuración, no de tu intención.
Elige con tres condiciones
La decisión suele resolverse con tres preguntas: ¿el tráfico viene de una aplicación o de todo el dispositivo, debe el destino ser incapaz de identificar tu dirección y necesitas llegar a una red privada? Respóndelas en ese orden y la herramienta casi siempre se elige sola.
| Requirement | Better fit | Reason |
|---|---|---|
| Every app covered, including non-browser traffic | A device VPN | Routing happens below the application, with a kill switch to stop leaks |
| Destination must not learn your address | Tor | The site sees a shared exit address rather than one tied to your account |
| Browser fingerprint that blends in | Tor Browser | The uniformity ships with the browser, a proxy alone adds none of it |
| Access to a private subnet or office resource | A VPN | Tor exits reach the public internet, not your internal routes |
Donde dos requisitos entran en conflicto, sopesa cuál puedes imponer. Un túnel de dispositivo con una lista de exclusiones con fugas es peor que una ruta solo de navegador que puedas demostrar.
La verificación es barata para ambos caminos, y debería ocurrir antes de que confíes en cualquiera de los dos:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
Un resultado falso del primer comando significa que la petición salió fuera del circuito, que es el fallo que merece la pena atrapar pronto. Compara el segundo con la dirección que te asignó tu proveedor, no con la que recuerdas de la semana pasada.
Lo que no repara ninguna de las dos opciones
El cifrado de aplicaciones sigue haciendo un trabajo que ninguna ruta realiza. El HTTP simple que cruza una red de privacidad sigue siendo legible en la salida, y HTTPS sigue siendo lo único que protege la carga de extremo a extremo. TLS tampoco dice nada sobre el nombre de host que escribiste, por lo que el destino sigue visible para quien termina el camino.
Las cuentas te identifican, y ninguna elección de enrutamiento cambia eso: el servicio sabe quién inició sesión independientemente de la dirección en la cabecera. La correlación por parte de un observador que ve suficiente red, el compromiso de tu propio dispositivo y todo lo que escribes en un formulario sobreviven a ambos diseños. Trata ambas herramientas como formas de mover la confianza, no de eliminarla.
Empieza por la configuración predeterminada que documenta cada proyecto, confirma la ruta con los dos comandos anteriores y solo entonces considera apilar una VPN bajo Tor. Anidarlas es una configuración con sus propios modos de fallo, no una actualización gratuita.