Cómo probar la estabilidad de una VPN sin registrar tu navegación

Quieres saber si el túnel sobrevive a una suspensión del portátil, a un paseo entre puntos de acceso, o a una hora de llamadas, y prefieres no entregar a nadie un registro de todo lo que lees mientras lo averiguas. Tres cosas lo responden: una sonda fija, los mismos cuatro hechos muestreados según un horario y el suceso que los cambió, anotado. Diez minutos de eso superan una tarde mirando cómo una página no carga. El registro que acabas teniendo también es lo bastante corto para adjuntarlo a un tique sin censurar la mitad.

Decide qué debe significar estable

«La VPN se cayó» son cuatro fallos distintos con una sola palabra. El peer puede perder su handshake, la ruta puede volver a la puerta de enlace local, la resolución de nombres puede ir a un servidor que nunca responde por el túnel, o todo eso puede estar sano mientras una aplicación sigue fallando. Decide cuál coincide con tu síntoma antes de recoger nada, porque cada uno necesita una sonda distinta. Luego elige un intervalo que puedas mantener: una muestra cada treinta segundos durante diez minutos capta un roaming sin convertir la prueba en carga de trabajo.

Si la queja es una llamada que se congela cuando vas a la cocina, la propiedad que necesitas es si una petición nueva se completa tras el roaming. Eso se comprueba en una línea y no registra ninguna navegación.

Fija una sonda inofensiva

Elige un destino que tengas permitido consultar y que no esté ligado a tus cuentas: un host de documentación, un punto final de estado interno o la propia puerta de enlace del túnel. Haz la operación repetible, por ejemplo curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://example.com/, que imprime una línea por intento. Mantén ese formato de salida fijo durante toda la ejecución. Un código de estado y una duración recogidos de la misma forma dos veces son lo que hace comparables dos ejecuciones.

Resiste el sitio del que de verdad dependes. Una página de banca o de correo web arrastra rastreadores, redirecciones y contenido personal a la medición, y además imprime identificadores de sesión en todo lo que pegues luego en un tique. Usa el mismo destino durante toda la investigación y anótalo junto al intervalo.

Muestrea los cuatro hechos

El estado del peer, la ruta, el resolutor y una petición nueva son las cuatro observaciones, y cada una tiene una fuente barata. En WireGuard, wg show wg0 latest-handshakes da la marca de tiempo del peer y ip route get 1.1.1.1 muestra qué interfaz usaría el núcleo. En OpenVPN el mismo estado está en el archivo de estado que escribe --status /run/openvpn/status 10 o detrás de state en la interfaz de gestión. Un cliente de Windows se queda en PowerShell con Get-NetAdapter y Resolve-DnsName.

Ponlos en bucle en un solo terminal para que cada línea lleve una marca de tiempo: for i in $(seq 1 20); do date -Is; wg show wg0 latest-handshakes; ip route get 1.1.1.1; sleep 30; done. Ese bucle cubre tres de los seis campos del registro; la versión del cliente se pone una vez arriba, y la marca de tiempo del suceso se añade cuando ocurre.

El resolutor es el hecho que la gente se salta, y dig +short lo oculta, porque esa forma solo imprime la respuesta. Pide el servidor explícitamente con dig example.com | grep SERVER:, o usa nslookup example.com donde dig no está instalado, que imprime la dirección del servidor al que fue la consulta. Un handshake viejo en un túnel inactivo tampoco es un fallo automático, ya que WireGuard solo renueva claves cuando hay tráfico que proteger.

Provoca el suceso, no una fuga

Toma cinco minutos tranquilos como línea base antes del suceso que te interesa, ya sea cerrar la tapa, caminar hasta otro punto de acceso o cambiar al punto de acceso del móvil. Anota la hora en que lo provocaste, para que las muestras de ambos lados se puedan alinear.

Sin esa marca de tiempo el registro muestra un hueco y nadie puede decir si lo cerró el cliente o la red. Dos ejecuciones con el suceso en lugares distintos valen más que diez sin él. Usa los controles de desconexión y reconexión del propio cliente. No desactives el interruptor de seguridad ni empujes tráfico fuera del túnel para ver qué pasa, porque en un portátil gestionado eso es una violación de política y en tu propia máquina crea exactamente la exposición que estabas probando.

Mantén un registro lo bastante pequeño para terminarlo

Seis campos por muestra: hora, versión del cliente, punto final, red de acceso, suceso, resultado. Deja fuera las direcciones web, las cargas útiles, los tokens y cualquier cosa que lleve un identificador de sesión, porque el registro es evidencia sobre el túnel y nada más. Tenlo junto al bucle para que la siguiente persona pueda volver a ejecutarlo sin preguntar qué significan las columnas.

Tras un cambio, repite la prueba con la misma sonda y el mismo intervalo; si cambias el destino y la versión del cliente a la vez, el resultado no pertenece a ninguno de los dos. Una ejecución limpia de diez minutos es evidencia para esas condiciones y ese destino, no una promesa sobre la red del hotel el mes que viene. Guarda el script y la plantilla de registro donde los encuentres. Las limitaciones documentadas de WireGuard merecen leerse antes de atribuir una caída al protocolo.