¿Pasa Tor por la VPN? Qué cambia el túnel dividido
Un icono de VPN conectada y un proceso de Tor en marcha no demuestran que la conexión de entrada de Tor usara el túnel. Comprueba la regla de división y luego la ruta de fallo.
He aquí la creencia que merece ponerse a prueba: un indicador conectado significa que el tráfico de Tor pasó primero por la VPN. La inferencia falla más a menudo de lo que debería, y falla en silencio. Un emparejador de túnel dividido puede dejar el proceso de Tor fuera del túnel mientras el dispositivo sigue conectado, y ambas observaciones son ciertas a la vez. El icono informa de una interfaz; la ruta que siguieron tus paquetes es una pregunta aparte. Respóndela desde el enrutamiento y el emparejador, no desde el indicador.
Qué demuestra un indicador conectado y qué no
Una VPN conectada significa que una interfaz está activa y que existe un túnel hacia el par. La conexión de entrada de Tor es otro flujo, creado por otro proceso, y si entra en ese túnel depende del emparejador y de la tabla de enrutamiento que se le apliquen. Excluye el proceso y la VPN se conecta igualmente, Tor sigue construyendo un circuito, y el orden que pretendías no ha ocurrido. Las dos observaciones responden a preguntas distintas, y por eso ninguna por sí sola resuelve el orden.
Ese hueco no es un fallo de ninguna de las dos herramientas. Es justo para lo que sirve una regla de exclusión, y la regla probablemente se escribió por un motivo que alguien todavía recuerda.
Qué emparejador aplica el cliente a una conexión
Lo que decide la ruta es el emparejador que el cliente aplica a cada conexión: un nombre de proceso, un prefijo de destino o una entrada de ruta, según el cliente. Un acceso directo del escritorio no coincide con ninguno de ellos, porque es un lanzador, no una unidad de política. Lee el conjunto de reglas del cliente y nombra la unidad que realmente comprueba antes de razonar sobre Tor. Si el cliente empareja por destino, la pregunta pasa a ser qué prefijos quedan dentro del túnel y no qué programa se está ejecutando.
Una regla basada en el destino que solo lleva prefijos de oficina privada es una forma habitual, y deja las conexiones de entrada ordinarias de Tor directas por diseño. Eso es la política funcionando tal como está configurada, y no es el orden VPN-antes-que-Tor por muy sano que se vea el indicador. Escribe el emparejador y los prefijos excluidos en la misma línea de tus notas, porque ese par es la regla.
Qué le pasa a Tor cuando cae el túnel
Ahora quita el túnel y observa qué hace Tor, porque una política que solo se sostiene mientras la red está sana no es la política que describiste. El cliente puede rechazar el tráfico directo mientras está caído, permitirlo en silencio o reconectarse y reaplicar la regla un momento después. Una desconexión manual y una caída son sucesos distintos, y la caída es la que nadie ha ensayado. Prueba con tráfico inofensivo y anota cuál de los tres resultados has observado realmente.
Lee también el comportamiento documentado del cliente, pero trata la documentación como una hipótesis hasta que tu prueba esté de acuerdo con ella. Los proveedores describen el valor por defecto; tu perfil decide la excepción.
Por qué la dirección de salida no puede responder a la pregunta de entrada
Un sitio alcanzado a través de Tor informa de la dirección del repetidor de salida, lo que te dice de dónde emergió el circuito y nada sobre cómo el primer salto abandonó tu dispositivo. La gente cita esa dirección como prueba del orden VPN-primero, y no puede soportar ese peso. La pregunta de entrada es local: qué interfaz llevó la conexión hasta el primer repetidor y qué dirección de origen habría visto el par de la VPN. Respóndela con una consulta de ruta o una captura de paquetes en el dispositivo, no con un sitio web.
Dos rutas distintas pueden producir el mismo país de salida, así que un resultado coincidente demuestra aún menos de lo que parece. Compara interfaces, no geografía.
Aplicaciones que nunca heredaron la configuración del navegador
Un visor de documentos, un cliente de sincronización y un gestor de paquetes hacen cada uno sus propias conexiones, y ninguno hereda la configuración de proxy del navegador. Cada uno sigue el emparejador del cliente, su propia configuración o el proxy del sistema, y la combinación rara vez se escribe. Así crece una lista de excepciones: una aplicación cada vez, cada adición razonable, hasta que nadie puede decir qué cubre la lista. Mejor lleva un diagrama breve por aplicación, que nombre el emparejador, la ruta y el comportamiento ante fallos.
Si la capa extra de VPN no sirve a ningún propósito que puedas enunciar, quitar la capa es más fácil de verificar que mantener una lista larga de excepciones. Mientras tanto, la nota del Proyecto Tor sobre las VPN aborda la misma cuestión de orden desde el otro lado. Menos piezas móviles significa menos suposiciones que volver a probar tras la próxima actualización del cliente.