Caídas intermitentes de la VPN: qué registrar en cada ocasión
Una caída intermitente es un problema de datos antes que un problema de configuración. Registre cinco campos por incidente y luego compare las etapas antes de cambiar ajustes.
Las caídas intermitentes son un problema de recogida de datos antes que un problema de configuración. Registre los mismos campos en cada aparición, o los incidentes no se podrán comparar. Cambiar tres ajustes después de cada evento destruye la única evidencia que tenía.
El procedimiento siguiente tarda unos dos minutos por incidente y produce una línea por evento. Supone acceso de solo lectura en un dispositivo que usted administra.
Fije los campos antes del primer fallo
Redacte la lista de campos antes de que algo se rompa, porque una plantilla inventada a mitad de un incidente siempre se salta una columna. Cinco campos bastan para empezar: la hora local con su desfase, el desencadenante, la etapa que se rompió, el texto exacto del error y si un intento nuevo tuvo éxito.
El desencadenante merece su propio vocabulario: inactividad, reanudación tras la suspensión, cambio de red, pico de carga, renovación de credenciales o desconocido. Deje desconocido etiquetado como desconocido en lugar de rellenarlo después de memoria. El campo de etapa aporta el mayor valor, porque registra dónde se detuvo la cadena y no qué sintió el usuario. El texto del error debe copiarse literalmente, porque una paráfrasis pierde la distinción entre dos códigos parecidos.
Deje los huecos como huecos. Una plantilla que obliga a responder invita a inventar, y un contexto inventado es peor que un espacio en blanco.
| Field | Example | Why it earns its place |
|---|---|---|
| Time with offset | 2026-11-03T09:14+08:00 | Orders events across sources in different zones |
| Trigger | resume from sleep | Separates a cause from a coincidence |
| Stage | handshake ok, no route | Names the boundary that failed |
Registre los mismos cinco hechos en el fallo
Ejecute los mismos comandos en el mismo orden cada vez. Dos minutos de salida valen más que una foto del icono de la bandeja, y la secuencia importa cuando después las marcas de tiempo no coinciden.
date -Is journalctl -u wg-quick@wg0 --since "-2 min" --no-pager wg show wg0 latest-handshakes transfer ip route get 203.0.113.10 ping -c 3 -W 2 192.0.2.1
La primera línea marca la observación con un desfase, y es la única forma de conciliar tres fuentes registradas en zonas distintas. El extracto del registro cubre el ciclo de vida del servicio, y la línea del apretón de manos dice si el par respondió. La consulta de ruta nombra la interfaz que usaría un destino concreto, y eso no es el mismo hecho que la existencia de la interfaz. Un ping a la dirección del túnel muestra si algo cruza el enlace, no si el otro lado es alcanzable.
Escriba una línea por incidente en un registro continuo, con esos campos y nada más. Después de cinco o seis entradas, ordene por desencadenante y luego por etapa. Los patrones aparecen como pares repetidos, y un par que nunca se repite es probablemente una coincidencia.
Localice la etapa que se rompió
La conectividad local, el estado del par, las rutas y la resolución de nombres fallan en sitios distintos, y cada uno deja su propia huella. Si la interfaz existe pero ninguna ruta apunta a ella, el fallo es de política local. Si la marca de tiempo del apretón de manos deja de avanzar mientras la interfaz sigue activa, el fallo está más arriba.
La resolución de nombres pertenece al mismo registro. Un resolutor que el lunes seguía el túnel y el martes la red local produce fallos que parecen aleatorios en la capa de aplicación.
Para el acceso autorizado al servidor, correlacione el mismo intento y no una reconexión cercana. Conserve las marcas de tiempo originales y anote cualquier desfase por separado, porque convertirlas en el sitio borra la evidencia de la conversión. Un intento, un juego de marcas de tiempo, una conclusión.
Compare una condición cada vez
Una comparación controlada cambia una condición significativa y mantiene la ejecución fallida junto a la exitosa. Mueva el dispositivo a otra red, o desactive una exclusión, y no cambie nada más en el mismo paso.
Mantenga la ejecución fallida en el registro. Borrarla en favor de la que funciona descarta la única evidencia del límite que intenta localizar.
Comparta un extracto, no el perfil
Antes de enviar nada, quite contraseñas, testigos, claves privadas, identidades ajenas y cargas útiles. Un perfil completo es un secreto de configuración y no un resumen de conexión, y no pertenece a un tique.
Envíe el extracto con los cinco campos y diga qué etapa cree que falló. Así un administrador puede examinar el límite que usted nombró en lugar de desplazarse por capturas de un icono desconectado. Si el límite sigue sin estar claro, el siguiente paso es otro registro controlado, no otro cambio de ajustes.