Un errore, tre segreti: quale credenziale VPN ha fallito?
Il client mostra un errore per ogni fase. Leggi l’associazione, lo scambio utente e il metodo prima di reimpostare una password che nessuno ha verificato.
«Autenticazione non riuscita» può indicare un certificato del server, una chiave precondivisa della macchina o una password utente. Quale delle tre dipende dal protocollo, perché ogni protocollo definisce un insieme diverso di segreti. Reimposta quello sbagliato e l’errore resta invariato. La via d’uscita è stabilire quante prove richiede il protocollo prima di modificare qualsiasi cosa.
Due prove che puntano in direzioni opposte
Un tunnel deve rispondere se ha raggiunto il gateway giusto e, separatamente, chi è l’utente. La prova del gateway è a livello macchina: un certificato del server, una chiave precondivisa o una chiave pubblica statica. La prova dell’utente è a livello persona: una password, un token, un certificato client o nulla. Sono direzioni di fiducia opposte e consumano materiale diverso.
IKEv2 esegue la prova del gateway dentro IKE_AUTH e, quando si usa EAP, esegue poi la prova dell’utente in uno scambio separato. La specifica IKEv2 le mantiene come sezioni distinte, il che è un forte indizio su dove guardare quando un solo messaggio copre entrambi i round.
Leggi la fase, non il messaggio
Il client mostra un’unica stringa di errore, qualunque fase sia fallita, quindi la stringa in sé non porta quasi nessuna informazione. A portare informazione è lo stato che puoi ispezionare a ogni fase: se esiste un’associazione, se è iniziato uno scambio utente e se il client ha offerto il metodo che il gateway voleva. La tabella ordina le fasi così, invece che per nome del protocollo.
| Stage that failed | Evidence you can inspect | What a password change cannot fix |
|---|---|---|
| The machine proof | no security association in the state list | a mismatched pre-shared key or an untrusted chain |
| The user proof | an association is up while PPP or EAP reports failure | an expired token, a locked account, a missing client key |
| The client's method support | the client offers no method the gateway accepts | a client without the required EAP or key material |
| The server's policy | the gateway rejects before any user exchange starts | a policy that requires a certificate the profile lacks |
Solo la seconda riga riguarda una credenziale che un utente può ridigitare. Le altre tre sono fatti di configurazione, ed è proprio questo disallineamento che fa finire tante di queste segnalazioni con una reimpostazione della password che non cambia nulla. Leggi la riga che corrisponde alla tua prova prima di toccare un campo.
Un protocollo a due segreti mostra le carte
L2TP su IPsec rende visibile il conteggio, perché i due controlli avvengono in processi diversi. Lo strato IPsec deve salire prima con una chiave precondivisa o un certificato, e solo dopo il PPP al suo interno tenta un accesso utente.
Quando il segreto della macchina è sbagliato non si forma alcuna associazione e la credenziale dell’utente non viene mai provata. Quando il segreto della macchina è giusto e quello dell’utente è sbagliato, l’associazione esiste e PPP rifiuta l’accesso dopo che il tunnel è già attivo. Entrambi producono lo stesso messaggio a schermo da due eventi diversi.
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerUn elenco di associazioni vuoto esclude subito lo strato utente, quindi controllalo prima della password. Un’associazione stabilita con ripetuti fallimenti PPP punta nella direzione opposta, verso lo strato utente o verso il protocollo di autenticazione al suo interno. Nessuna delle due conclusioni è disponibile dal testo dell’errore del client.
Da cosa dipende davvero l’accesso con sola password
L’accesso con sola password è normale per L2TP, PPTP, SSTP e IKEv2 con EAP. WireGuard non ha affatto questa opzione, perché i suoi pari sono chiavi e non utenti. Per OpenVPN la risposta viene dal requisito di certificato client del server: un gateway che chiede sia certificato sia password continuerà a rifiutare un client con sola password, qualunque cosa si digiti nel campo.
Quale componente ti serve discende dalla stessa risposta. Un accesso con password sotto IKEv2 richiede un client che parli EAP, mentre un accesso con certificato ha bisogno della chiave privata del client e della catena del server. Installa quello sbagliato e il fallimento si legge come un errore di credenziali anche se manca proprio il metodo di autenticazione.
Cambia una cosa, poi ritesta
Stabilisci prima tre fatti: quale protocollo gira, quanti segreti definisce e quali di essi appartengono alla macchina e non all’utente. Le macchine falliscono al primo stadio e le persone al secondo, e confondere i due è tutto questo problema.
Poi cambia esattamente una cosa e ritesta dallo stesso client. Quella disciplina trasforma un fallimento confuso in una correzione che puoi descrivere alla persona successiva, ed è più utile di una connessione che funziona e che nessuno sa spiegare.