L2TP: segnale fatale 15, NO_PROPOSAL_CHOSEN e modp1024 mancante

La connessione si blocca, il client esce e l’ultima riga sullo schermo è death_handler: Fatal signal 15 received. Quella riga segnala un’interruzione, non una causa. Una riga sopra nel log IPsec c’è quasi sempre NO_PROPOSAL_CHOSEN, e la coppia punta alla fase 2 dello scambio, dove i peer confrontano le scelte di cifratura e hash e si fermano quando non ne condividono nessuna. Le credenziali non sono ancora state inviate in quella fase, quindi ridigitare la password non può cambiare il risultato.

Di solito due cose svuotano quell’intersezione su un client Linux. Il demone locale potrebbe non implementare più il gruppo Diffie-Hellman richiesto dal profilo, oppure il profilo porta una proposta di fase 1 in un campo di fase 2. Entrambe lasciano traccia nel log, e nessuna delle due è un problema di account.

Che cosa dicono davvero i due messaggi

IKE negozia a passaggi. La fase 1 costruisce un canale protetto e sceglie i propri algoritmi; la fase 2, la SA figlia, trasporta il traffico con un insieme separato. NO_PROPOSAL_CHOSEN è la notifica che un risponditore restituisce quando nessuna delle combinazioni offerte è accettabile, e compare come [ HASH N(NO_PROP) ] dentro uno scambio INFORMATIONAL.

Il segnale 15 è un altro evento: qualcosa ha detto al processo locale di fermarsi e il gestore lo ha registrato. Quando le due righe compaiono insieme l’ordine è causale, prima il rifiuto e poi lo spegnimento.

Leggi la negoziazione prima di toccare le credenziali

Alza il livello di log dove scrive il demone, poi riconnettiti osservando l’output. Su un host NetworkManager il plugin L2TP passa quel livello al backend, e i messaggi finiscono nel journal o nel file syslog classico a seconda della distribuzione. Uno di questi mostrerà lo scambio: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' o tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

Una riga che nomina pluto viene da libreswan, charon da strongSwan, ed entrambe descrivono la stessa condizione con parole diverse. La forma che vale la pena cercare è quella che nomina il gruppo mancante, per esempio algorithm 'modp1024' is not supported, perché trasforma un guasto vago in uno preciso.

Dove è finito modp1024

Il gruppo 2 di Diffie-Hellman è abbastanza debole che diverse distribuzioni hanno smesso di compilarlo in libreswan dalla 3.30 in poi. Allora un profilo scritto anni fa, o preso da una guida per gateway che elenca solo aes128-sha1-modp1024, chiede al demone locale qualcosa che non può affatto eseguire. Le build più recenti di NetworkManager-l2tp rendono quell’esito più probabile: dalla 1.2.16 sostituiscono l’insieme con proposte in stile Windows 10 e iOS e abbandonano modp1024 appena viene rilevato libreswan. L’estremità remota spesso è innocente e continua a offrire esattamente il gruppo che hai configurato.

È questa asimmetria che fa sembrare casuale il guasto. Un client più vecchio si connette, lo stesso profilo su un portatile aggiornato no, e la configurazione del server non si è mai mossa. Il danno lo fa la deriva delle versioni.

Due riparazioni con raggio diverso

La riparazione a buon mercato è smettere di codificare gli algoritmi a mano. Svuota entrambi i campi delle proposte nell’editor e lascia che il plugin scelga un insieme accettato dall’estremità remota; se il gateway supporta gruppi moderni, la negoziazione si completa senza altro lavoro.

La seconda riparazione mantiene raggiungibile un gateway vecchio installando strongSwan, i cui pacchetti implementano ancora il gruppo 2 sulla maggior parte delle distribuzioni. È un cambio di demone, quindi costa qualcosa: verifica se altri tunnel sull’host dipendono dalla configurazione di libreswan prima di rimuoverlo, e aspettati dinieghi SELinux tra NetworkManager e il plugin strongSwan su Fedora. Quei dinieghi compaiono nel log di audit e non nella traccia IKE, ed è per questo che un tunnel può sembrare rotto subito dopo un’installazione riuscita. L’ordine che funziona è prima dnf install strongswan, poi rpm -e libreswan.

Stringhe di proposta che combaciano, e le trappole intorno

Quando i campi vanno riempiti a mano, la fase 1 e la fase 2 prendono valori diversi. Una coppia nota per funzionare contro un’estremità in stile Meraki offre aes128-sha1-modp1024 in fase 1 con 3des-sha1-modp1024 dietro, entrambe chiuse da un punto esclamativo che rende rigoroso l’insieme, così vengono inviate solo quelle proposte.

La fase 2 poi si restringe a aes128-sha1 e 3des-sha1 con lo stesso marcatore rigoroso e senza alcun suffisso Diffie-Hellman. Una riga di fase 2 che porta -modp1024 è un valore di fase 1 nel campo sbagliato, e il risponditore la rifiuta a ogni tentativo. Copia quella riga in un secondo profilo e il secondo profilo fallisce allo stesso modo, ed è così che un refuso diventa un incidente per l’intera flotta.

Altri guasti indossano lo stesso popup senza essere disallineamenti di proposta. Su KDE il tipo L2TP può comparire nell’elenco con il plugin installato mentre ogni connessione muore subito, perché l’editor delle connessioni e gli helper di runtime arrivano come pacchetti separati. Gli host senza schermo possono riusare un profilo da un desktop funzionante: copialo da /etc/NetworkManager/system-connections/, imposta la modalità su 600, poi esegui nmcli con reload. Alzalo con nmcli con up id work-l2tp, dato che la forma nuda vuole un UUID, e rimuovi ogni voce ifname obsoleta, altrimenti il gestore risponde Could not find source connection mentre tutto il resto è corretto.

Una chiave pre-condivisa può essere memorizzata in chiaro o come 0s seguito da base64; entrambe le forme funzionano, ma il valore deve corrispondere al gateway byte per byte, compresi gli spazi finali che hai copiato con essa.