Un utente non riesce ad accedere alla VPN: una diagnosi ordinata

Quando una persona non riesce a connettersi mentre il resto del team continua a lavorare, la domanda utile non è che cosa è rotto, ma quale strato non è stato d’accordo. L’accesso è una catena: il client parte, il gateway risponde, un’identità viene affermata, un secondo fattore viene soddisfatto, la policy viene valutata, e solo allora il traffico fluisce. Una rottura in qualsiasi punto di quella catena arriva a voi come la stessa frase dell’utente, quindi il primo lavoro è trovare l’anello che ha davvero fallito.

Trattate il rapporto come un punto di partenza e non come una diagnosi. I controlli qui sotto vanno dal più economico, e ciascuno è scritto per chiudere l’indagine quando fallisce.

Fissate la fase e il timestamp

Annotate quattro cose prima di toccare qualsiasi configurazione: il client e la sua versione, la formulazione esatta sullo schermo, il minuto del tentativo e la rete in cui si trovava la persona. La formulazione porta informazione reale, perché credenziali rifiutate, un gateway che non risponde e un accesso completato che ancora non riesce ad aprire una pagina interna sono tre problemi diversi con tre responsabili diversi. Notate se il client ha prodotto una riga di log locale, poiché un client che non ha mai inviato un pacchetto non ha nulla da aggiungere a una ricerca lato server. Con il timestamp registrato, ogni interrogazione successiva diventa una ricerca e non una caccia.

Smettete di indovinare le password a questo punto. Dove l’account ha un limite di tentativi, una raffica di tentativi rapidi può bloccarlo e aggiungere un secondo guasto artificiale sopra quello reale. Annotate quanti tentativi sono già stati fatti, così un blocco non venga poi scambiato per un sintomo nuovo. Un account bloccato vi toglie anche la capacità di distinguere una password sbagliata da una policy rifiutata, poiché entrambe arrivano come un rifiuto.

Leggete l’evento di identità di quel singolo tentativo

Chiedete all’amministratore di estrarre il record di autenticazione che corrisponde al minuto annotato. In un deployment di Windows NPS, la guida alla risoluzione dei problemi di NPS di Microsoft documenta l’evento di rifiuto 6273 insieme al codice di motivo che lo accompagna, che di solito separa un utente sconosciuto, credenziali errate, una discordanza di policy e una chiamata caduta per un motivo non correlato.

Un risultato vuoto è anch’esso informazione. Se nulla ha raggiunto il servizio di identità, il tentativo è morto prima: un indirizzo di gateway obsoleto nel profilo, un listener che il client non riesce a raggiungere, o un host dismesso mentre il profilo continuava a vivere. Se il record esiste e riporta successo, le credenziali non sono il problema e l’argomento si sposta sull’autorizzazione o sull’instradamento dietro il gateway. Questi due esiti puntano in direzioni opposte, perciò la ricerca nei log deve avvenire prima che qualcuno reinstalli un client.

Tenete il codice di motivo nel ticket. Quel singolo campo trasforma l’occorrenza successiva in una ricerca di cinque minuti invece di un’indagine ripetuta. Abbinate lo alla versione del client, perché un codice che appare su una build è una conversazione diversa da uno che appare su ogni build.

Cambiate una condizione alla volta, entro la policy

La tentazione è reinstallare il client, reimpostare la password e spostare il portatile su un’altra rete in un solo passaggio. Questo a volte risolve il sintomo e distrugge sempre le prove. Scegliete invece un solo scambio consentito: la stessa persona su un secondo dispositivo registrato, o un’identità di test approvata sullo stesso dispositivo. Ogni scambio risponde esattamente a una domanda, così un successo restringe il guasto al lato che avete cambiato invece di incolpare la VPN nel suo insieme.

Non prendete in prestito le credenziali di un collega per questo confronto. Usate un’identità di test tramite il processo supportato, e non copiate mai una chiave del dispositivo né saltate la registrazione perché sarebbe più rapido. Dove la policy vieta del tutto uno scambio, quella restrizione fa parte del sistema in prova e appartiene al verbale, non a una soluzione tampone.

Confermate la riparazione sul percorso originale

Quando l’anello rotto è identificato, riparate solo quell’anello e ripetete il tentativo originale: stessa persona, stesso dispositivo, stessa rete, stessa applicazione. Un account di test che si connette dalla VLAN di amministrazione dimostra che il gateway è vivo, e non dimostra nulla sul martedì mattina dell’utente. Chiedete all’utente di eseguire l’azione che è fallita e non una più semplice, poiché un ping riuscito dice poco su una condivisione file rifiutata.

Chiudete il ticket con ciò che è stato escluso e ciò che è cambiato. Quella nota è la differenza tra un salvataggio una tantum e qualcosa che il prossimo ingegnere di turno potrà riutilizzare.