Si el VPN dejó de conectarse de repente, no se apresure a reinstalar todo. La mayoría de las "averías" no son fatalidades, sino la combinación de dos o tres causas pequeñas: internet inestable, conflicto de configuraciones, la MTU incorrecta o certificados "desordenados". A continuación hay una lista de comprobación detallada pero práctica para una autodiagnosis ordenada. Sin magia, solo observación, secuencia y un poco de sentido del humor. Al final también hay importantes descargos sobre el uso responsable y legal.
1. Primero detente y describe el síntoma: qué exactamente "no funciona"
Empieza por formular el problema en lenguaje claro: "El cliente se conecta, pero las páginas no se abren", "La conexión se queda en la fase 'Handshaking'", "Funciona por Wi‑Fi pero no por móvil", "Se conecta, pero pierde la conexión a los 30 segundos". Esa concreción ahorra horas y ya indica una dirección para la búsqueda.
Luego verifica el contexto. ¿Has cambiado la contraseña/las claves, actualizado el cliente, caducó la suscripción del proveedor, activaste funciones experimentales (split tunneling, kill switch, Always‑on, IPv6, DNS "inteligentes")? A veces la causa es un interruptor diminuto que activaste camino al café.
Reúne el conjunto mínimo de hechos: tipo de protocolo (WireGuard, OpenVPN, IKEv2), plataforma (Windows/macOS/Linux/iOS/Android), red (router doméstico, Wi‑Fi corporativo, LTE), hora de inicio del fallo. Además una captura del error o el texto del registro — aunque sea en "Notas".
Y lo último en este bloque: prueba otro servidor/ubicación del mismo proveedor. Si un servidor está "rojo" y el vecino "verde", probablemente el problema no sea tu equipo. Si todos están rojos, seguimos con la lista de verificación.
2. Comprobación de red básica: ¿internet funciona? ¿DNS responde? ¿hay ruta?
El VPN es solo una "tubería". Primero asegúrate de que la red del dispositivo esté bien. Abre cualquier sitio "pesado" sin VPN (por ejemplo, un portal con imágenes): si tarda mucho, hay que arreglar la conexión. En Wi‑Fi público con autenticación visita http://neverssl.com o simplemente prueba una página sin cifrar; puede aparecer un portal cautivo.
Luego comprueba si responde con ping una dirección externa. La prueba más simple hacia un resolvedor DNS público:
# Windows PowerShell
Test-Connection 1.1.1.1 -Count 4
# o
Test-NetConnection 1.1.1.1 -InformationLevel Detailed
# Linux / macOS
ping -c 4 1.1.1.1
traceroute 1.1.1.1 # Linux
traceroute -I 1.1.1.1 # ICMP, si se filtra UDP
Si llegas al IP pero no a los nombres de dominio, el culpable es el DNS. Temporalmente configura en el dispositivo o en el router un resolvedor público (por ejemplo, 1.1.1.1) y verifica si cambia el comportamiento. Esto no "arregla" el VPN para siempre, pero ayuda a detectar si el problema es la red, el DNS o el propio túnel.
Para los meticulosos: una comprobación rápida de puertos. Si usas OpenVPN‑UDP 1194 o WireGuard‑UDP 51820, verifica que la red no bloquee UDP en general: Test-NetConnection vpn.example.com -Port 1194 (Windows) o nc -vz vpn.example.com 1194 (comprobación TCP del puerto como indicio indirecto de disponibilidad del host).
3. Cliente y protocolo: desde credenciales básicas hasta "qué pasa con la hora"
Problema n.º 1 — credenciales. Para OpenVPN/IKEv2 verifica usuario/contraseña, la validez de los certificados y que no esté activado accidentalmente el bloqueo de mayúsculas. Para WireGuard asegúrate de que la clave privada no se haya generado de nuevo sin actualizarse en el servidor: los pares de claves deben coincidir.
Problema n.º 2 — hora desajustada. Una diferencia en el reloj del sistema respecto al servidor de varios minutos rompe TLS e IKE. Sincroniza la hora (NTP) y vuelve a intentar. Suena simple, pero soluciona más casos de los que quisiéramos admitir.
Problema n.º 3 — conflicto de modos. El kill switch puede bloquear todo el tráfico si falla el apretón de manos, el split tunneling desvía una aplicación "fuera" del túnel, y Always‑on en Android no dejará pasar tráfico sin un VPN activo. Desactiva temporalmente todas las funciones "inteligentes" y deja una conexión limpia: si conecta, activa las funciones de una en una.
Sobre protocolos. WireGuard suele o "volar" o no conectar silenciosamente — revisa claves, direcciones, la MTU y UDP. OpenVPN tiene flags útiles para proteger el canal de control ( tls‑crypt v2), y un análisis detallado de fallos en su guía de depuración. Para IKEv2 (strongSwan, clientes integrados) a menudo el problema es la fragmentación de paquetes grandes en la etapa IKE_AUTH y el filtrado de fragmentos — esto tiene que ver con la MTU, que se explica más abajo.
Y, por favor, actualiza el cliente. Las versiones antiguas de OpenVPN/WireGuard/drivers de adaptadores virtuales con frecuencia dejan de funcionar después de actualizaciones del sistema operativo.
4. Tres enemigos invisibles: la MTU, el DNS y el DPI
La MTU. Una MTU demasiado grande provoca cortes invisibles: el túnel "sube" pero la mitad de los sitios no carga. Comprueba el tamaño seguro con ping sin fragmentación y ajusta la MTU un poco por debajo del valor encontrado:
# Windows (probamos el tamaño -l, el flag -f prohíbe la fragmentación)
ping -f -l 1472 1.1.1.1
# Linux/macOS (el flag -M do prohíbe la fragmentación; tamaño -s)
ping -c 4 -M do -s 1472 1.1.1.1
Si sin fragmentación solo pasan paquetes más pequeños, reduce la MTU en el perfil de WireGuard (parámetro MTU=) o usa en OpenVPN mssfix/tun‑mtu. En IKEv2 los mensajes IKE_AUTH grandes pueden simplemente cortarse; es una trampa clásica con fragmentos y firewalls.
DNS. "Se conecta, pero no carga nada" a menudo significa que el túnel no recibe los servidores DNS correctos. Comprueba qué resolvedores entrega el perfil y que el cliente realmente los aplica. Tras la corrección, haz una prueba de fugas en DNSLeakTest y asegúrate de que las consultas van por el resolvedor "correcto".
DPI/reconocimiento de tráfico. En algunas redes cortan UDP por regla general, y OpenVPN se reconoce por el apretón de manos. La práctica: cambiar puerto/transporte (TCP/443), activar el cifrado del canal de control (ver tls‑crypt v2), y para WireGuard usar encapsulación o proxy sobre HTTP/3/QUIC en ciertos proveedores. Recuerde las leyes y políticas de la red — sobre eso en el bloque final.
Bonus para precisión: si sabes usarlo, inspecciona la conexión con Wireshark para ver exactamente dónde se rompe el apretón de manos: ¿DNS? ¿TLS? ¿IKE? A veces una sola captura de tráfico ahorra la tarde.
5. Sistema operativo y entorno: qué revisar en Windows, macOS, Linux, iOS y Android
Windows. Abre el "Visor de sucesos" → Aplicaciones y servicios → Microsoft → Windows → RasClient. Un error con Event ID 20227 ya indica una dirección. En PowerShell revisa perfiles: Get-VpnConnection, prueba rápidamente puerto/ruta: Test-NetConnection vpn.example.com -Port 443 -TraceRoute. Si está activo un kill switch/firewall, atenúa temporalmente las reglas y vuelve a intentar. Actualiza los drivers de los adaptadores virtuales (TAP/WinTUN).
macOS. Asegúrate de que en "Preferencias del Sistema" → "Red" el perfil esté activo; con networksetup -listallnetworkservices comprueba los servicios. Si IKEv2 falla sin motivo aparente, abre la "Consola" y filtra por ikev2/NEVPN durante la conexión. A veces ayuda eliminar e importar el perfil de nuevo, así como desactivar agentes filtrantes conflictivos.
Linux. Para WireGuard mira sudo wg (¿hay latest handshake?), journalctl -u wg-quick@wg0. Para OpenVPN, revisa los logs del servicio/cliente, que CN/certificados coincidan y que no haya errores de timeout o fragmentación. Verifica las rutas con ip route y las reglas iptables/nft que puedan "tumbar" el túnel.
Android. En "Ajustes" → "Red e internet" → "VPN" comprueba que no estén activados "VPN siempre activa" y "Bloquear sin VPN", que cortan el tráfico si falla. Si el perfil fue importado por una app, prueba desde la app, no solo desde el menú del sistema. Si hace falta, recrea el perfil y vuelve a otorgar permisos.
iOS/iPadOS. Revisa "Ajustes" → "General" → "VPN y gestión del dispositivo". Desactiva conflictos (por ejemplo, filtros privados/perfiles de contenido), reinstala el perfil y reinicia el dispositivo. A veces funciona sincronizar la hora y restablecer ajustes de red.
6. Cuando el problema no es tu equipo: servidor, proveedor, rutas
Si las comprobaciones básicas dan "verdes" pero el túnel no se mantiene, piensa en factores externos. El servidor puede estar sobrecargado o bajo filtrado; a veces las ubicaciones bloquean centros de datos concretos. Prueba otra región y, si es posible, otra conexión (internet doméstico ↔ red móvil).
Pide al proveedor su página de estado o canal de notificaciones: mantenimientos y averías pasan hasta en los mejores. Si gestionas tu propio servidor, revisa el tráfico entrante y los logs del daemon, que no hayan caducado certificados, que la licencia no se haya anulado y que no hayan cambiado reglas en el firewall o la nube.
En entornos corporativos averigua si cambiaron las políticas de seguridad: nuevos EDR/filtrados suelen romper túneles "por el camino". A veces ayuda excluir temporalmente el proceso del cliente de la inspección SSL y de filtros de contenido (con consentimiento de los administradores, por supuesto).
Si todo es inexplicable, prepara un "paquete mínimo para soporte": hora exacta del fallo, servidor/ubicación, tipo de red, captura/fragmento de log (sin datos sensibles), resultados de pruebas sencillas (ping/trazado/MTU). Una buena incidencia ahorra muchos nervios a todos.
7. Tras "arreglar": comprueba privacidad y "hermeticidad"
Conectaste — felicidades, pero dedica dos minutos más al control de calidad. Primero verifica que la IP externa sea realmente la que promete el proveedor (por ejemplo, en la página de comprobación de IP). Si no coincide, quizá estás en un nodo "local" o olvidaste desactivar el split tunneling para el navegador.
Luego — fugas DNS. Visita dnsleaktest.com y asegúrate de que los resolvedores correspondan a tu proveedor/política. Si aparece el resolvedor de tu proveedor doméstico, corrige la configuración del cliente/perfil (pasa los DNS correctos por el túnel).
Por último — WebRTC. En el navegador comprueba fugas en browserleaks.com/webrtc. Si hace falta, desactiva la revelación de IP por WebRTC (extensión/política del navegador) o usa modos en los que las direcciones locales no se expongan.
El combo ganador para el futuro: MTU estable, DNS correctos dentro del túnel y evitar a toda costa "aceleradores" y "optimizadores" que sustituyen resolvedores y aplican sus propios filtros encima del VPN.
8. Uso responsable y legal: descargos importantes
Sólo legalmente. Usa VPN estrictamente dentro del marco legal de tu país y de los términos de los servicios a los que accedes. El acceso a contenidos, recursos y servicios prohibidos en tu jurisdicción puede ser ilegal. Eres responsable de cumplir la ley.
Respeta las normas de la red. En redes corporativas, educativas y de invitados hay políticas locales; intentar eludir restricciones sin el consentimiento del propietario de la red puede violar contratos y acarrear sanciones.
Sin abusos. No uses VPN para actividades ilícitas, interferir con sistemas ajenos, violar derechos de autor, estafar, etc.
La privacidad es un proceso. El VPN no es un "escudo mágico". No te oculta en los sitios donde inicias sesión ni corrige hábitos inseguros. Verifica fugas, actualiza sistemas, usa MFA y evita extensiones dudosas.
Este material es de carácter informativo y no constituye asesoría legal. Consulta las normas vigentes en tu jurisdicción.
Lista de verificación breve (guárdala)
- ¿Hay internet sin VPN? Ping/traza a
1.1.1.1. ¿Se resuelven dominios? - Actualiza el cliente. Verifica usuario/contraseña/claves/validez de certificados. Sincroniza la hora.
- Desactiva kill switch/split tunneling/Always‑on y prueba de nuevo. Intenta otro servidor/puerto/transporte.
- Encuentra la MTU sin fragmentación y aplícala en el perfil. Verifica que el DNS pase por el túnel.
- ¿El problema ocurre solo en un SO/red? Revisa logs (RasClient, Console, journalctl), filtros y drivers.
- Tras la reparación: comprueba la IP externa, fugas DNS y WebRTC. Restaura las políticas necesarias una por una.
- Respeta siempre la ley y las reglas de la red. El VPN es una herramienta, no una indulgencia.
