L2TP: sinal fatal 15, NO_PROPOSAL_CHOSEN e modp1024 em falta

A ligação bloqueia, o cliente termina e a última linha no ecrã é death_handler: Fatal signal 15 received. Essa linha relata uma interrupção, não uma causa. Uma linha acima, no registo do IPsec, está quase sempre NO_PROPOSAL_CHOSEN, e o par aponta para a fase 2 da troca, onde os pares comparam as escolhas de cifra e de hash e param quando não têm nenhuma em comum. As credenciais ainda não foram enviadas nessa fase, por isso voltar a escrever a palavra-passe não pode alterar o resultado.

Normalmente duas coisas esvaziam essa interseção num cliente Linux. O daemon local pode já não implementar o grupo Diffie-Hellman que o perfil pede, ou o perfil pode transportar uma proposta de fase 1 num campo de fase 2. Ambas deixam rasto no registo, e nenhuma é um problema de conta.

O que as duas mensagens dizem na realidade

O IKE negocia por passagens. A fase 1 constrói um canal protegido e escolhe os seus próprios algoritmos; a fase 2, a SA filha, transporta tráfego sob um conjunto separado. NO_PROPOSAL_CHOSEN é a notificação que o respondente devolve quando nenhuma das combinações oferecidas é aceitável, e aparece como [ HASH N(NO_PROP) ] dentro de uma troca INFORMATIONAL.

O sinal 15 é outro acontecimento: algo disse ao processo local para parar e o gestor registou-o. Quando as duas linhas aparecem juntas, a ordem é causal: primeiro a rejeição e depois o encerramento.

Leia a negociação antes de tocar nas credenciais

Aumente o nível de registo onde o daemon escreve e volte a ligar enquanto observa a saída. Num anfitrião com NetworkManager o plugin L2TP passa esse nível para o backend, e as mensagens ficam no journal ou no ficheiro syslog clássico conforme a distribuição. Qualquer destes mostrará a troca: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' ou tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

Uma linha que nomeia pluto vem do libreswan, charon do strongSwan, e ambas descrevem a mesma condição com palavras diferentes. A forma que vale a pena procurar é a que nomeia o grupo em falta, por exemplo algorithm 'modp1024' is not supported, porque transforma uma falha vaga numa concreta.

Para onde foi o modp1024

O grupo 2 de Diffie-Hellman é suficientemente fraco para que várias distribuições tenham deixado de o compilar no libreswan a partir da 3.30. Então um perfil escrito há anos, ou copiado de um guia de gateway que só lista aes128-sha1-modp1024, pede ao daemon local algo que ele não consegue executar de todo. As compilações mais recentes do NetworkManager-l2tp tornam esse desfecho mais provável: desde a 1.2.16 substituem o conjunto por propostas ao estilo do Windows 10 e do iOS e descartam o modp1024 assim que o libreswan é detetado. O extremo remoto é muitas vezes inocente e continua a oferecer exatamente o grupo que configurou.

É essa assimetria que faz a falha parecer aleatória. Um cliente antigo liga-se, o mesmo perfil num portátil atualizado não, e a configuração do servidor nunca se mexeu. O dano é causado pela deriva de versões.

Duas reparações com âmbito diferente

A reparação barata é deixar de fixar os algoritmos à mão. Limpe os dois campos de propostas no editor e deixe o plugin escolher um conjunto que o extremo remoto aceite; se o gateway suportar grupos modernos, a negociação termina sem mais trabalho.

A segunda reparação mantém acessível um gateway antigo instalando o strongSwan, cujos pacotes ainda implementam o grupo 2 na maioria das distribuições. Isso é uma troca de daemon, por isso tem custo: confirme se outros túneis no anfitrião dependem da configuração do libreswan antes de o remover, e conte com negações do SELinux entre o NetworkManager e o plugin strongSwan no Fedora. Essas negações aparecem no registo de auditoria e não no traço do IKE, e é por isso que um túnel pode parecer avariado logo após uma instalação bem-sucedida. A ordem que funciona é primeiro dnf install strongswan, depois rpm -e libreswan.

Cadeias de propostas que coincidem, e as armadilhas à volta

Quando os campos têm de ser preenchidos à mão, a fase 1 e a fase 2 tomam valores diferentes. Um par conhecido por funcionar contra um extremo ao estilo Meraki oferece aes128-sha1-modp1024 na fase 1 com 3des-sha1-modp1024 por trás, ambos fechados por um ponto de exclamação que torna o conjunto estrito, pelo que só essas propostas são enviadas.

A fase 2 estreita-se então para aes128-sha1 e 3des-sha1 com o mesmo marcador estrito e sem qualquer sufixo Diffie-Hellman. Uma linha de fase 2 com -modp1024 é um valor de fase 1 no campo errado, e o respondente rejeita-a em cada tentativa. Copie essa linha para um segundo perfil e o segundo perfil falha da mesma forma, e é assim que um erro de escrita se torna um incidente para toda a frota.

Outras falhas vestem a mesma janela sem serem desalinhamentos de propostas. No KDE o tipo L2TP pode aparecer listado com o plugin instalado enquanto cada ligação morre de imediato, porque o editor de ligações e os auxiliares de execução são distribuídos em pacotes separados. Os anfitriões sem ecrã podem reutilizar um perfil de um ambiente de trabalho funcional: copie-o de /etc/NetworkManager/system-connections/, ponha o modo em 600 e depois execute nmcli con reload. Suba-o com nmcli con up id work-l2tp, já que a forma nua pede um UUID, e remova qualquer entrada ifname obsoleta, senão o gestor responde Could not find source connection enquanto tudo o resto está correto.

Uma chave pré-partilhada pode ser guardada como texto simples ou como 0s seguido de base64; ambas as formas funcionam, mas o valor tem de corresponder ao gateway byte a byte, incluindo os espaços finais que copiou com ela.