¿La VPN del router parece correcta tras un corte? Compruebe estas cuatro capas

Un router que se enciende tras un corte ha restaurado su configuración, no su conectividad. Tras un corte de luz, un router puede restaurar su perfil de VPN guardado antes de que estén listas las dependencias que ese perfil necesita: el módem de aguas arriba puede seguir entrenándose, el reloj puede estar mal y la autenticación puede no haberse completado. La luz del panel y la configuración guardada describen la intención, no un túnel que funcione. Compruebe las cuatro capas siguientes en orden en lugar de sustituir el perfil, que es lo que la gente hace en segundo lugar y lamenta en primer lugar.

Todo esto supone que está en el sitio o tiene una vía de acceso que no dependa del túnel que está probando. Si no la tiene, organícela antes del próximo corte.

Primera capa: ¿ha vuelto realmente el WAN

Empiece por el módem, no por el panel del router. Un router que termina de arrancar antes de que su módem se haya entrenado muestra una interfaz sana sin nada detrás, y el túnel no tiene ningún par al que llegar. Confirme que el módem reenvía de verdad y luego confirme que el router ha tomado la configuración de WAN que espera. Compruebe también si la dirección WAN ha cambiado: una dirección dinámica que vuelve distinta puede invalidar una regla basada en dirección o una lista de permitidos remota, y desde dentro de la red eso parece un fallo de la VPN.

Algunas redes de acceso también exigen un paso de admisión nuevo tras un corte. Lea el registro del cliente para la primera etapa de fallo en lugar de adivinar: el primer error nombra la capa, y todo lo que viene después es consecuencia. Anote la dirección y el resultado de la admisión en el ticket, porque ambos deciden si el mismo perfil funcionará mañana. Una dirección cambiada es un arreglo de cinco minutos y un misterio de dos horas.

Segunda capa: compruebe el reloj antes del certificado

Un reloj incorrecto interfiere en la validez del certificado y en todo lo que depende del tiempo, y un dispositivo integrado que arranca sin una fuente de tiempo operativa puede quedarse con una fecha antigua un rato. Entonces la validación del certificado falla por un motivo que no tiene nada que ver con la credencial. Un error de validez cuyas fechas se desvían años señala al reloj; el mismo error con fechas actuales señala al certificado.

date -u
chronyc tracking

Use el proceso de recuperación de tiempo admitido y confirme el reloj del router antes de tocar el perfil. Desactivar la validación para saltarse el error convierte un problema temporal de orden en un debilitamiento permanente, y es el arreglo malo más común en este escenario. Si el dispositivo no tiene reloj con batería, el orden de arranque importa: necesita acceso a la red antes de sincronizar la hora, y necesita hora antes de validar un túnel. Ese orden es lo que hay que arreglar si el mismo fallo se repite tras cada corte.

Tercera capa: lea lo que dice el túnel

Compruebe el estado propio del túnel y el resultado de su negociación o autenticación, no que la interfaz esté levantada. Una interfaz puede existir sin un par establecido, y un cliente puede mostrarse conectado mientras falla la renovación de claves. Separe los tiempos de espera de transporte de los rechazos explícitos: un tiempo de espera sugiere que la ruta o el par aún no son alcanzables, mientras que un rechazo significa que el extremo remoto respondió y se negó, a menudo por credenciales, un certificado o una identidad de par que ya no coincide. Enviar al usuario a restablecer la contraseña por un tiempo de espera hace perder la tarde a todos.

Tenga a mano la última configuración buena conocida para comparar campos en lugar de reconstruirlos. Si un campo ha cambiado, ese cambio es el hallazgo. Compárelo campo por campo con la restaurada en lugar de leer solo la restaurada. La mayoría de las sorpresas tras un corte son un campo que volvió en silencio a un valor predeterminado de plantilla.

Cuarta capa: pruebe desde un dispositivo posterior

Abra un recurso permitido e inofensivo desde un cliente detrás del router y luego confirme qué salida o ruta privada usó realmente el tráfico. Compruebe el DNS y cada familia de direcciones que dice cubrir, porque la sonda del propio router puede tener éxito mientras la política del cliente sigue siendo incorrecta — la sonda suele usar otra fuente, otra tabla u otra ruta de resolución.

curl -s https://ifconfig.me
nslookup example.com

Si el túnel está caído y no solo mal configurado, decida si los clientes afectados deben bloquearse o pueden usar un recurso alternativo aprobado. Esa elección pertenece al plan de conmutación por error antes de un corte, no a un hilo de chat durante uno. Escriba la salida y el resolutor observados en el ticket del corte. Dos líneas ahora ahorran a la siguiente persona una hora de conjeturas sobre qué ruta estuvo activa durante la ventana.

Qué arreglar para que el próximo corte sea más corto

Si el fallo se repite, el arreglo es el orden, no la configuración: suba el WAN, luego la hora, luego el túnel, luego la política del cliente. La mayoría de los routers lo expresan como una dependencia o un retraso, y un retraso breve y deliberado supera a reescribir el perfil.

Después repita la prueba normal de reinicio una vez cambiado, incluida la comprobación del lado del cliente. Una prueba de reinicio que solo mira el panel del router prueba la capa menos informativa de las cuatro.