Un usuario no puede iniciar sesión en la VPN: un diagnóstico ordenado

Cuando una persona no logra conectarse mientras el resto del equipo sigue trabajando, la pregunta útil no es qué está roto, sino qué capa no se puso de acuerdo. El inicio de sesión es una cadena: el cliente arranca, la puerta de enlace responde, se afirma una identidad, se satisface un segundo factor, se evalúa la política y solo entonces fluye el tráfico. Una rotura en cualquier punto de esa cadena llega a ustedes como la misma frase del usuario, así que la primera tarea es encontrar el eslabón que realmente falló.

Traten el informe como un punto de partida y no como un diagnóstico. Las comprobaciones siguientes van de la más barata a la más cara, y cada una está escrita para terminar la investigación cuando falla.

Fijen la etapa y la marca de tiempo

Anoten cuatro cosas antes de tocar cualquier configuración: el cliente y su versión, la redacción exacta en pantalla, el minuto del intento y la red en la que estaba la persona. La redacción lleva información real, porque unas credenciales rechazadas, una puerta de enlace que no responde y un inicio de sesión completado que aún no puede abrir una página interna son tres problemas distintos con tres responsables distintos. Fíjense en si el cliente produjo una línea de registro local, ya que un cliente que nunca envió un paquete no tiene nada que aportar a una búsqueda del lado del servidor. Con la marca de tiempo registrada, cada consulta posterior se convierte en una búsqueda y no en una cacería.

Dejen de adivinar contraseñas en este punto. Donde la cuenta tiene un límite de reintentos, una ráfaga de intentos rápidos puede bloquearla y añadir una segunda falla artificial encima de la real. Anoten cuántos intentos se han hecho ya, para que un bloqueo no se confunda después con un síntoma nuevo. Una cuenta bloqueada también les quita la capacidad de distinguir una contraseña incorrecta de una política rechazada, ya que ambas llegan como una negativa.

Lean el evento de identidad de ese único intento

Pidan al administrador que extraiga el registro de autenticación que coincide con el minuto anotado. En un despliegue de Windows NPS, la guía de solución de problemas de NPS de Microsoft documenta el evento de rechazo 6273 junto con el código de motivo que lo acompaña, que suele separar un usuario desconocido, unas credenciales erróneas, un desajuste de política y una llamada caída por un motivo no relacionado.

Un resultado vacío también es información. Si nada llegó al servicio de identidad, el intento murió antes: una dirección de puerta de enlace obsoleta en el perfil, un oyente al que el cliente no puede llegar, o un host que se retiró mientras el perfil seguía vivo. Si el registro existe e informa de éxito, las credenciales no son el problema y el argumento pasa a la autorización o al enrutamiento detrás de la puerta de enlace. Estos dos resultados apuntan en direcciones opuestas, por lo que la búsqueda en los registros debe ocurrir antes de que alguien reinstale un cliente.

Guarden el código de motivo en el ticket. Ese único campo convierte la próxima aparición en una consulta de cinco minutos en lugar de una investigación repetida. Emparejenlo con la versión del cliente, porque un código que aparece en una compilación es una conversación distinta de uno que aparece en todas las compilaciones.

Cambien una condición a la vez, dentro de la política

La tentación es reinstalar el cliente, restablecer la contraseña y mover el portátil a otra red en una sola pasada. Eso a veces arregla el síntoma y siempre destruye la evidencia. Elijan en cambio un solo intercambio permitido: la misma persona en un segundo dispositivo inscrito, o una identidad de prueba aprobada en el mismo dispositivo. Cada intercambio responde exactamente a una pregunta, así que un éxito estrecha la falla hacia el lado que cambiaron en lugar de culpar a la VPN entera.

No pidan prestadas las credenciales de un colega para esta comparación. Usen una identidad de prueba mediante el proceso admitido, y nunca copien una clave de dispositivo ni omitan la inscripción porque sería más rápido. Donde la política prohíbe del todo un intercambio, esa restricción forma parte del sistema bajo prueba y pertenece al registro, no a una solución alternativa.

Confirmen la reparación en la ruta original

Cuando se identifique el eslabón roto, reparen solo ese eslabón y repitan el intento original: misma persona, mismo dispositivo, misma red, misma aplicación. Una cuenta de prueba que se conecta desde la VLAN de administración demuestra que la puerta de enlace está viva, y no demuestra nada sobre el martes por la mañana del usuario. Pidan al usuario que realice la acción que falló y no una más simple, ya que un ping correcto dice poco sobre un recurso compartido rechazado.

Cierren el ticket con lo que se descartó y lo que cambió. Esa nota es la diferencia entre un rescate puntual y algo que el próximo ingeniero de guardia podrá reutilizar.