Tempo limite do L2TP no Ubuntu 22.04: o bug do túnel do xl2tpd

O ambiente de trabalho mostra uma ligação em curso, o IPsec comunica sucesso e a interface PPP nunca aparece. No syslog, o mesmo número de túnel repete-se até a tentativa expirar em UDP 1701. Antes de editar a chave pré-partilhada ou a configuração do servidor, reconheça esta forma: no Ubuntu 22.04 costuma ser uma regressão de empacotamento no xl2tpd, e o servidor estava correto o tempo todo.

O que o par de linhas repetido no syslog lhe diz

Uma sessão que falha imprime um par de linhas em intervalos regulares: o daemon não encontra um túnel para uma mensagem de controlo recebida e depois despeja os identificadores de chamada e de túnel que recebeu. Mais tarde, o contador de novas tentativas atinge o limite e a ligação fecha com um tempo limite na porta 1701. Os endereços e identificadores são casuais; a forma é o que importa. O IKE concluiu, o tráfego de controlo L2TP chegou e o daemon não conseguiu associá-lo a um túnel que já tinha criado.

A falha situa-se, portanto, entre o controlo L2TP e o PPP. Nada sobre o segredo, as opções PPP ou a sub-rede remota foi ainda testado.

Confirme que o IPsec realmente teve sucesso

Duas verificações separam isto de um problema de credenciais, e ambas vêm antes de qualquer alteração ao pacote.

ipsec status
journalctl -u strongswan --since "5 min ago" | grep -i "shared key"

A saída de estado lista a ligação e o seu estado, e um túnel estabelecido significa que a fase um e a fase dois terminaram. Uma linha de registo sobre uma chave partilhada em falta aponta apenas para o segredo, por isso pare e corrija isso primeiro. Quando o IPsec está estabelecido e o tempo limite do L2TP ainda aparece, o daemon é o suspeito restante. Guarde as linhas exatas de uma tentativa em vez de um dia inteiro de novas tentativas.

Verifique a compilação do xl2tpd, não o nome da versão

A compilação jammy do xl2tpd 1.3.16 do Ubuntu ativou a otimização em tempo de ligação, o que quebrou a análise do identificador de túnel na resposta SCCRP do servidor. O daemon passa então a descartar os pacotes de controlo de um túnel que ele próprio criou. A cadeia de versão importa mais do que o nome da distribuição.

dpkg -l xl2tpd
apt policy xl2tpd
apt-mark showhold

O pacote corrigido é o 1.3.16-1ubuntu0.1, por isso uma compilação sem esse sufixo é anterior à correção. A saída de políticas mostra que candidato uma atualização instalaria, e a lista de retidos explica porque não chegou uma correção. Onde o pacote está disponível, atualize-o e volte a ligar-se pelo perfil normal em vez de editar ficheiros à mão. Não reconstrua módulos nem altere o segredo enquanto a compilação antiga estiver instalada.

Verifique o PPP após a alteração

Uma atualização bem-sucedida prova-se na camada que estava quebrada. Verifique se o PPP subiu, não apenas se o ícone mudou.

ip -4 addr show ppp0
ip route | grep ppp

A lista de interfaces deve mostrar um endereço local e um de par, e a tabela de rotas deve transportar os prefixos do túnel. O syslog deve mostrar o túnel aceite e o pppd a comunicar ambos os endereços, sem linhas repetidas de túnel não encontrado. Se o PPP está ativo e o tráfego continua a falhar, veja a seguir o encaminhamento ou a MTU, porque a etapa L2TP já terminou o seu trabalho. Anote a versão do pacote que funciona nas notas da máquina, para que uma futura reinstalação não reponha a compilação quebrada.

Onde o pacote corrigido não está disponível, as alternativas documentadas são uma compilação local a partir do código-fonte 1.3.16 ou 1.3.17, uma mudança para o kl2tpd ou um downgrade fixado. Cada uma acarreta um custo de manutenção que vale a pena registar.