L2TP NO_PROPOSAL_CHOSEN: qual fase falhou de facto?

O NO_PROPOSAL_CHOSEN chega antes de qualquer nome de utilizador PPP ser examinado, o que é um facto útil e também a razão pela qual a mensagem induz em erro. Informa que um lado rejeitou uma proposta; não informa que parâmetro divergiu e nada diz sobre se a rejeição ocorreu durante a construção da associação IKE ou mais tarde, ao negociar a proteção do tráfego. Por trás dessas duas possibilidades estão duas correções diferentes, e só uma envolve a caixa PFS a que as pessoas recorrem primeiro.

Uma mensagem, dois conjuntos de propostas

A disposição IKEv1 L2TP/IPsec tem duas negociações em sequência. A fase 1 constrói a associação de segurança IKE a partir de um algoritmo de cifragem, um algoritmo de integridade e um grupo Diffie-Hellman. A fase 2 negoceia depois como o tráfego é protegido, e o requisito de PFS pertence a essa segunda conversa.

Como as fases são sequenciais, a posição da falha diz-lhe que lista comparar. É todo o valor de diagnóstico da mensagem, e vale a pena extraí-lo antes de tocar em qualquer definição.

Porque é que uma caixa PFS não consegue reparar a fase 1

Desativar o PFS altera uma propriedade da fase 2. Se as partes nunca acordaram a fase 1, a conversa ESP nunca acontece, pelo que a caixa não tem qualquer efeito na rejeição, e é por isso que a sua alteração produz o mesmo erro com um carimbo de tempo diferente.

O erro inverso é igualmente comum. Uma associação IKE bem-sucedida não prova que a proposta ESP seja aceitável e decerto não prova que o grupo da fase 2 coincida. Trate um túnel de gestão estabelecido como prova apenas sobre a fase 1. As pessoas leem a linha verde como «o túnel está ativo» e depois passam uma hora na fase errada porque nada lhes disse que a segunda negociação não tinha começado.

Leia o registo antes de escolher algoritmos

Recolha as mensagens imediatamente anteriores à rejeição do backend que realmente trata da ligação e correlacione-as com a mesma tentativa. Sem essa correlação está a ler o histórico de outra ligação e a tirar conclusões dele.

journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall          # strongSwan
ipsec whack --status     # Libreswan

A partir dessas linhas, responda a duas perguntas: estabeleceu-se uma associação de fase 1, e qual troca falhou. Essas duas respostas reduzem a pesquisa a uma única lista de atributos. Uma notificação nua sem contexto em volta não consegue fazê-lo, por mais tentador que seja experimentar uma proposta de um tópico de fórum. Copiar uma cadeia que funciona de uma máquina com outro backend substitui normalmente uma rejeição por outra, um pouco mais tarde.

A sintaxe do backend não viaja

Anote a versão do NetworkManager-l2tp e a versão do backend IPsec antes de comparar seja o que for. O Libreswan e o strongSwan não partilham sintaxe de propostas nem conjuntos de algoritmos idênticos, pelo que uma cadeia que funciona num é um erro de sintaxe no outro. O backend instalado pode ainda recusar o IKEv1 por política, e nesse caso nenhuma proposta será alguma vez aceite.

O README do projeto documenta essas diferenças entre backends e mantém separados os campos da fase 1 e da fase 2. Leia-o como documentação da estrutura, não como um convite a ativar todas as cifras históricas e um grupo fraco, porque uma ligação que só tem sucesso assim não é a ligação que lhe pediram para construir.

Acorde o conjunto e depois verifique as etapas

Pergunte ao operador do gateway quais os conjuntos IKE e ESP suportados e aprovados, e depois compare essa resposta com as propostas efetivas do cliente em vez de com o seu ficheiro de configuração. Se a divergência for especificamente sobre PFS da fase 2, decida um grupo suportado ou uma política sem PFS aprovada explicitamente. Não inferir a política a partir do nome do erro.

Quando a única sobreposição exige criptografia que a organização já não aceita, a decisão pertence ao gateway ou a uma migração de protocolo. Alargar a cadeia do cliente até algo negociar é uma forma de entregar uma fraqueza conhecida com um visto verde ao lado.

Depois de corrigir a divergência real, confirme o estabelecimento do IPsec antes de investigar o L2TP e o PPP, e trate qualquer rejeição de autenticação posterior como pertencente à etapa seguinte. Depois ensaie a renovação no processo de teste aprovado, porque estabelecer a primeira associação não diz nada sobre o resto da sua vida.