Ubuntu 24.04 ha sostituito in silenzio il demone dietro il plugin L2TP di NetworkManager. Il percorso più vecchio usava xl2tpd; il pacchetto più recente porta un’implementazione in Go che genera un demone chiamato kl2tpd. Il plugin avvia quello installato, quindi l’aggiornamento può sostituire il demone senza toccare il profilo o le credenziali. È tutto il guasto: un messaggio di controllo che il nuovo demone non riconosce.

Il plugin coordina IPsec, L2TP e PPP, poi consegna l’interfaccia risultante a NetworkManager. Non implementa L2TP da solo.

Il plugin è un coordinatore, non un demone

network-manager-l2tp esegue l’helper IPsec, un demone L2TP e PPP, e collega l’interfaccia alla gestione delle connessioni del desktop. Per anni il demone è stato xl2tpd, e ogni guida che ne citava la configurazione ereditava quel presupposto. Il pacchetto Debian ha poi accettato l’una o l’altra implementazione, e 24.04 installa quella in Go, che fornisce kl2tpd. Nessun campo del profilo registra quale demone girasse prima, quindi la sostituzione resta invisibile finché un messaggio non viene rifiutato.

Una macchina con entrambi i pacchetti può comunque non eseguire quello che vi aspettate. La scelta è del plugin, non della guida che avete seguito.

Leggete la fase prima di scegliere una riparazione

journalctl -b --no-hostname _COMM=nm-l2tp-service _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd _COMM=charon _COMM=pluto

Correlate un singolo tentativo tra gli helper invece di fidarvi della notifica del desktop. Quella query mostra dove si è fermata la sequenza, e dpkg -l mostra quale implementazione è installata. Un guasto che compare dopo l’instaurarsi del peer IPsec e che cita un messaggio di controllo o un attributo non riconosciuto indica il demone. Un guasto prima che il tunnel esista significa che il demone non è mai stato raggiunto.

Una discrepanza della chiave precondivisa termina alla fase IPsec e nomina il peer. Il problema delle credenziali PPP compare a tunnel sollevato e di solito porta un rifiuto CHAP o MS-CHAP leggibile. Entrambi si vedono nella stessa query, e sono problemi diversi.

Due percorsi, e non si mescolano

sudo apt install xl2tpd
sudo apt purge go-l2tp

Quella coppia installa xl2tpd e poi rimuove il demone Go, lasciando al plugin la scelta dell’implementazione di cui il gateway parla il dialetto. L’ordine conta: il plugin dipende dall’una o dall’altra implementazione, quindi rimuovere prima il pacchetto Go porta giù anche il plugin. Il secondo percorso mantiene il demone Go e passa a una build più recente che comprende il messaggio, il che di solito significa un PPA del manutentore invece della versione dell’archivio. In una flotta gestita, bloccare un PPA è più facile da giustificare che insegnare agli utenti a rimuovere i pacchetti.

Non combinate i due in un’unica modifica. Un guasto successivo vi lascerebbe incapaci di dire quale metà ha aiutato, e un aggiornamento futuro può ripristinare il pacchetto appena rimosso.

Mettete nel ticket il binario del demone, la sua versione e il messaggio esatto. Nessuno può riprodurre un rapporto che dice solo che L2TP si è rotto dopo il rilascio, mentre un attributo nominato più una versione di pacchetto dà loro un punto di partenza.

Tre cose che non è

Non è un problema di profilo, visto che lo stesso profilo funzionava su 22.04 con lo stesso gateway. Non è una rotta mancante né una modifica al firewall, perché quelle falliscono altrove con prove diverse. Reinstallare il plugin non lo ripara, perché viene scelto di nuovo lo stesso demone. La descrizione utile nomina il demone e il messaggio che ha rifiutato.

Una correzione lato gateway è l’altro esito legittimo. Il firmware che smette di inviare l’attributo sopravvive a ogni aggiornamento del client, mentre bloccare un pacchetto sopravvive al rilascio successivo della distribuzione solo se qualcuno ricorda perché è bloccato.

Confrontate i due percorsi sul costo di manutenzione invece che sulla velocità. Entrambi possono funzionare; solo uno elimina la discrepanza di dialetto.

Articoli correlati