NO_PROPOSAL_CHOSEN no L2TP? Examine primeiro o gateway

O pedido de nome de utilizador nunca aparece e o cliente comunica NO_PROPOSAL_CHOSEN. Nesse momento, as credenciais e a chave pré-partilhada são irrelevantes, porque os dois extremos não acordaram como proteger a fase 1. A maioria das pessoas reage colando uma cadeia de cifra que encontrou online. Uma análise do gateway responde à mesma pergunta com provas e demora mais ou menos o mesmo tempo.

O que a mensagem exclui

A rejeição ocorre em modo principal, antes de qualquer troca L2TP ou PPP, pelo que nem o túnel nem a base de dados de utilizadores foram consultados. A fase 1 negoceia cifragem, integridade e um grupo Diffie-Hellman. A fase 2 negoceia a proposta ESP para os dados. Uma falha da fase 1 não se corrige alterando uma definição PFS da fase 2, e uma associação IKE concluída não prova que a proposta ESP seja adequada.

Registe o backend antes de editar a sintaxe: ipsec --version. libreswan e strongSwan aceitam grafias diferentes da proposta para os mesmos algoritmos.

Depois leia a rejeição em contexto com journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Examine o gateway para conhecer o seu conjunto de transformações

Um scanner pergunta diretamente ao gateway que transformações irá negociar. Pare primeiro o serviço IPsec local para que a sonda não compita com o seu próprio cliente e depois leia as linhas SA. Trate a lista como prova sobre o outro extremo, não como um menu para ativar tudo de uma vez.

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

Os equipamentos mais antigos oferecem frequentemente 3DES, SHA1 e MODP1024, porque eram os valores predefinidos quando o produto foi enviado e ninguém os reviu. Guarde a saída em bruto da análise, pois é o único registo do que o outro extremo ofereceu nesse dia. Se for a sobreposição mais forte disponível, a escalagem correta é para o proprietário do gateway, não para uma configuração de cliente que volta a ativar criptografia fraca para todos.

Faça corresponder a sobreposição sem desativar a segurança

Introduza apenas as transformações que aparecem tanto na análise como na sua política. O exemplo abaixo reflete um gateway que oferece 3DES, SHA1 e MODP1024 na fase 1. Note a ressalva sobre o backend: o libreswan 4.x não compila o grupo modp1024, pelo que isto se aplica ao strongSwan ou a uma compilação de libreswan com suporte DH2. Verifique a versão antes de concluir que o cliente está avariado.

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

Um ponto de exclamação no fim fixa uma única proposta. Use-o para isolar um teste e depois remova-o, para que o gateway possa negociar algo mais forte mais tarde.

Verifique o daemon e a porta antes de tentar novamente

O NetworkManager-l2tp inicia a sua própria instância de xl2tpd. Se o serviço do sistema já detiver a porta UDP 1701, o cliente recorre a uma porta de origem efémera, o que o RFC 3193 permite e alguns servidores descartam em silêncio. Verifique o proprietário do socket antes da tentativa seguinte.

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

Os segredos gerados obsoletos são outra causa silenciosa. Os ficheiros em /etc/ipsec.d/ com o nome de uma ligação antiga podem sobreviver ao perfil que os criou, por isso remova os que nada referencia e tente novamente.

Por fim, verifique de onde veio o conselho. Um ipsec.conf escrito para IKEv1 XAuth descreve outro tipo de VPN, e a sua proposta não é a única linha que estará errada num perfil L2TP. Registe o conjunto de transformações que introduziu ao lado do perfil, para que a próxima pessoa não repita a sonda.