Autenticazione VPN non riuscita: raramente è la porta o il DNS

Autenticazione non riuscita significa che il servizio ha ricevuto un’identità e l’ha rifiutata, un’affermazione più stretta di quanto la maggior parte delle persone vi legga. La porta è aperta, la sessione TLS può essersi completata e qualcosa nelle credenziali o nell’account è stato respinto. Cambiare le impostazioni di rete non può risolverlo, e ripetere il tentativo può bloccare l’account. Il testo dell’errore nomina già la fase, quindi iniziate da lì.

L’errore vi ha già detto quale fase è fallita

Una connessione che non completa mai la stretta di mano TLS non ha affatto raggiunto l’autenticazione. Una connessione che completa la stretta di mano e poi segnala un rifiuto delle credenziali l’ha raggiunta e lì è fallita. Questi due esiti richiedono indagini diverse, e spesso vengono confusi perché entrambi finiscono con una finestra chiusa.

OpenVPN rende esplicita la distinzione con un messaggio AUTH_FAILED dal server, che è una decisione e non un errore di trasporto. Un timeout della negoziazione TLS o un errore di verifica del certificato appartengono alla fase precedente. Leggete quale avete prima di toccare le credenziali, perché reimpostare la password non può riparare una stretta di mano e cambiare il firewall non può riparare un accesso rifiutato. Una riga del registro del client risponde alla domanda.

La stessa logica vale per una sessione che si connette e poi cade. Un guasto di riautenticazione al quarantesimo minuto è un difetto diverso da un rifiuto al primo accesso, e l’intervallo è l’indizio.

Confermate che il profilo punti al servizio giusto

L’account usato sul sito di un provider non è sempre quello accettato dal suo gateway VPN. Un profilo salvato può anche puntare a un vecchio gateway molto tempo dopo che il servizio si è spostato.

Confrontate l’endpoint del profilo con quello pubblicato dall’operatore e controllate quale sistema di identità consulta il gateway. Reimpostare la password su un portale web non cambia nulla se il tunnel si autentica su una directory separata. Le credenziali di un server pubblico non correlato non funzioneranno sul vostro, e testare una password di lavoro in un profilo ricevuto tramite un messaggio non attendibile è comunque un cattivo scambio. Confermate l’origine prima di digitare qualsiasi cosa.

Due minuti sul profilo evitano un giorno di tentativi sulle credenziali.

Il formato di accesso fa parte delle credenziali

Un nome utente può richiedere una forma e-mail, un prefisso di dominio o un suffisso di directory. Il gateway confronta la stringa ricevuta, quindi il formato fa parte delle credenziali e non è decorazione.

Poi escludete le cause banali prima di escalare. Controllate la disposizione della tastiera, eventuali spazi finali introdotti da un copia-incolla e una vecchia voce nel gestore di password. Dopo una reimpostazione, confermate che la VPN usi la stessa fonte di identità della pagina in cui la password è stata cambiata. Se questi dettagli sono corretti, smettete di indovinare e chiedete all’operatore se l’account è abilitato e autorizzato all’accesso VPN. È una correzione lato servizio, non un’impostazione del client.

openvpn --config office.ovpn --verb 3
journalctl -u openvpn-client@office -n 40 --no-pager

La riga di registro che porta AUTH_FAILED di solito include un codice di motivo o una stringa di challenge. Copiatela esattamente invece di parafrasarla quando chiedete aiuto.

I secondi fattori hanno il proprio contratto

Il profilo può aspettarsi un codice monouso, una challenge interattiva o un accesso dal browser che restituisce un token al client. Usate il flusso supportato dall’operatore invece di inventarne uno.

Non aggiungete un codice alla password a meno che quel formato sia esplicitamente richiesto, perché alcune installazioni usano un campo separato e altre una stringa di challenge. Per i codici basati sul tempo, controllate l’orologio del dispositivo, dato che pochi minuti di scarto invalidano ogni codice. Se l’accesso dal browser riesce e il client non riprende mai, annotate esattamente quel punto, perché identifica la consegna e non la credenziale. Un’altra reimpostazione della password probabilmente non aiuterà.

Il limite di sessioni è l’altro rifiuto comune. Se l’account consente una sola sessione, un secondo accesso può terminare il primo, e il sintomo sembra una connessione intermittente più che una politica.

Un certificato non è una password

Un certificato client può scadere o essere revocato mentre la password dell’account resta perfettamente corretta. La passphrase di una chiave privata è di nuovo un terzo segreto, e protegge un file e non un account.

Leggete l’errore prima di sostituire qualsiasi cosa, poi ottenete la sostituzione corretta dall’operatore verificato. Tenete attiva la verifica dell’identità del server mentre lo fate: accettare un certificato non correlato o copiare la chiave privata di qualcun altro non è una riparazione, è un secondo incidente. Poi testate la risorsa di cui avete davvero bisogno, perché un tunnel connesso con un servizio irraggiungibile appartiene a un’altra indagine. Annotate quale fase è fallita così la persona successiva non ricomincia l’intero processo.

Se la sessione si stabilisce e fallisce più tardi, registrate l’intervallo e qualsiasi evento di rinnovo vicino. Quel registro separa un problema di durata del token da un guasto al primo accesso, ed è la differenza tra una correzione di cinque minuti e una settimana di nuovi tentativi.