El VPN se desconecta sin parar: prueba la radio antes que el servidor

Una desconexión de VPN puede empezar mucho antes de que ningún tráfico llegue al servidor. La pérdida de Wi-Fi, un traspaso de Wi-Fi a la red móvil, la congestión del punto de acceso local y un teléfono que se duerme pueden interrumpir el camino exterior mientras el software del túnel informa de un fallo limpio. Avance desde el dispositivo hacia fuera: primero el enlace, después los eventos del propio cliente, luego una comparación controlada y solo entonces el servidor. Ese orden le evita cambiar nodos de salida por un problema que vive en la habitación.

Mire el enlace, no el icono de señal

Busque transiciones del enlace en lugar de barras. Un dispositivo puede mostrar una señal fuerte mientras el punto de acceso está saturado, mientras hay un traspaso de itinerancia en curso o mientras una política de ahorro de energía apaga la radio con la pantalla apagada.

Registre el estado de la interfaz, la puerta de enlace actual y la hora de cada cambio. Después compruebe si la desconexión coincide con la transición. Una caída que ocurre cada vez que el teléfono se mueve entre habitaciones es un problema de enlace hasta que se demuestre lo contrario, sin importar qué servidor muestre la aplicación.

Lea los eventos de reconexión del cliente

La mayoría de los clientes registran un motivo de la desconexión y una marca de tiempo del siguiente intento. Un túnel que renegocia en cuestión de segundos y luego funciona es un evento distinto de uno que se queda caído hasta que lo activa manualmente.

Las reconexiones breves repetidas apuntan al camino exterior, porque el cliente sigue llegando al servidor y perdiendo la sesión. Un túnel que se queda caído apunta a la autenticación, a un cambio de punto final o a una política, porque el cliente no llega lo bastante lejos como para perder algo. Lea los dos patrones por separado antes de tocar la configuración.

Compare un segundo punto final con cuidado

Un segundo punto final es una comparación útil y no es, por sí solo, un experimento controlado. Cambia la ruta, la infraestructura y a menudo el país, así que una diferencia entre dos puntos finales no demuestra que el primer servidor esté defectuoso.

Mantenga fijos el dispositivo, la red de acceso y la carga de trabajo y anote qué más cambió al cambiar. Si ambos puntos finales fallan a la vez en el mismo lugar, el camino local es el factor común. Si solo falla uno, el servidor o la ruta hasta él pasa a ser la pista. Anote los factores de confusión para que la conclusión no se adelante a las pruebas.

Correlacione con el servidor que administra

Si administra el punto final, haga coincidir la hora del intento con los registros de escucha y de asociación. Varios clientes no relacionados que fallan en la misma puerta de enlace son una prueba distinta de un solo teléfono que se cae cada vez que se mueve.

Una sola respuesta de un par no establece una salud continua de la aplicación. Tras la recuperación, pruebe el recurso que realmente necesita, porque un saludo correcto y un servidor accesible pueden coexistir con un camino de aplicación roto.

Escriba el informe que lo acota

Separe cuatro afirmaciones: pérdida del enlace local, alcance exterior, negociación del túnel y estado propio de la aplicación. Cada una tiene su propia prueba, y un informe que las mantiene separadas dice a la siguiente persona dónde mirar.

Anote también los límites de la comparación. Si una política impidió una prueba de camino directo, dígalo en lugar de presentar la comparación de puntos finales como prueba. La etiqueta de país en la aplicación no identifica la ruta completa, y un servidor geográficamente cercano todavía puede alcanzarse por un camino congestionado.

La página de limitaciones conocidas del proyecto WireGuard es un recordatorio útil de que un protocolo puede ser correcto y aun así dejar el comportamiento del enlace al sistema operativo. Termine repitiendo la misma prueba tras la siguiente desconexión, porque un solo evento es un dato y un patrón es un diagnóstico.