Bloqueado por un bucle de reintentos de VPN: detén primero el cliente

A las 02:40 la cuenta se bloquea y no hay nadie frente al teclado. Un cliente en un estante sigue presentando la contraseña que guardó el mes pasado, la pasarela sigue rechazándola, y el contador detrás del bloqueo sube sin que intervenga ninguna persona. Eso es un bucle de reintentos y no un ataque, y hay que detenerlo antes de que se pueda recuperar la cuenta.

Trátalo como dos problemas en un orden fijo. Detén primero al emisor y después restaura el acceso, porque hacerlo al revés reinicia el bucle en cuestión de minutos.

Averigua qué proceso envía los fallos

Empieza por las marcas de tiempo del sistema de identidad y compáralas con cada cliente que tiene la cuenta. Un perfil gestionado, un servicio sin supervisión, un teléfono en un cajón y un portátil de repuesto con credenciales antiguas pueden autenticarse todos como la misma persona. El que falla cada pocos segundos es el bucle, y el que falla una vez al día suele ser una persona que lo olvidó. Ambos alimentan el mismo contador, y ahí está la trampa.

Distingue un rechazo de una pasarela inalcanzable mientras miras. Un tiempo de espera agotado, un fallo de resolución de nombres o un puerto cerrado normalmente no incrementan un contador de fallos, mientras que un intercambio de autenticación completado que devuelve un resultado de credencial incorrecta sí lo hace. Mezclar los dos produce la solución equivocada, porque uno necesita el cliente detenido y el otro necesita la ruta reparada.

Tres condiciones que deciden la respuesta

Tres hechos reducen esto a una respuesta. Primero, si el registro muestra un rechazo explícito o un fallo de transporte. Segundo, si la identidad se comparte entre dispositivos o servicios. Tercero, si el cliente que reintenta es uno que administras tú o uno que controla otra persona.

Un rechazo explícito de un solo cliente que controlas significa detener ese cliente, desbloquear por la ruta aprobada y hacer un único inicio de sesión deliberado. Una identidad compartida empuja la respuesta hacia el aprovisionamiento y no hacia el desbloqueo, porque el bucle se reanudará en el momento en que el otro dispositivo se reconecte. Los fallos de transporte apuntan a la capa de red, donde la protección de la cuenta no es el asunto en absoluto.

Ninguna de esas ramas implica debilitar la protección. Los umbrales de bloqueo y los límites de velocidad existen porque la misma señal que te molesta durante una caída es la señal que frena un intento de adivinar una contraseña.

Detén al emisor antes de desbloquear

Detén la unidad o la conexión que sigue autenticándose, y deténla de una forma que sobreviva a un reinicio. Poner el cliente en pausa no basta cuando su servicio está configurado para arrancar automáticamente al iniciar el sistema.

# which unit is presenting the credential?
journalctl -u openvpn-client@home --since '20 min ago' | grep -i 'auth\|error'

# stop it, and keep it stopped across reboots
sudo systemctl stop openvpn-client@home
sudo systemctl disable openvpn-client@home
systemctl is-active openvpn-client@home

Espera unos minutos y confirma que el contador de fallos deja de moverse. Esa pausa es la prueba de que encontraste la fuente correcta. Si los fallos continúan, el bucle viene de otro sitio y el paso de desbloqueo habría sido inútil.

Solo entonces usa el proceso de desbloqueo o recuperación documentado del operador, y síguelo con exactamente un inicio de sesión controlado desde el dispositivo que pretendes conservar. Los umbrales exactos, los periodos de enfriamiento y la redacción de la recuperación son específicos de cada servicio, así que léelos en lugar de adivinar un número.

Elimina la causa para que no vuelva

Actualiza la credencial guardada donde se posee: en el llavero del sistema operativo, en el perfil del cliente o en la configuración de la cuenta de servicio. Borrarla de un sitio mientras otro conserva una copia es como vuelve el bucle una semana después, normalmente cuando un portátil que estaba desconectado regresa y reproduce su valor en caché.

Dale a la automatización una identidad propia. Una cuenta aprovisionada por separado con su propia credencial y sus propios límites evita que un fallo de máquina deje a una persona fuera del correo, y hace que el fallo sea atribuible en los registros. Añade una espera progresiva al cliente para que una credencial rechazada detenga los reintentos en lugar de repetirlos, y activa una alarma ante fallos de autenticación repetidos para que el siguiente bucle se note en minutos y no a las 02:40.

Cuando el informe va a soporte, conserva el identificador de la cuenta, las marcas de tiempo y el nombre del cliente. Las contraseñas y el material de recuperación nunca pertenecen a ese registro.