Comprueba IPv4 e IPv6 al verificar tu VPN

Una página de dirección pública puede mostrar una IPv4 distinta después de conectar la VPN y aun así dejar una pregunta importante sin respuesta: ¿qué ocurre cuando una aplicación utiliza IPv6? Muchas conexiones cotidianas admiten más de una familia de direcciones, mientras que algunas redes solo ofrecen una. Una verificación útil comprueba qué está disponible y qué debe hacer la configuración elegida. El objetivo no es forzar IPv6 en todas partes ni desactivarlo siempre, sino evitar tratar una solicitud correcta como descripción completa de todas las rutas posibles del dispositivo.

Empieza las pruebas IPv6 con un resultado esperado

Pregunta si el cliente y la configuración deben transportar IPv6, bloquearlo fuera del túnel o utilizar otra disposición documentada. Son políticas diferentes. La ausencia de un resultado IPv6 puede ser normal en una configuración y un fallo en otra. Sin conocer el comportamiento previsto, resulta difícil interpretar la prueba.

La dirección del servidor y el tráfico dentro del túnel son conceptos distintos. Conectar con un servidor VPN mediante una dirección IPv4 no determina por sí solo las familias que puede transportar el túnel. Del mismo modo, ver un servidor con IPv6 no demuestra que todas las aplicaciones vayan a utilizar IPv6 después. La capacidad depende de la configuración completa y de la red que la rodea.

Consulta las instrucciones del protocolo y del cliente antes de editar nada. La comparación de VLESS y WireGuard ayuda a identificar el tipo de configuración, pero el nombre de un protocolo no constituye una política de enrutamiento. Registra la aplicación, la versión, la configuración seleccionada y si hay túnel dividido o excepciones locales.

Determina qué ofrece la red habitual

Cuando sea apropiado realizar una comparación sin VPN y sin datos sensibles, comprueba si la red subyacente dispone de IPv4, IPv6 o ambos. No desconectes un túnel laboral obligatorio ni expongas actividad sensible solo para obtener una referencia. Si la política impide comparar, registra esa limitación y solicita al administrador un método autorizado.

Utiliza un diagnóstico que informe por separado sobre las familias de direcciones. Una página que muestra una sola dirección puede haber utilizado simplemente la primera ruta operativa. La especificación Happy Eyeballs del IETF describe cómo las aplicaciones prueban direcciones o familias alternativas para reducir la demora de conexión. Esto mejora la experiencia, pero cargar una página correctamente no demuestra necesariamente que ambas rutas funcionen.

Relaciona la observación con la red real. Un resultado con el Wi-Fi doméstico no describe los datos móviles, y un portátil conectado mediante el teléfono no equivale necesariamente al propio teléfono. Anota el método de acceso y la hora. Si IPv6 aparece como no disponible, no inventes una dirección ni clasifiques su ausencia como fuga solo para completar una tabla.

Repite las observaciones con el túnel activo

Conecta la configuración prevista y realiza solicitudes nuevas desde el mismo dispositivo y aplicación. Registra por separado IPv4 y, cuando esté disponible, IPv6. Anota los fallos como fallos, en lugar de descartarlos porque otra página haya cargado. Mantén el mismo servidor durante la comparación.

Una prueba de navegador mide las solicitudes de ese navegador. Si importa otra aplicación, utiliza un diagnóstico adecuado o solicítalo a soporte. Las excepciones, los proxies del sistema y la conexión específica de cada aplicación pueden modificar el alcance. La guía del estado de la VPN explica por qué el indicador de conexión es un punto de partida, no una prueba de cada conexión posterior.

Si un resultado parece mostrar la dirección del proveedor habitual donde esperabas una ruta protegida, deja de usar esa configuración para tareas sensibles hasta revisar la política. Conserva la observación en privado y descríbela con precisión. No publiques configuraciones completas ni claves junto con una prueba de dirección. Soporte suele necesitar primero el cliente y el comportamiento esperado, antes que cualquier dato secreto de acceso.

Interpreta las direcciones con más cuidado que las etiquetas de país

Una consulta de dirección puede asociar una organización o un país a la dirección observada. Esas etiquetas aportan contexto, pero no miden de forma definitiva la ubicación física. Las bases de datos pueden discrepar y clasificar de manera distinta IPv4 e IPv6 asociados al mismo servicio.

Para verificar el enrutamiento, compara las direcciones observadas con lo que el proveedor espera de esa configuración. Trata el comportamiento geográfico como otra cuestión. El artículo sobre país de la VPN e idioma de la web explica por qué la preferencia de idioma de un sitio no resuelve el asunto por sí sola. Una interfaz rusa o una búsqueda en inglés no sustituye una comprobación de familias de direcciones.

Utiliza un registro sencillo con cuatro entradas: IPv4 habitual, IPv6 habitual, IPv4 por el túnel e IPv6 por el túnel. Marca expresamente los campos no disponibles o no probados. Añade debajo la política prevista. Este formato permite distinguir una familia no compatible, una ruta directa inesperada y una discrepancia geográfica sin resumir las tres como «la VPN está rota».

No repares rutas adivinando campos de configuración

No añadas ni elimines rutas amplias únicamente porque aparezcan en un ejemplo de un foro. La documentación VPN de Android, por ejemplo, describe rutas separadas para cubrir todos los destinos de IPv4 e IPv6. Esos ajustes determinan qué destinos entran en la interfaz virtual; no son líneas decorativas que puedan copiarse sin entender el resto.

La misma cautela se aplica a los archivos importados manualmente. Un cambio de enrutamiento puede afectar al acceso al DNS, los servicios locales y la capacidad de reconectar. Guarda de forma segura el archivo original que funcionaba y utiliza la configuración admitida por el proveedor para tu cliente. Nunca publiques una configuración para preguntar si una sola línea es correcta.

Si la solución compatible bloquea deliberadamente una familia no disponible, verifica ese comportamiento mediante los controles documentados del cliente. Desactivar IPv6 en todo el sistema operativo o router puede afectar a otras aplicaciones y personas. Hazlo solo con una razón clara y la autoridad adecuada, no como remedio universal para un resultado inexplicable de una única web.

Vuelve a comprobar al cambiar de red de acceso

El resultado del Wi-Fi de ayer no garantiza el mismo comportamiento en la red móvil de hoy. Repite la pequeña observación tras una actualización importante del cliente, un cambio de configuración o un cambio del método de acceso que utilizas. No necesitas pruebas interminables de un sistema sin cambios; céntrate en las transiciones que pueden modificar las rutas disponibles.

Si el caso sigue sin resolverse, envía a la ayuda de Lumeraya la versión del cliente, el tipo de red, la política esperada y los resultados separados de ambas familias. Indica si fue posible obtener una referencia sin VPN. No incluyas claves privadas ni afirmes que existe un fallo general cuando solo has probado una aplicación.

Una comprobación clara de ambas familias termina con una conclusión acotada: la ruta IPv4 observada actuó como se esperaba, IPv6 también o estaba deliberadamente no disponible, y las incertidumbres restantes están identificadas. Eso es más útil que una sola dirección tranquilizadora, porque vincula el resultado con la configuración real y el tráfico que quieres proteger.