L2TP NO_PROPOSAL_CHOSEN: quale fase ha fallito davvero?

NO_PROPOSAL_CHOSEN arriva prima che venga esaminato qualsiasi nome utente PPP, il che è un fatto utile e anche il motivo per cui il messaggio trae in inganno. Segnala che un lato ha rifiutato una proposta; non segnala quale parametro non coincideva e non dice nulla se il rifiuto sia avvenuto durante la costruzione dell'associazione IKE o più tardi, durante la negoziazione della protezione del traffico. Dietro queste due possibilità ci sono due correzioni diverse, e solo una coinvolge la casella PFS a cui si ricorre per prima.

Un messaggio, due insiemi di proposte

La disposizione IKEv1 L2TP/IPsec prevede due negoziazioni in sequenza. La fase 1 costruisce l'associazione di sicurezza IKE a partire da un algoritmo di cifratura, un algoritmo di integrità e un gruppo Diffie-Hellman. La fase 2 negozia poi come proteggere il traffico, e il requisito PFS appartiene a quella seconda conversazione.

Poiché le fasi sono sequenziali, la posizione del guasto vi dice quale elenco confrontare. È tutto il valore diagnostico del messaggio, e vale la pena estrarlo prima di toccare un'impostazione.

Perché una casella PFS non può riparare la fase 1

Disattivare PFS cambia una proprietà della fase 2. Se le parti non hanno mai concordato la fase 1, la conversazione ESP non avviene affatto, quindi la casella non ha alcun effetto sul rifiuto, ed è per questo che cambiarla produce lo stesso errore con un timestamp diverso.

L'errore inverso è altrettanto comune. Un'associazione IKE riuscita non dimostra che la proposta ESP sia accettabile, e di certo non dimostra che il gruppo della fase 2 corrisponda. Trattate un tunnel di gestione stabilito come prova solo sulla fase 1. Le persone leggono la riga verde come «il tunnel è attivo», poi passano un'ora sulla fase sbagliata perché nulla ha detto loro che la seconda negoziazione non era iniziata.

Leggete il registro prima di scegliere gli algoritmi

Raccogliete i messaggi immediatamente precedenti il rifiuto dal backend che gestisce davvero la connessione e correlateli con lo stesso tentativo. Senza quella correlazione state leggendo la storia di un'altra connessione e ne traete conclusioni.

journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall          # strongSwan
ipsec whack --status     # Libreswan

Da quelle righe, rispondete a due domande: si è stabilita un'associazione di fase 1, e quale scambio ha fallito. Queste due risposte restringono la ricerca a un solo elenco di attributi. Una notifica nuda senza contesto attorno non può farlo, per quanto sia tentante provare una proposta da un thread di forum. Copiare una stringa funzionante da una macchina con un altro backend di solito sostituisce un rifiuto con un altro, poco più tardi.

La sintassi del backend non viaggia

Annotate la versione di NetworkManager-l2tp e quella del backend IPsec prima di confrontare qualcosa. Libreswan e strongSwan non condividono la sintassi delle proposte né insiemi di algoritmi identici, quindi una stringa che funziona in uno è un errore di sintassi nell'altro. Il backend installato può anche rifiutare IKEv1 per politica, e in quel caso nessuna proposta sarà mai accettata.

Il README del progetto documenta queste differenze tra backend e tiene separati i campi della fase 1 e della fase 2. Leggetelo come documentazione della struttura, non come invito ad attivare ogni cifrario storico e un gruppo debole, perché una connessione che riesce solo così non è quella che vi è stato chiesto di costruire.

Concordate la suite, poi verificate le fasi

Chiedete all'operatore del gateway quali suite IKE ed ESP sono supportate e approvate, poi confrontate quella risposta con le proposte effettive del client anziché con il suo file di configurazione. Se il disaccordo riguarda specificamente il PFS di fase 2, scegliete un gruppo supportato o una politica senza PFS approvata esplicitamente. Non deducete la politica dal nome dell'errore.

Quando l'unica sovrapposizione richiede crittografia che l'organizzazione non accetta più, la decisione spetta al gateway o a una migrazione di protocollo. Ampliare la stringa del client finché qualcosa negozia è un modo per consegnare una debolezza nota con una spunta verde accanto.

Dopo aver corretto la divergenza reale, confermate lo stabilimento di IPsec prima di indagare su L2TP e PPP, e trattate qualsiasi rifiuto di autenticazione successivo come appartenente alla fase seguente. Poi provate il rinnovo nel processo di test approvato, perché stabilire la prima associazione non dice nulla sul resto della sua vita.