L2TP en Ubuntu 24.04 roto: xl2tpd ou demo go-l2tp?

Ubuntu 24.04 cambiou en silencio o demo que hai detrás do complemento L2TP de NetworkManager. A vía antiga usaba xl2tpd; o empaquetado máis recente incorpora unha implementación en Go que xera un demo chamado kl2tpd. O complemento inicia o que estea instalado, así que a actualización pode substituír o demo sen tocar o seu perfil nin as súas credenciais. Ese é todo o fallo: unha mensaxe de control que o novo demo non recoñece.

O complemento coordina IPsec, L2TP e PPP, e despois entrega a interface resultante a NetworkManager. Non implementa L2TP por si mesmo.

O complemento é un coordinador, non un demo

network-manager-l2tp executa o axudante de IPsec, un demo L2TP e PPP, e conecta a interface coa xestión de conexións do escritorio. Durante anos o demo foi xl2tpd, e cada titorial que mencionaba a súa configuración herdou ese suposto. O empaquetado de Debian aceptou despois calquera das dúas implementacións, e 24.04 instala a de Go, que proporciona kl2tpd. Ningún campo do perfil rexistra que demo se executaba antes, así que a substitución permanece invisible ata que se rexeita unha mensaxe.

Unha máquina con ambos os paquetes pode seguir sen executar o que vostede espera. A selección é decisión do complemento, non da guía que seguiu.

Lea a etapa antes de escoller unha reparación

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

Correlacione un só intento entre os axudantes en lugar de confiar na notificación do escritorio. Ese consulta mostra onde se detivo a secuencia, e dpkg -l mostra que implementación está instalada. Un fallo que aparece despois de establecerse o par de IPsec e que menciona unha mensaxe de control ou un atributo non recoñecido apunta ao demo. Un fallo antes de que exista o túnel significa que nunca se alcanzou o demo.

Unha discrepancia da clave precompartida remata na etapa de IPsec e nomea o par. O problema de credenciais PPP aparece cando o túnel xa está levantado e normalmente leva un rexeitamento CHAP ou MS-CHAP lexible. Ambos se ven na mesma consulta, e son problemas distintos.

Dúas rutas, e non se mesturan

sudo apt install xl2tpd
sudo apt purge go-l2tp

Ese par coloca xl2tpd e despois elimina o demo Go, deixando que o complemento escolla a implementación cuxo dialecto fala a pasarela. A orde importa: o complemento depende dunha implementación ou da outra, así que purgar primeiro o paquete Go leva o complemento por diante. A segunda ruta conserva o demo Go e pasa a unha compilación máis nova que entende a mensaxe, o que normalmente significa un PPA do mantedor en lugar da versión do arquivo. Nunha frota xestionada, fixar un PPA é máis fácil de xustificar que ensinar aos usuarios a purgar paquetes.

Non combine as dúas nun só cambio. Un fallo posterior déixalle entón sen poder dicir que metade axudou, e unha actualización futura pode restaurar o paquete que acaba de quitar.

Ponxa no tícket o binario do demo, a súa versión e a mensaxe exacta. Ninguén pode reproducir un informe que só di que L2TP se rompeu tras o lanzamento, mentres que un atributo nomeado máis unha versión de paquete lles dá un punto de partida.

Tres cousas que non é

Non é un problema de perfil, xa que o mesmo perfil funcionaba en 22.04 coa mesma pasarela. Non é unha ruta que falta nin un cambio de devasa, porque eses fallan noutro sitio con probas distintas. Reinstalar o complemento tampouco o repara, xa que se volve seleccionar o mesmo demo. A descrición útil nomea o demo e a mensaxe que rexeitou.

Unha corrección no lado da pasarela é o outro desenlace lexítimo. O firmware que deixa de enviar o atributo sobrevive a cada actualización do cliente, mentres que fixar un paquete sobrevive ao seguinte lanzamento da distribución só se alguén lembra por que está fixado.

Compare as dúas rutas polo custo de mantemento en lugar de pola velocidade. Ambas poden funcionar; só unha elimina a discrepancia de dialecto.