VPN a través de Tor: primero la comprobación del transporte

Tor primero significa que el cliente VPN se sitúa detrás de un proxy SOCKS, así que el túnel mismo se construye a través de Tor y el tráfico de las aplicaciones sale del punto final de la VPN. Ese es un orden concreto y no es lo que construye la mayoría de la gente. Abrir Tor Browser junto a un cliente VPN normal no obliga a ninguno de los dos programas a usar la ruta del otro.

Recorra las comprobaciones en orden. Cada una decide si vale la pena empezar la siguiente.

Qué orden está construyendo en realidad

Dos órdenes se confunden en la misma conversación. Tor primero significa que el cliente VPN llega a su servidor a través de un proxy SOCKS, así que el túnel se construye sobre Tor. VPN primero significa que el tráfico de Tor sale por el túnel, que es lo que la mayoría construye por accidente y luego describe como el otro. El primero concentra la frontera de reenvío en el operador de la VPN, el segundo la concentra en la entrada y la salida de Tor. Ninguno de los dos es lo que se obtiene al tener ambas aplicaciones abiertas a la vez.

Anote qué orden necesita la tarea antes de configurar nada, porque los dos requieren ajustes de software distintos y fallan en lugares distintos. Un orden mal etiquetado le envía a depurar la capa equivocada durante una hora. Todo lo siguiente supone Tor primero.

Compruebe el transporte antes que nada

La interfaz SOCKS de Tor transporta flujos TCP y no ofrece una asociación UDP general. Una VPN cuyo transporte sea UDP no puede tratar ese proxy como una interfaz de red ordinaria, y ningún ajuste del cliente cambia lo que el proxy está dispuesto a reenviar. WireGuard en su forma habitual es la víctima obvia. Un perfil de OpenVPN en modo TCP es la solución habitual, y aun así hay que decirle explícitamente que use el proxy.

ss -lntp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 -o /dev/null -w '%{http_code}\n' https://example.com

Confirme que el proxy escucha y puede transportar una petición HTTPS simple antes de depurar un túnel a través de él. Si la petición simple falla, el cliente VPN nunca tendrá éxito y sus registros no le dirán por qué.

Reescriba el mapa del observador

La entrada de Tor puede ver la fuente que se conecta a Tor a menos que algo anterior la haya cambiado, así que ese salto aprende su dirección. El proveedor de la VPN recibe una conexión que llega del lado de Tor, pero aún puede conocer una cuenta, un registro de pago o una credencial que usted envió dentro del túnel. Los destinos alcanzados a través de la VPN ven su salida en lugar de la salida de Tor, y eso concentra la frontera final de reenvío en un solo operador.

Tampoco recrea una ruta distribuida hacia cada destino. Tor Browser construye un circuito nuevo por sitio; una VPN llevada sobre Tor construye un solo túnel, y cada sitio detrás de él comparte ese punto final. Trate la diferencia como un hecho de diseño y no como una limitación que haya que eliminar.

Cuente las capas de fallo cuando se rompe

Una configuración rota tiene al menos cuatro capas independientes: la conexión SOCKS, el intercambio TLS con el servidor de la VPN, el propio intercambio de la VPN y luego el enrutamiento o la resolución de nombres dentro del túnel. Cada una falla con un síntoma distinto y cada una necesita una reparación distinta. Aflojar las comprobaciones de certificados porque el túnel no levanta es el diagnóstico erróneo clásico, y convierte un problema de transporte en uno de seguridad.

Registre la primera capa que falle y deténgase ahí. Un rechazo del proxy y una clave rechazada no son variaciones del mismo suceso.

Deténgase si el modelo de amenaza necesita las defensas de Tor Browser

Enrutar aplicaciones arbitrarias por una VPN llevada por Tor no da a esas aplicaciones las funciones de huella y aislamiento de Tor Browser. Sus cuentas, identificadores y comportamiento de red propio siguen siendo relevantes, y un túnel no normaliza ninguno de ellos. Si el objetivo es un navegador que se mezcle con otros usuarios, este orden no lo ofrece.

El propio Tor Project advierte contra combinaciones que los usuarios no pueden configurar correctamente, y esta vale para la mayoría de la gente. Es un diseño deliberado para un modelo de amenaza estrecho, no un atajo hacia el tráfico anónimo de todo el dispositivo.