Si ve alguno de los síntomas a continuación incluso después de encender la VPN, sospeche de una fuga de DNS o de WebRTC. Una filtración ocurre cuando la información que se supone que debe pasar por la ruta VPN abandona esa ruta (también llamada exfiltración).
- La IP del servidor VPN se muestra en la página de verificación de IP, pero el servidor DNS de la empresa de telecomunicaciones o enrutador se muestra en la prueba de DNS.
- La dirección IPv4 ha cambiado, pero la dirección IPv6 es la misma que antes de apagar la VPN.
- En la página de prueba de WebRTC, la IP pública aparece como estaba antes de apagar la VPN.
- La IP original solo es visible inmediatamente después de cambiar de Wi-Fi a datos móviles o despertar del modo de suspensión.
- Activé StageVPN para Chrome, pero otros navegadores y programas de PC se conectan usando la IP original.
- Incluso con la VPN activada, el sitio muestra el idioma y el contenido según la región original (esto puede deberse a la configuración de la cuenta/cookies).
La fuga de DNS es un fenómeno en el que la comunicación web pasa a través del túnel cuando la VPN está activada, pero solo las consultas de DNS salen del túnel y el nombre de dominio es visible para el servidor DNS de la empresa de telecomunicaciones o Wi-Fi. La fuga de WebRTC es un fenómeno en el que el WebRTC del navegador envía una solicitud STUN directamente desde la VPN/proxy, lo que permite que la página web descubra la IP pública real. Ninguno de los fenómenos significa que el contenido de la página se esté filtrando. Sin embargo, revela “quién accede a dónde”. Este artículo comienza con los síntomas y pasa por seis etapas de diagnóstico, resolución por causa y reexamen.
Diagnóstico: Cómo comprobar si hay una fuga en 6 pasos
El principio de la verificación de fugas es comparar los valores con la VPN apagada y encendida. Compare la IP que se muestra en el sitio, el servidor que recibió la consulta DNS y la dirección del candidato WebRTC. Si los valores originales son visibles incluso después de encender la VPN, es una fuga. Las pruebas solo son significativas en los dispositivos y navegadores que realmente utiliza. Incluso si no tiene un sitio de prueba específico, puede verificar la mayoría de las cosas simplemente usando un navegador. La página de verificación de IP es una página web que muestra la dirección IP pública de la persona conectada en la pantalla. Puedes encontrarlo en un buscador como 'Comprobar IP'. Busque la página de prueba de fugas de DNS y la página de prueba de WebRTC de la misma manera. El principio es el mismo sin importar qué página utilices, por lo que no tienes que depender de un sitio específico.
- Apague la VPN y registre su IP. Abra la página de verificación de IP y escriba la dirección IPv4 pública y, si está presente, la dirección IPv6. Este valor es la base para todas las comparaciones posteriores.
- Encienda su VPN y compare IP. Después de verificar el indicador de finalización de la conexión en la aplicación StageVPN o el indicador verde ON en el ícono de StageVPN para Chrome, abra la misma página nuevamente. IPv4 debe reemplazarse con la dirección de su servidor VPN.
- Verifique su servidor DNS. Abra la página de prueba de fugas de DNS. Estas páginas consultan subdominios aleatorios y luego muestran el servidor DNS que envió la consulta. Si puede ver los servidores de su operador o enrutador, es una fuga de DNS.
- Abra chrome://webrtc-internals. Al ingresar esta dirección en la barra de direcciones de Chrome se mostrarán las conexiones WebRTC en curso y las direcciones de los candidatos. El elemento aparecerá si tiene la página de prueba WebRTC o la página de videollamada abierta en otra pestaña.
- Consulta la IP del candidato. Si la dirección del candidato srflx (reflexión del servidor) es la misma que la IP pública original del paso 1, entonces se trata de una fuga de WebRTC. Si es la IP del servidor VPN o solo son visibles el nombre .local y la IP privada, la IP pública no está expuesta.
- Verifique IPv6. Si tenía una dirección IPv6 en el paso 1, encienda la VPN y vea si esa dirección desapareció o cambió. Si este es el caso, IPv6 está saliendo del túnel. Cambie entre Wi-Fi y datos móviles y repita para ver si los resultados son los mismos después de reiniciar el navegador.
| Resultados de la observación | significado | Siguiente causa |
|---|---|---|
| IP del servidor VPN visible en el sitio | Las comunicaciones web pasan por la ruta VPN. | Normal, siguiente paso |
| IPv4 ha cambiado, pero IPv6 es la dirección original | IPv6 sale del túnel | Causa 2 |
| El servidor DNS es de la empresa de telecomunicaciones o del enrutador. | fuga de DNS | Causas 1, 3, 4, 5 |
| El servidor DNS es un proveedor de DNS público | DNS en tu configuración de VPN o un DNS seguro que tú mismo especifiques. | No asuma que es una filtración basándose únicamente en el nombre de la empresa, verifique la causa 4 |
| La IP pública original es visible en WebRTC | Fuga de WebRTC | Causas 6 y 7 |
| Sólo los nombres .local o IP privadas son visibles en WebRTC | La IP pública no está expuesta | generalmente normal |
| IP original solo inmediatamente después del cambio de red | brecha en el momento de la transición | Causa 8 |
Los resultados pueden variar según el sitio de prueba. Hay lugares que solo ven IPv4 y lugares que ven IPv6, y los métodos para encontrar servidores DNS también son diferentes. Compare en más de un lugar y cambiando a múltiples redes.
¿Qué revela una consulta DNS?
Las consultas DNS contienen nombres de dominio. El contenido de la página o los valores ingresados no están incluidos. DNS es el sistema de libreta de direcciones de Internet que convierte los nombres de dominio leídos por humanos en direcciones IP utilizadas por las computadoras. Cada vez que escribe una dirección en su navegador o una aplicación contacta un servidor, su dispositivo primero pregunta al servidor DNS "¿cuál es la dirección de este nombre?" Entonces, con solo mirar el historial de consultas, puede saber mucho sobre cuándo y a qué servicio intentó acceder.
- mi dispositivoAplicación/Navegador
- Consultas DNS de texto sin formato
- Wifi públicoenrutador de cafetería
- Consultas DNS de texto sin formato
- DNS del operadorservidor existente
- Áreas que pueden estar expuestas
- mi dispositivoAplicación/Navegador
- DNS en túnel
- Wifi públicoenrutador de cafetería
- DNS en túnel
- servidor vpnStageVPN
- Consulta por IP del servidor VPN
- servidor DNSEspecificar en la configuración de VPN
- Cifrado VPN
Las consultas DNS tradicionales van al puerto UDP 53 sin cifrar. Para compensar esto, se crearon DoH (RFC 8484), que encapsula consultas en HTTPS, y DoT (RFC 7858), que encapsula consultas en TLS. Sin embargo, incluso si utiliza DNS cifrado, el nombre del servidor (SNI) enviado al conectarse a un sitio a través de HTTPS puede ser visible en la red si el sitio y el navegador no admiten ECH (Encrypted Client Hello).
| método de entrega | Observador en el mismo Wi-Fi | Operador Wi-Fi/empresa de comunicaciones | Servidor DNS que recibe la consulta |
|---|---|---|---|
| DNS simple (texto sin cifrar) | puedo ver | puedo ver | Visible, con mi IP pública |
| DoH/DoT (DNS cifrado) | no puedo ver | No visible, las direcciones del servidor DNS son visibles | Visible, con mi IP pública |
| DNS dentro de un túnel VPN | no puedo ver | No visible, solo ve que se está comunicando con el servidor VPN | Visible, con IP del servidor VPN |
| Estado de fuga de DNS | Si es texto plano, puedes verlo. | puedo ver | Visible, con mi IP pública |
El DNS seguro (DoH) y la VPN tienen propósitos diferentes. DoH solo cifra consultas DNS; el acceso al sitio en sí y las IP que ve el sitio siguen siendo las mismas. Una VPN cifra toda la comunicación entre su dispositivo o navegador y el servidor VPN y cambia la IP que ven los sitios. El modo incógnito tampoco detiene las filtraciones. El modo incógnito es una función que no deja historial ni cookies en el dispositivo, y no cambia las consultas DNS ni las rutas WebRTC.
¿Cómo determina WebRTC una dirección IP?
WebRTC encuentra su propia dirección de varias formas para conectar dos dispositivos a través de la ruta más corta y pasa los resultados al script en la página web. WebRTC es una tecnología estándar web que le permite realizar videollamadas, llamadas de voz y transferencias de archivos sin complementos en su navegador. El proceso de recopilación de direcciones se denomina ICE (RFC 8445). Incluso las páginas que no realizan videollamadas pueden iniciar este proceso con un script.
- Crear objeto de conexiónEl script de la página web crea RTCPeerConnection
- Reunir candidatos localesSu navegador recopila las direcciones de los dispositivos de red de su dispositivo.
- consulta de aturdimientoPregúntele al servidor STUN 'cómo es mi dirección' con UDP
- Entrega de candidatosSe entrega a la página una lista de candidatos que incluye direcciones públicas proporcionadas por el servidor STUN.
| Tipo de candidato | algo | Información que puede ser revelada | Protección de navegadores recientes |
|---|---|---|---|
| anfitrión | Dirección del dispositivo de red de la máquina | IP privada (192.168.x, etc.) | Enmascarado con un nombre .local aleatorio (mDNS), pero se puede ver en sitios que han otorgado permisos de cámara y micrófono. |
| srflx (reflexión del servidor) | Mi dirección pública vista por el servidor STUN | IP pública, IP real si omites el proxy | Puede estar restringido por la política de procesamiento de IP de WebRTC |
| relé | TURN Dirección del servidor de retransmisión | IP del servidor de retransmisión | Si utiliza la retransmisión, la otra parte verá la dirección del servidor en lugar de su IP. |
El problema es la consulta STUN en el paso 3. Los servidores proxy del navegador reenvían solicitudes web, pero las comunicaciones UDP de WebRTC no pasan por el proxy en la configuración predeterminada del navegador. Entonces, la dirección proporcionada por el servidor STUN no es el servidor proxy, sino mi IP pública original. Las cosas son diferentes con las VPN para todo el dispositivo. Dado que toda la comunicación UDP, incluidas las solicitudes STUN, va al túnel, la dirección que ve el servidor STUN es también la IP del servidor VPN.
Proxy del navegador y política predeterminada
- Las solicitudes web pasan por un proxy
- Las solicitudes STUN van directamente a UDP
- La página puede ver la IP pública real.
Proxy del navegador y enable_non_proxied_udp
- Evite que UDP pase por el proxy
- WebRTC solo usa rutas proxy
- Algunas llamadas tienen diferentes métodos de conexión o calidad.
VPN para todo el dispositivo
- Las solicitudes STUN también pasan por el túnel.
- El candidato de dirección pública es la IP del servidor VPN
- La desconexión y el manejo de IPv6 requieren confirmación
Chrome tiene una 'política de manejo de IP de WebRTC' que determina qué dirección utilizará WebRTC y las extensiones pueden cambiar este valor. Cada valor corresponde a cuatro métodos descritos en la Recomendación sobre el manejo de direcciones IP WebRTC del IETF (RFC 8828).
| valor de la política | movimiento | rango de exposición |
|---|---|---|
| por defecto | Recopile candidatos de todos los dispositivos de la red | Más amplio (direcciones locales enmascaradas por mDNS) |
| interfaces_públicas_y_privadas_predeterminadas | Utilice únicamente dispositivos en la ruta predeterminada, utilice direcciones públicas y privadas | No expone direcciones de otros dispositivos |
| default_public_interface_only | Utilice únicamente direcciones públicas de la ruta predeterminada | Las direcciones privadas no están expuestas |
| desactivar_non_proxied_udp | No hay UDP a través de proxy, use TCP a través de proxy si el proxy no admite UDP | No exponer direcciones de rutas fuera del proxy |
Solución: cómo comprobar y solucionar por causa
La mayoría de las fugas tienen una de ocho causas: esto generalmente se debe a configuraciones superpuestas. Comience verificando el número de causa señalado en la tabla de diagnóstico y cada vez que solucione una, repita el paso 6 en la imagen de arriba para ver si el resultado ha cambiado. Si cambia varias configuraciones a la vez, no sabrá qué funcionó.
Causa 1 · No hay ningún servidor DNS en la configuración VPN o el dispositivo utiliza un DNS diferente.
controlar Con la VPN activada, la prueba de DNS muestra el enrutador Wi-Fi o el servidor DNS del operador. A menudo tienes DNS manual en la configuración de Wi-Fi de tu dispositivo.
resolver La aplicación StageVPN incluye un servidor DNS en la configuración de VPN y envía consultas al túnel. Revierta el DNS manual a automático en la configuración de red de su dispositivo, luego desconéctese y vuelva a conectarse a la VPN. Si el problema persiste, verifique las causas 3 y 5.
Causa 2 IPv6 sale del túnel
controlar IPv4 se ha cambiado a la dirección del servidor VPN, pero IPv6 sigue siendo el mismo que el valor escrito en el paso 1. Si la VPN solo hace un túnel IPv4, las consultas y comunicaciones IPv6 saldrán por la ruta original.
resolver La aplicación StageVPN también está configurada para enviar comunicaciones IPv6 al túnel (AllowedIPs 0.0.0.0/0, ::/0), por lo que normalmente no es necesario desactivarla. Si IPv6 todavía aparece como debería, primero verifique si otra aplicación VPN o configuración del dispositivo están cambiando la ruta. Algunos sitios de prueba no admiten IPv6, así que compare en más de un sitio.
Causa 3 · El sistema operativo consulta el DNS de múltiples dispositivos de red simultáneamente.
controlar Especialmente durante una conexión VPN en una PC con Windows, la prueba de DNS muestra tanto el DNS de la VPN como el DNS de su operador. Esto se debe a una función que pregunta a todos los dispositivos de red simultáneamente, como la resolución inteligente de nombres de múltiples inicios de Windows.
resolver Mantenga actualizado su sistema operativo y software VPN y repita las pruebas. Este fenómeno se reporta principalmente con VPN para todo el dispositivo en PC y no ocurre de la misma manera en la aplicación StageVPN en teléfonos inteligentes y StageVPN para Chrome en Chrome debido a diferentes estructuras.
Causa 4 · El DNS seguro (DoH) se especifica por separado en el navegador o dispositivo
controlar La prueba de DNS muestra servidores de proveedores de DNS públicos. En este caso, puede que no se trate de una fuga, sino de una configuración que usted mismo especificó. Si tiene una VPN para todo el dispositivo, esta consulta también pasará por el túnel, pero será recibida por el proveedor especificado en lugar del DNS en su configuración de VPN.
resolver Si esta es la configuración deseada, puede dejarla como está. Si desea utilizar DNS para su configuración de VPN, cambiará automáticamente la configuración de DNS segura en su navegador y dispositivo. Es importante no dar por sentado que se trata de una filtración con sólo mirar el nombre de la empresa.
Causa 5 · Otras aplicaciones VPN, proxy y de seguridad también están activadas
controlar Las funciones de red de otras aplicaciones VPN, extensiones de proxy, filtros de anuncios o programas de seguridad se activan al mismo tiempo. Las configuraciones de ruta se sobrescriben entre sí, lo que hace que algunas consultas vayan a la ruta original.
resolver Encienda sólo uno a la vez. Apague otras aplicaciones y extensiones, desconecte y vuelva a conectar StageVPN y repita el paso 6. La configuración de proxy de Chrome solo puede controlar una extensión a la vez, por lo que si otra extensión usa un proxy, StageVPN para Chrome no se conectará y le dirá por qué.
Causa 6 · Sólo se utiliza el proxy del navegador, pero se espera comunicación fuera del navegador
controlar Activé StageVPN para Chrome, pero otros navegadores, mensajeros de PC y programas de correo se conectan utilizando la IP y el DNS originales. Esto no es una fuga, esta es la gama diseñada. La extensión sólo cubre la comunicación en Chrome.
resolver Si necesita proteger programas fuera de Chrome, use una VPN que se aplique a todo el dispositivo. En los teléfonos inteligentes, la aplicación StageVPN hace precisamente eso. La diferencia de alcance entre los dos métodos es VPN de navegador versus VPN de aplicaciónLo organicé en .
Causa 7 Política WebRTC no aplicada
controlar Activé StageVPN para Chrome y puedo ver la IP pública original en la prueba WebRTC o en el candidato srflx en chrome://webrtc-internals. Si otra extensión o la política de administración de la empresa/organización controla primero la configuración de WebRTC, StageVPN para Chrome no cambiará la política y la dejará como está.
resolver Desactive cualquier otra extensión que controle la configuración de WebRTC y vuelva a conectar StageVPN para Chrome. Si la causa es la política de gestión, póngase en contacto con su administrador. Para escribir en una ventana de incógnito, debes activar 'Permitir en modo incógnito' en la pantalla de administración de extensiones. Cuando está desactivado, las comunicaciones en ventanas de incógnito no pasan por el proxy.
Causa 8 · El momento en que se pierde la conexión VPN
controlar La IP original es visible solo inmediatamente después de cambiar de red o salir del modo de suspensión, y después de un tiempo es normal. Durante la desconexión todas las consultas y comunicaciones salen por la vía normal.
resolver Antes de realizar cualquier trabajo delicado, verifique si el indicador de finalización de la conexión de la aplicación o el ícono de extensión están activados. WireGuard, utilizado por la aplicación StageVPN, no restablece un túnel incluso cuando se cambia de Wi-Fi a LTE, pero el protocolo no puede compensar las desconexiones temporales en la propia red. La capacidad de bloquear automáticamente las comunicaciones cuando se desconecta la VPN no es una característica proporcionada por StageVPN. El principio es Explicando los principios de WireGuardesta en
¿Cómo detienen las fugas las aplicaciones StageVPN y StageVPN para Chrome?
La aplicación StageVPN reduce las fugas al canalizar todas las comunicaciones, mientras que StageVPN para Chrome realiza búsquedas de nombres y ajusta las políticas WebRTC. Dado que el alcance de la protección es diferente, la forma en que se maneja también lo es.
| artículo | Aplicación StageVPN (iPhone·iPad·Android) | StageVPN para Chrome |
|---|---|---|
| rango de protección | Todos los dispositivos | Navegador Chrome |
| Comunicaciones enviadas a través de ruta VPN | IPv4·IPv6 Todo (IP permitidas 0.0.0.0/0, ::/0) | Las solicitudes web pasan a través de proxy (excluyendo bandas de IP privadas y localhost) |
| consultas DNS | Reenvíe dentro del túnel al servidor DNS especificado en la configuración de VPN. | Chrome no busca las solicitudes que pasan a través de un proxy, sino el servidor proxy. |
| WebRTC | Toda la comunicación UDP pasa por el túnel. | enable_non_proxied_udp se aplica durante la conexión y vuelve a la configuración original cuando se desconecta. |
| Lo que ves actualmente en la red | El hecho de que exista comunicación cifrada con el servidor VPN y la cantidad de datos. | Búsqueda de nombres de direcciones de servidores proxy, conexiones cifradas con el proxy y comunicación desde aplicaciones fuera de Chrome |
| Casos que pueden no aplicarse | Mientras se pierde la conexión VPN, cuando otra aplicación VPN se redirige | Ventana de incógnito con Permitir modo de incógnito desactivado cuando otra extensión o política de administración controla la configuración de proxy/WebRTC |
| Historial de acceso (93 días) | Los dominios vistos no se registran | Se registra el nombre del host de destino conectado, pero no se registra la ruta ni el término de búsqueda. |
StageVPN no lo guía a través de un menú de configuración de protección contra fugas de DNS separado como una característica de sus ofertas. El comportamiento anterior depende de la configuración VPN predeterminada de la aplicación y del método de conexión de la extensión. El alcance de la provisión es Características y alcance de la ofertaPuedes consultarlo aquí.
La ausencia de fugas significa que las consultas y las comunicaciones pasan por la ruta VPN en lugar del operador. Esto no significa que no se mantendrán registros. StageVPN conserva los registros de acceso durante 93 días de acuerdo con la Ley de Protección de Secretos de Comunicaciones y no registra el contenido de las comunicaciones. El artículo es Acceder al aviso de almacenamiento de registrosBueno, la razón por la que lo estoy revelando es ¿Por qué divulgamos nuestra política de retención de registros de acceso?explicado.
Lista de verificación de nueva verificación: ¿Qué vuelve a verificar después de realizar cambios?
Cada vez que solucione una causa, verifique los elementos a continuación nuevamente desde el principio. Si todo pasa, no hay fuga. Si algún elemento falla, regresa a la tarjeta de causa correspondiente.
- Después de desconectar y volver a conectar la VPN, verifiqué si la aplicación mostraba la conexión completada o si el ícono de expansión estaba ENCENDIDO.
- En la página de verificación de IP, verá la dirección del servidor VPN tanto para IPv4 como para IPv6, o no verá IPv6.
- La prueba de DNS no muestra el servidor DNS de la empresa de telecomunicaciones o del enrutador.
- El candidato srflx en chrome://webrtc-internals no tiene la IP pública original.
- Las funciones de red de otras aplicaciones VPN, proxies/extensiones VPN y programas de seguridad están desactivadas.
- Si ha configurado DNS manual o DNS seguro para su dispositivo y navegador, ha verificado que esta es la configuración deseada.
- Su sistema operativo, navegador y aplicaciones y extensiones de StageVPN están actualizados.
- El mismo resultado incluso después de cambiar entre Wi-Fi y datos móviles y reiniciar el navegador.
- Si necesita proteger programas fuera de Chrome, puede utilizar una VPN para todo el dispositivo en lugar de una extensión.
También es una buena idea determinar cuándo es necesaria una nueva inspección. Esto es después de una actualización importante de su sistema operativo o navegador, después de instalar una nueva extensión o aplicación de seguridad, o antes de realizar cualquier trabajo confidencial en una red a la que se conecta por primera vez. Si la configuración es la misma pero los resultados han cambiado, la causa suele ser una de estas tres cosas. Una vez que lo domines, las 6 etapas del diagnóstico se pueden completar en solo unos minutos.
Si el problema persiste, organice el modelo del dispositivo, el sistema operativo y la versión de la aplicación, la hora en que ocurrió y los resultados de las pruebas. atención al clientePor favor contáctenos. Por favor no envíe su contraseña o código de verificación. Las configuraciones del dispositivo que se deben verificar junto con la verificación de fugas son: 10 configuraciones de privacidad de teléfonos inteligentesBueno, existen riesgos que no se pueden solucionar solo con una VPN. Lo que las VPN previenen y no pueden prevenirPues tus hábitos en las redes públicas son Reglas de seguridad de Wi-Fi públicoLo organicé en .
material de referencia
- RFC 1034: Nombres de dominio: conceptos e instalaciones — Estructura del DNS y función de los resolutores (IETF)
- RFC 8484: Consultas DNS a través de HTTPS (DoH) — Cómo cifrar consultas DNS a través de HTTPS (IETF)
- RFC 7858: DNS sobre TLS — Cómo cifrar consultas DNS con TLS (IETF)
- RFC 8445: Establecimiento de conectividad interactiva (ICE) — Tipos de candidatos de conexión WebRTC y procedimientos de recopilación (IETF)
- RFC 8828: Requisitos de manejo de direcciones IP WebRTC — Rango de direcciones que los navegadores exponen a WebRTC (IETF)
- API de privacidad de Chrome — Valores de la política de manejo de IP de Chrome WebRTC (Chrome para desarrolladores)
- API chrome.proxy — Configuración de proxy de extensión, lista de omisión y prioridades de control (Chrome para desarrolladores)
- API WebRTC — RTCPeerConnection y el concepto de candidatos ICE (MDN Web Docs)
