Un usuari no pot iniciar sessió a la VPN: un diagnòstic ordenat

Quan una persona no aconsegueix connectar-se mentre la resta de l’equip continua treballant, la pregunta útil no és què està trencat, sinó quina capa no s’ha posat d’acord. L’inici de sessió és una cadena: el client arrenca, la passarel·la respon, s’afirma una identitat, se satisfà un segon factor, s’avalua la política i només llavors flueix el trànsit. Un trencament en qualsevol punt d’aquesta cadena us arriba com la mateixa frase de l’usuari, així que la primera feina és trobar l’eslavó que realment ha fallat.

Tracteu l’informe com un punt de partida i no com un diagnòstic. Les comprovacions següents van de la més barata a la més cara, i cadascuna està escrita per acabar la investigació quan falla.

Fixeu l’etapa i la marca de temps

Anoteu quatre coses abans de tocar cap configuració: el client i la seva versió, la formulació exacta a la pantalla, el minut de l’intent i la xarxa on era la persona. La formulació porta informació real, perquè unes credencials rebutjades, una passarel·la que no respon i un inici de sessió completat que encara no pot obrir una pàgina interna són tres problemes diferents amb tres responsables diferents. Fixeu-vos si el client ha produït una línia de registre local, ja que un client que mai ha enviat un paquet no té res a afegir a una cerca al costat del servidor. Amb la marca de temps enregistrada, cada consulta posterior es converteix en una cerca i no en una cacera.

Deixeu d’endevinar contrasenyes en aquest punt. On el compte té un límit de reintents, una ràfega d’intents ràpids pot bloquejar-lo i afegir una segona fallada artificial damunt de la real. Anoteu quants intents s’han fet ja, perquè un bloqueig no es confongui més tard amb un símptoma nou. Un compte bloquejat també us treu la capacitat de distingir una contrasenya incorrecta d’una política rebutjada, ja que totes dues arriben com una negativa.

Llegiu l’esdeveniment d’identitat d’aquell únic intent

Demaneu a l’administrador que extregui el registre d’autenticació que coincideix amb el minut que heu anotat. En un desplegament de Windows NPS, la guia de resolució de problemes de NPS de Microsoft documenta l’esdeveniment de rebuig 6273 juntament amb el codi de motiu que l’acompanya, que normalment separa un usuari desconegut, unes credencials dolentes, un desajust de política i una trucada caiguda per un motiu no relacionat.

Un resultat buit també és informació. Si no ha arribat res al servei d’identitat, l’intent ha mort abans: una adreça de passarel·la obsoleta al perfil, un oient al qual el client no pot arribar, o un amfitrió que es va retirar mentre el perfil continuava viu. Si el registre existeix i informa d’èxit, les credencials no són el problema i l’argument es trasllada a l’autorització o a l’encaminament darrere de la passarel·la. Aquests dos resultats apunten en direccions oposades, i per això la cerca als registres ha de passar abans que algú reinstal·li un client.

Guardeu el codi de motiu al tiquet. Aquest únic camp converteix la propera aparició en una consulta de cinc minuts en lloc d’una investigació repetida. Aparelleu-lo amb la versió del client, perquè un codi que apareix en una compilació és una conversa diferent d’un que apareix a totes les compilacions.

Canvieu una condició alhora, dins de la política

La temptació és reinstal·lar el client, restablir la contrasenya i moure el portàtil a una altra xarxa en una sola passada. Això de vegades arregla el símptoma i sempre destrueix les proves. Trieu en canvi un sol bescanvi permès: la mateixa persona en un segon dispositiu inscrit, o una identitat de prova aprovada al mateix dispositiu. Cada bescanvi respon exactament una pregunta, de manera que un èxit estreny la fallada cap al costat que heu canviat en lloc de culpar la VPN sencera.

No demaneu prestades les credencials d’un col·lega per fer aquesta comparació. Utilitzeu una identitat de prova mitjançant el procés admès, i no copieu mai una clau de dispositiu ni us saltu la inscripció perquè seria més ràpid. On la política prohibeix del tot un bescanvi, aquesta restricció forma part del sistema sota prova i pertany al registre, no a una solució alternativa.

Confirmeu la reparació al camí original

Quan s’identifica l’eslavó trencat, repareu només aquest eslavó i repetiu l’intent original: mateixa persona, mateix dispositiu, mateixa xarxa, mateixa aplicació. Un compte de prova que es connecta des de la VLAN d’administració demostra que la passarel·la és viva, i no demostra res sobre el dimarts al matí de l’usuari. Demaneu a l’usuari que faci l’acció que va fallar i no una de més simple, ja que un ping correcte diu poc sobre un recurs compartit rebutjat.

Tanqueu el tiquet amb què s’ha descartat i què ha canviat. Aquesta nota és la diferència entre un rescat puntual i una cosa que el proper enginyer de guàrdia podrà reutilitzar.