Un usuario non pode iniciar sesión na VPN: un diagnóstico ordenado

Cando unha persoa non consegue conectarse mentres o resto do equipo segue traballando, a pregunta útil non é que está roto, senón que capa non se puxo de acordo. O inicio de sesión é unha cadea: o cliente arrinca, a pasarela responde, afírmase unha identidade, satisfaise un segundo factor, avalíase a política e só entón flúe o tráfico. Unha rotura en calquera punto desa cadea chega a vostedes como a mesma frase do usuario, así que a primeira tarefa é atopar o elo que realmente fallou.

Traten o informe como un punto de partida e non como un diagnóstico. As comprobacións seguintes van da máis barata á máis cara, e cada unha está escrita para rematar a investigación cando falla.

Fixen a etapa e a marca de tempo

Anoten catro cousas antes de tocar calquera configuración: o cliente e a súa versión, a redacción exacta na pantalla, o minuto do intento e a rede na que estaba a persoa. A redacción leva información real, porque unhas credenciais rexeitadas, unha pasarela que non responde e un inicio de sesión completado que aínda non pode abrir unha páxina interna son tres problemas distintos con tres responsables distintos. Fíxense en se o cliente produciu unha liña de rexistro local, xa que un cliente que nunca enviou un paquete non ten nada que achegar a unha busca do lado do servidor. Coa marca de tempo rexistrada, cada consulta posterior convértese nunha busca e non nunha cacería.

Deixen de adiviñar contrasinais neste punto. Onde a conta ten un límite de reintentos, unha ráfaga de intentos rápidos pode bloqueala e engadir unha segunda falla artificial encima da real. Anoten cantos intentos se fixeron xa, para que un bloqueo non se confunda despois cun síntoma novo. Unha conta bloqueada tamén lles quita a capacidade de distinguir un contrasinal incorrecto dunha política rexeitada, xa que ambas chegan como unha negativa.

Lean o evento de identidade dese único intento

Pidan ao administrador que extraia o rexistro de autenticación que coincide co minuto anotado. Nunha implantación de Windows NPS, a guía de solución de problemas de NPS de Microsoft documenta o evento de rexeitamento 6273 xunto co código de motivo que o acompaña, que adoita separar un usuario descoñecido, unhas credenciais erróneas, un desaxuste de política e unha chamada caída por un motivo non relacionado.

Un resultado baleiro tamén é información. Se nada chegou ao servizo de identidade, o intento morreu antes: un enderezo de pasarela obsoleto no perfil, un oínte ao que o cliente non pode chegar, ou un host que se retirou mentres o perfil seguía vivo. Se o rexistro existe e informa de éxito, as credenciais non son o problema e o argumento pasa á autorización ou ao encamiñamento detrás da pasarela. Estes dous resultados apuntan en direccións opostas, por iso a busca nos rexistros debe ocorrer antes de que alguén reinstale un cliente.

Garden o código de motivo no tícket. Ese único campo converte a próxima aparición nunha consulta de cinco minutos en lugar dunha investigación repetida. Emparellen o coa versión do cliente, porque un código que aparece nunha compilación é unha conversación distinta dun que aparece en todas as compilacións.

Cambien unha condición á vez, dentro da política

A tentación é reinstalar o cliente, restablecer o contrasinal e mover o portátil a outra rede nunha soa pasada. Iso ás veces arranxa o síntoma e sempre destrúe a evidencia. Elixan en cambio un só intercambio permitido: a mesma persoa nun segundo dispositivo inscrito, ou unha identidade de proba aprobada no mesmo dispositivo. Cada intercambio responde exactamente a unha pregunta, así que un éxito estreita a falla cara ao lado que cambiaron en lugar de culpar a VPN enteira.

Non pidan prestadas as credenciais dun compañeiro para esta comparación. Usen unha identidade de proba mediante o proceso admitido, e nunca copien unha clave de dispositivo nin omitan a inscrición porque sería máis rápido. Onde a política prohibe de todo un intercambio, esa restrición forma parte do sistema baixo proba e pertence ao rexistro, non a unha solución alternativa.

Confirmen a reparación na ruta orixinal

Cando se identifique o elo roto, reparen só ese elo e repitan o intento orixinal: mesma persoa, mesmo dispositivo, mesma rede, mesma aplicación. Unha conta de proba que se conecta desde a VLAN de administración demostra que a pasarela está viva, e non demostra nada sobre o martes pola mañá do usuario. Pidan ao usuario que realice a acción que fallou e non unha máis simple, xa que un ping correcto di pouco sobre un recurso compartido rexeitado.

Pechen o tícket co que se descartou e co que cambiou. Esa nota é a diferenza entre un rescate puntual e algo que o próximo enxeñeiro de garda poderá reutilizar.