PSK L2TP/IPsec rifiutata: passa dalla finestra di dialogo, poi dai file

Incolli la chiave precondivisa dal messaggio dell'amministratore nella finestra di dialogo di NetworkManager, spunti la casella per mostrarla e la chiave combacia carattere per carattere. La connessione finisce comunque con un errore di autenticazione prima che il tunnel sia attivo. La prima volta che l'ho visto ho pensato che la chiave fosse sbagliata; non lo era. Altre due cose decidono ciò che il demone legge davvero: il file di segreti che il plugin scrive per quella connessione e se il valore ha attraversato la finestra senza modifiche.

Il percorso qui sotto segue la chiave dal campo al file, e questo è l'ordine che ti dice dove si è persa. Fallo sulla macchina che fallisce, non su quella che funziona, perché la differenza tra le due è di solito la disposizione dei file e non la chiave.

Parti dalla finestra di dialogo, ma non fidarti del campo

Apri la scheda IPsec della connessione e ridigita la chiave invece di incollarla. Una chiave copiata da un messaggio di chat, da un PDF o da un gestore di password può arrivare con un'interruzione di riga finale che il campo non mostra, e i caratteri visibili sembrano comunque corretti.

Fai clic sul controllo che mostra la password e guarda la fine della stringa, non il centro. Se il cursore lascia una riga vuota sotto il testo, cancellala e ridigita l'ultimo carattere. Questa sola correzione risolve una parte sorprendente di queste segnalazioni e costa meno che leggere qualsiasi log.

Se la chiave arriva da un sistema di ticket che spezza le righe lunghe, richiedila tramite un canale che non le spezzi. Confronta le lunghezze con l'amministratore invece di guardare due stringhe affiancate; un carattere perso in un punto di taglio è invisibile in un carattere proporzionale.

Segui la chiave dentro /etc/ipsec.d

Il plugin non consegna mai la PSK al demone IPsec come argomento sulla riga di comando. Invece salva il valore in un file di segreti e fa in modo che il demone lo includa, aggiungendo una riga include a /etc/ipsec.secrets se non ce n'è una. Ciò che la finestra trattiene è un input per quel file generato, non il valore in uso.

Elenca ciò che esiste prima di cambiare qualcosa:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

Le versioni precedenti del plugin scrivevano un file per connessione, chiamato come l'UUID della connessione, per esempio /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Eliminare un profilo nell'applet non elimina quel file in modo affidabile. Se un vecchio file di un server precedente è ancora sul disco e ancora incluso, il demone può scegliere un segreto che appartiene a un profilo che non usi più, e la connessione fallisce mentre il campo visibile è corretto.

Capisci cosa ha fatto il cambiamento 1.2.12 agli aggiornamenti

La versione 1.2.12 del plugin ha sostituito i file di segreti per connessione con un unico file condiviso, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Un aggiornamento non ripulisce i file più vecchi per UUID, e una riga include /etc/ipsec.d/*.secrets esistente li include ancora. La versione 1.2.16 ha cambiato la gestione delle proposte predefinite, non la disposizione dei segreti.

Questa storia spiega perché due macchine con quello che sembra lo stesso profilo si comportano diversamente. La chiave è identica; l'insieme dei file che il demone include non lo è. Quando rimuovi un file orfano, spostalo da parte invece di cancellarlo, conferma la connessione, poi cancellalo quando lo stato funzionante è registrato. Rinominarlo mantiene recuperabile il vecchio valore se il guasto si rivela altrove.

Separa i caratteri che il formato di archiviazione non può contenere

La documentazione di strongSwan sulla stringa del segreto condiviso afferma che il valore non può contenere un'interruzione di riga né un carattere di virgolette doppie. Una chiave incollata da un documento può portare l'uno o l'altro senza alcuna differenza visiva in una finestra normale.

Dal 1.2.12 il valore memorizzato non è testo semplice. Il plugin codifica la PSK in base64 prima che raggiunga il file, e le note di rilascio presentano quella codifica come la ragione per cui ora una virgoletta doppia è accettabile in una chiave. Una virgoletta digitata nel campo è quindi rappresentabile; lo stesso non vale per ogni carattere di controllo.

La lunghezza è un altro vincolo. Nessun minimo universale vale per il software L2TP/IPsec: alcuni client accettano chiavi più corte di venti caratteri e alcuni gateway impongono un minimo. Se una chiave corta viene rifiutata, la regola appartiene alla politica del server o alla validazione di quel client, e alzare qualcosa in locale non la cambierà.

Leggi quale livello di autenticazione ha fallito

Esegui prima ipsec --version, perché strongSwan e Libreswan usano nomi di file e sintassi diversi, e un consiglio per uno può danneggiare l'altro. Poi leggi la fase del guasto dal messaggio del client o dal log del demone: una lamentela sulla chiave precondivisa è un evento diverso da un nome utente e una password rifiutati.

La PSK autentica gli estremi del tunnel. Il nome utente e la password autenticano la persona dentro L2TP, e PPP se ne occupa dopo che l'associazione IPsec è attiva. Una PSK corretta con un account sbagliato fallisce comunque, e cambiare account non riparerà una chiave che il demone non ha mai letto correttamente.

Quando chiudi il ticket, annota tutti e quattro: versione del plugin, file di segreti in uso, se la chiave è stata ridigitata o incollata e il livello indicato nell'errore. Così chi ripeterà questo percorso potrà saltare direttamente alla differenza tra la macchina che funziona e quella che fallisce.