Congelación de dos segundos: ¿fue la VPN o el Wi-Fi?
Un bloqueo de dos segundos y una sesión VPN nueva son sucesos distintos. Ponga la ruta de acceso y el túnel en líneas de tiempo separadas antes de cambiar un temporizador.
Una congelación de dos segundos que se recupera se ve igual tanto si el túnel renegoció como si la radio tuvo un hipo. También es posible que no se haya caído nada en absoluto, y esa posibilidad merece probarse primero. Una ráfaga breve de pérdidas, una renegociación y un bloqueo de la aplicación se sienten igual para la persona que teclea. Solo uno de los tres casos se corrige editando la configuración del túnel.
Dos registros, no uno
Anote qué ocurrió con la conexión de debajo y, por separado, qué hizo el túnel mismo. Después coloque la pausa de la aplicación frente a ambos registros. Son series de sucesos independientes que a veces coinciden, y llamar desconexión a las tres presupone la respuesta desde el principio.
Un monitor que sondea una vez por minuto no puede ver una interrupción de dos segundos. Informar que ese día fue saludable es técnicamente exacto y prácticamente inútil. Ponga el intervalo de muestreo junto a cada resultado que cite.
Qué hizo el enlace de acceso mientras la aplicación se congelaba
El intervalo de muestreo y el tiempo de espera definen qué pudo haber observado el monitor, así que anote ambos junto al resultado. Una ausencia registrada de cortes significa poco cuando el instrumento muestrea cada sesenta segundos. Luego sondee tres lugares con marcas de tiempo: el router local, un host externo aprobado alcanzado por la ruta simple y un recurso detrás del túnel.
Confirme primero las rutas, porque un destino público puede estar él mismo enrutado por el túnel y entonces mide el túnel en lugar de la ruta de acceso. Las pruebas que fechan realmente el corte viven una capa más abajo: eventos de enlace en el router, registros de resincronización en el módem y una dirección WAN que cambió. Un contador acumulado de errores le dice que algo falló, nunca cuándo. Correlacione esos registros con la ventana del incidente en vez de leerlos aislados.
ping -i 0.5 -c 40 192.168.60.1
mtr -rwc 40 203.0.113.25
ip -brief address showUn contador que subió ayer no explica nada sobre una congelación de esta mañana. Limite la correlación a la ventana que el usuario reportó.
Busque el registro de reinicio
Un datagrama UDP perdido no hace, por sí solo, que Community OpenVPN inicie una negociación TLS nueva. El comportamiento de reinicio sigue ping-restart, y el valor vigente pudo haberlo impuesto el servidor; el manual de la 2.6 define esos temporizadores. La entrega se rompe un instante, el umbral nunca se cruza y el registro queda vacío. Por eso busque en el registro alrededor de la pausa una línea de reinicio, una conexión nueva o un identificador de sesión que cambió. Si no aparece ninguno de los tres, el túnel probablemente no hizo nada y el temporizador nunca fue el problema.
Recortar cada keepalive hace que la detección parezca más rápida y mueve la línea en la que un hipo se convierte en reconexión. Cada reconexión cuesta una ronda de autenticación y la reinstalación de rutas. Estirar el temporizador no compra nada salvo una ventana más larga en la que una ruta muerta aún parece viva. Ambas son decisiones de ajuste con un precio, no mejoras gratuitas.
Un suceso ausente también es una prueba, y es del tipo que la gente se salta porque nada en el registro llama la atención sobre él. Anote la búsqueda que hizo, no solo el resultado.
Deje que la comparación decida qué arreglar
Con ambos registros uno al lado del otro, la asignación suele escribirse sola. Un evento de enlace del router en ambas rutas significa que el tema es la conexión de acceso. Un túnel silencioso y una ruta simple utilizable significan que lo es la negociación.
| What you observed | Tunnel log at that second | Where to look next |
|---|---|---|
| two-second pause, plain path answers throughout | nothing | the monitor's resolution, then a loss burst |
| pause plus a router link event, plain path stops and returns | no restart line | the access link, not the tunnel timer |
| pause, then a new session identifier | restart line | the restart threshold and what triggered it |
| one application freezes while both paths answer | nothing | that application and its server-side work |
Cada fila es una pista, no un veredicto: los extremos despriorizan ICMP, y dos destinos no comparten necesariamente una ruta. Mantenga los relojes alineados entre cliente, puerta de enlace y aplicación para que la comparación sea posible. Una fila que encaja en dos columnas necesita otra observación, no una decisión.
Un informe que sobrevive a la revisión responde cuatro cosas: cuánto duró la congelación, qué rutas siguieron respondiendo, qué registró el túnel en ese segundo y con qué frecuencia muestrea el monitor. Esos cuatro hechos permiten al siguiente lector reproducir la observación en lugar de fiarse de un resumen. Un porcentaje de disponibilidad esconde justo el intervalo que le interesa, y la frase "la VPN se cayó" también.