VPN dentro de Tor, Tor dentro de VPN: por qué se rompe la cadena
Cuando se apilan una VPN, Tor y un proxy, el orden decide qué se resuelve y qué se transporta. Encuentra la primera frontera rota antes de cambiar los tres.
Apilar una VPN, Tor y un proxy de aplicación se siente como multiplicar la privacidad, y multiplica el número de sitios donde una conexión puede morir. El resultado habitual es un navegador que gira mientras las tres herramientas se declaran sanas. Cambiar las tres configuraciones a la vez elimina entonces la única pista que tenías sobre cuál miente.
Dibuja primero el camino previsto, en orden, nombrando qué programa abre cada conexión y qué nombre se resuelve en cada paso.
Las capas no se suman, interactúan
Una VPN antes de Tor significa que la conexión de entrada del cliente de Tor viaja dentro del túnel. Una VPN transportada a través de Tor significa que el propio punto final del cliente de VPN debe ser alcanzable por Tor, lo que es un requisito muy distinto. El proxy del navegador añade otro salto más que el sistema operativo desconoce. Tres disposiciones, tres listas de dependencias separadas.
Cada disposición cambia qué se puede resolver, qué se puede transportar y quién ve el primer paquete. Solo una de ellas puede ser la configuración que tenías en mente.
Añade también el camino directo al diagrama. Una ruta de reserva, una exclusión de túnel dividido o un atajo del proxy pueden hacer que una página cargue mientras se salta en silencio la cadena que querías probar, y ese éxito engaña más que el fallo.
El orden decide qué se puede transportar
Tor transporta flujos TCP por su interfaz SOCKS, y un cliente que pide al proxy que resuelva el nombre del host mantiene la consulta dentro del circuito. UDP no viaja así en configuraciones normales, por eso un túnel WireGuard no puede anidarse dentro de Tor sin un relé TCP adicional en medio.
OpenVPN se puede forzar a TCP, así que esa disposición al menos es descriptible. También es más lenta y más frágil, y el modo de fallo cuando se rompe se parece a un puerto bloqueado. Espera pasar más tiempo distinguiendo esos dos casos que arreglando cualquiera de ellos.
La resolución es la otra mitad. Con --socks5-hostname el proxy resuelve el destino, mientras que el --socks5 simple pregunta primero al resolutor local y filtra el nombre fuera del circuito. Ese único parámetro decide si la consulta del nombre pertenece a la cadena o a tu proveedor de Internet.
| Order | What must resolve the endpoint | What usually breaks |
|---|---|---|
| VPN, then Tor | The tunnel's resolver | Entry guards blocked by the VPN provider's filters |
| Tor, then VPN | The SOCKS proxy, remotely | UDP transports, which Tor does not carry |
| App proxy on top | The application itself | Proxy bypass rules and cached connections |
Localizar la primera frontera rota
Prueba las etapas en el orden en que viajan los paquetes, con peticiones inofensivas, y detente en la primera que falle. Anota qué comando se ejecutó primero, porque el orden forma parte de la evidencia. Dos comandos separan un circuito muerto de una salida muerta:
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
El primero informa de si una petición llega a completarse a través del proxy SOCKS, y el segundo muestra la dirección que la red presenta ahora mismo. Si el primero falla y el segundo funciona, el problema está en el cliente de Tor o antes. Si ambos funcionan y el navegador sigue fallando, la aplicación usa un camino distinto del de la consola.
Una página de IP pública también describe solo la última salida visible. No puede decir cuántos saltos la precedieron, así que combínala con la salida de estado admitida de cada herramienta en lugar de tratar un solo número como un diagrama.
Cuándo dejar de añadir capas
Si no puedes decir en una frase qué aporta una capa, quítala. Una cadena cuyo propósito no está claro es una cadena que nadie puede depurar a las tres de la madrugada, y la ganancia de privacidad de un salto sin explicación suele ser menor que la disponibilidad que pierdes.
Si una capa sí se gana su sitio, pruébala sola primero, luego añade la siguiente y confirma el camino otra vez con los mismos dos comandos. Restaura la cadena completa antes del uso normal y mantén la validación TLS y la autenticación activadas; un aviso de certificado aceptado para que cargue una página es un rodeo de enrutamiento, no una reparación. Anota el orden que elegiste mientras lo tienes fresco.
Escribe ese orden, incluido el resolutor que responde en cada etapa. Una cadena que funciona y que puedes describir sobrevive a la próxima actualización, mientras que una cadena que funciona y que montaste probando desaparece con ella. Añade la fecha y las versiones, para que un fallo posterior pueda compararse con un estado conocido bueno en lugar de discutirse de memoria. Diez líneas en un archivo de texto ahorran una tarde de conjeturas.