Análisis técnico de Turbo VPN para Windows: filtraciones de IPv6, protocolos propietarios y la respuesta del proveedor


Durante nuestras últimas pruebas del cliente de Windows de Turbo VPN, identificamos filtraciones activas de IP y configuraciones de protocolo que comprometen la privacidad de los usuarios. Este informe sintetiza los hallazgos clave, las mejoras implementadas y las áreas que requieren atención continua.

Turbo VPN, propiedad de Innovative Connecting Pte. Limited con sede en Singapur, afirma más de 500 millones de descargas en Android. Aunque la empresa emitió un parche tras nuestros hallazgos técnicos iniciales, la versión 3.6.0.0 siguió filtrando direcciones IPv6 a través de sus protocolos propietarios (Lepus y LinkSentinel) y también en conexiones OpenVPN estándar.

Con evidencia técnica adicional proporcionada por TechRadar, Turbo VPN desplegó una segunda actualización (versión 3.7.0.0) para Windows para corregir las filtraciones persistentes de IPv6. Nuestras pruebas confirman que esta versión bloquea con éxito el tráfico IPv6 no cifrado.

No obstante, la información disponible sobre los protocolos propietarios sigue siendo escasa, y uno de los protocolos (V2Ray) fue eliminado discretamente durante las actualizaciones recientes. Al consultarle sobre su retirada, la empresa indicó a TechRadar que aún estaba verificando el protocolo.

Filtraciones de IP intermitentes

Concebir la reserva de la dirección IP como objetivo principal de una VPN es fundamental. Sin embargo, al iniciar las pruebas de los protocolos propietarios de Turbo VPN en una conexión IPv4 pura esta semana, descubrimos que nuestra IP real no quedaba ocultada en absoluto.

Aunque la app mostraba estar «conectada», cada prueba de búsqueda de IP en línea revelaba nuestra IP real de IPv4. Reiniciamos la máquina, reinstalamos la app y usamos múltiples herramientas de búsqueda independientes, pero los problemas persistieron.

Split screen showing IP leaks with Turbo VPN connected

Captura de pantalla que muestra filtraciones IPv4 con Turbo VPN conectado durante nuestras pruebas iniciales en la versión 3.5.2.0(Imagen: Future)

Para confirmar estos hallazgos, instalamos la app en una segunda máquina en una red dual IPv4/IPv6 separada. Las pruebas en este entorno revelaron un fallo distinto: mientras la dirección IPv4 quedaba enmascarada, la dirección IPv6 real permanecía expuesta.

Pruebas de seguimiento en una conexión solo IPv4 también mostraron que la ocultación de IPv4 se estabilizó, lo que destaca la naturaleza intermitente del fallo de la versión inicial.

Tras compartir estos hallazgos técnicos con el equipo, Turbo VPN lanzó una actualización (versión 3.6.0.0). En nuestra evaluación de esta versión, la app enmascaró las direcciones IPv4 de forma consistente, pero las direcciones IPv6 continuaron expuestas en los protocolos propietarios y en las conexiones OpenVPN estándar.

Considerando que la mayoría de sistemas operativos modernos y navegadores web favorecen las conexiones IPv6 sobre IPv4, no tunelizar o bloquear este tráfico dejaba a los usuarios en conexiones duales expuestos de forma predeterminada.

Tras una actualización subsiguiente emitida hoy, la app de Windows está bloqueando el tráfico IPv6 no cifrado mientras enmascara las direcciones IPv4 de forma consistente.

Screenshot showing IPv6 leaks on Turbo VPN

Captura de pantalla que muestra filtraciones IPv6 en Turbo VPN versión 3.6.0.0(Imagen: Future)

Lepus: ¿VPN o proxy Shadowsocks?

Lepus figura junto a los protocolos VPN estándar de Turbo VPN. Se describe como capaz de ofrecer “camuflaje excelente con velocidad y estabilidad igualmente destacadas, diseñada para redes altamente restringidas”.

Sin embargo, en nuestras pruebas iniciales Lepus operaba de forma distinta a los protocolos VPN habituales. En lugar de crear un túnel cifrado a nivel de sistema, ejecutaba un proceso local de ShadowsocksR (ssr.exe) que modifica la configuración de Windows (ProxyEnable: 1) para ejecutar un proxy local en el puerto 46288.

Eso significa que cualquier dato que no sea de navegador —incluido el tráfico de OS en segundo plano, aplicaciones de mensajería de escritorio y utilidades de línea de comandos— no se beneficiaba de un túnel cifrado y se encaminaba a través de una conexión estándar.

Preguntamos al equipo de Turbo VPN cuánto tiempo podría haber existido este comportamiento, pero no respondieron a esa pregunta específica.

En pruebas posteriores, la versión 3.6.0.0 protegió todo el tráfico saliente en un túnel cifrado y funcionó como túnel a nivel de sistema para tráfico IPv4.

Sin embargo, su configuración seguía permitiendo filtraciones IPv6, lo que significa que los usuarios con una conexión dual quedaban expuestos. Esto se debe a que la app no habilitó interfaces IPv6 virtuales, no asignó rutas de puerta de enlace IPv6 y no estableció reglas de firewall para bloquear el tráfico IPv6 saliente, como se muestra a continuación.

Screenshot showing IPv4 and IPv6 route table while connected to Turbo VPN's Lepus protocol

Captura de pantalla que muestra la tabla de rutas IPv4 e IPv6 durante la conexión al protocolo Lepus de Turbo VPN en la versión 3.6.0.0.(Imagen: Future)

La respuesta oficial y qué esperar

Después de compartir varios rounds de retroalimentación técnica con Turbo VPN, la app de Windows (versión 3.7.0.0) parece haber corregido las filtraciones IPv6 restantes.

En lugar de intentar crear una infraestructura IPv6 completa, la versión más reciente parece haber implementado el bloqueo de IPv6 a nivel de cliente. Esto fuerza todo el tráfico web a través del túnel cifrado IPv4.

Sin embargo, la información detallada sobre los protocolos propietarios continúa ausente tanto dentro de la app como en el sitio web oficial: una búsqueda en el sitio de la empresa no arroja resultados para Lepus ni LinkSentinel. Además, aparte de un descriptor breve en la pestaña de selección de protocolo, a los usuarios no se les ofrece contexto técnico sobre cómo estos protocolos enrutan el tráfico ni qué mecanismos de seguridad emplean. Sumado a la retirada silenciosa de V2Ray, los usuarios quedan con muy poca información sobre cómo garantizar una conexión segura.

La empresa no respondió a preguntas sobre la falta de información acerca de los protocolos propietarios. En respuesta a nuestros hallazgos iniciales, la empresa afirmó: “El comportamiento observado en el cliente de Windows surgió solo en determinadas configuraciones de red, apareciendo en un número limitado de entornos.”

“Tras los puntos que planteó, nuestro equipo técnico realizó una revisión exhaustiva e implementó las mejoras necesarias en la última compilación de Windows en un corto plazo”.

Continuaremos probando el producto y actualizaremos nuestra revisión completa en las próximas semanas.

from Latest from TechRadar https://ift.tt/teJiBnU
via IFTTT IA