L2TP quebrado no Ubuntu 24.04: xl2tpd ou demónio go-l2tp?

O Ubuntu 24.04 substituiu silenciosamente o demónio por trás da extensão L2TP do NetworkManager. O caminho mais antigo usava xl2tpd; a embalagem mais recente traz uma implementação em Go que cria um demónio chamado kl2tpd. A extensão inicia o que estiver instalado, pelo que a atualização pode substituir o demónio sem tocar no perfil nem nas credenciais. É toda a falha: uma mensagem de controlo que o novo demónio não reconhece.

A extensão coordena IPsec, L2TP e PPP e depois entrega a interface resultante ao NetworkManager. Não implementa o L2TP por si própria.

A extensão é um coordenador, não um demónio

network-manager-l2tp executa o auxiliar IPsec, um demónio L2TP e PPP, e liga a interface à gestão de ligações do ambiente de trabalho. Durante anos o demónio foi xl2tpd, e cada tutorial que mencionava a sua configuração herdou esse pressuposto. A embalagem Debian aceitou depois qualquer uma das duas implementações, e a 24.04 instala a de Go, que fornece kl2tpd. Nenhum campo do perfil registe qual o demónio que corria antes, pelo que a substituição fica invisível até uma mensagem ser rejeitada.

Uma máquina com ambos os pacotes pode continuar a não executar o que espera. A escolha é decisão da extensão, não do guia que seguiu.

Leia a etapa antes de escolher uma reparação

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

Correlacione uma única tentativa entre os auxiliares em vez de confiar na notificação do ambiente de trabalho. Essa consulta mostra onde a sequência parou, e dpkg -l mostra que implementação está instalada. Uma falha que aparece depois de o par IPsec estar estabelecido, e que menciona uma mensagem de controlo ou um atributo desconhecido, aponta para o demónio. Uma falha antes de o túnel existir significa que o demónio nunca foi alcançado.

Uma divergência na chave pré-partilhada termina na etapa IPsec e nomeia o par. O problema de credenciais PPP aparece depois de o túnel estar levantado e normalmente traz uma rejeição CHAP ou MS-CHAP legível. Ambos são visíveis na mesma consulta, e são problemas diferentes.

Dois caminhos, e não se misturam

sudo apt install xl2tpd
sudo apt purge go-l2tp

Esse par coloca xl2tpd e depois remove o demónio Go, deixando a extensão escolher a implementação cujo dialeto o gateway fala. A ordem importa: a extensão depende de uma ou da outra implementação, pelo que purgar primeiro o pacote Go leva a extensão consigo. O segundo caminho mantém o demónio Go e passa para uma compilação mais recente que compreende a mensagem, o que normalmente significa um PPA do mantenedor em vez da versão do arquivo. Numa frota gerida, fixar um PPA é mais fácil de justificar do que ensinar os utilizadores a purgar pacotes.

Não combine os dois numa só alteração. Uma falha posterior deixa-o então sem poder dizer que metade ajudou, e uma atualização futura pode restaurar o pacote que acabou de remover.

Coloque no ticket o binário do demónio, a versão e a mensagem exata. Ninguém consegue reproduzir um relatório que só diz que o L2TP quebrou após o lançamento, enquanto um atributo nomeado mais uma versão de pacote lhes dá um ponto de partida.

Três coisas que não é

Não é um problema de perfil, já que o mesmo perfil funcionava na 22.04 com o mesmo gateway. Não é uma rota em falta nem uma alteração na firewall, porque essas falham noutro sítio com provas diferentes. Reinstalar a extensão também não o repara, já que o mesmo demónio volta a ser escolhido. A descrição útil nomeia o demónio e a mensagem que ele rejeitou.

Uma correção do lado do gateway é o outro desfecho legítimo. O firmware que deixa de enviar o atributo sobrevive a cada atualização do cliente, enquanto fixar um pacote só sobrevive ao lançamento seguinte da distribuição se alguém se lembrar por que está fixo.

Compare os dois caminhos pelo custo de manutenção em vez da velocidade. Ambos podem funcionar; só um elimina a divergência de dialeto.