NO_PROPOSAL_CHOSEN en L2TP? Examine primeiro a pasarela

O aviso de nome de usuario nunca aparece e o cliente informa de NO_PROPOSAL_CHOSEN. Nese momento as credenciais e a clave precompartida son irrelevantes, porque os dous extremos non acordaron como protexer a fase 1. A maioría da xente responde pegando unha cadea de cifrado que atopou en liña. Unha análise da pasarela responde á mesma pregunta con probas e leva máis ou menos o mesmo tempo.

Que descarta a mensaxe

O rexeitamento ocorre en modo principal, antes de calquera intercambio L2TP ou PPP, así que nin o túnel nin a base de datos de usuarios se consultaron. A fase 1 negocia o cifrado, a integridade e un grupo Diffie-Hellman. A fase 2 negocia a proposta ESP para os datos. Un fallo da fase 1 non se arranxa cambiando un axuste PFS da fase 2, e unha asociación IKE completada non demostra que a proposta ESP encaixe.

Anote o backend antes de editar a sintaxe: ipsec --version. libreswan e strongSwan aceptan grafías distintas da proposta para os mesmos algoritmos.

Despois lea o rexeitamento en contexto con journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Examine a pasarela para coñecer o seu conxunto de transformacións

Un escáner pregunta directamente á pasarela que transformacións vai negociar. Deteña primeiro o servizo IPsec local para que a sonda non compita co seu propio cliente e despois lea as liñas SA. Trate a lista como unha proba sobre o outro extremo, non como un menú para activalo todo de vez.

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

Os equipos máis antigos adoitan ofrecer 3DES, SHA1 e MODP1024, porque eran os valores predeterminados cando se enviou o produto e ninguén os revisou. Garde a saída sen procesar da análise, porque é o único rexistro do que o outro extremo ofreceu ese día. Se esa é a superposición máis forte dispoñible, a escalada correcta é cara ao propietario da pasarela, non cara a unha configuración de cliente que volve habilitar criptografía feble para todos.

Axuste a superposición sen desactivar a seguridade

Introduza só as transformacións que aparecen tanto na análise como na súa política. O exemplo seguinte reflicte unha pasarela que ofrece 3DES, SHA1 e MODP1024 na fase 1. Fíxese na advertencia sobre o backend: libreswan 4.x non compila o grupo modp1024, así que isto se aplica a strongSwan ou a unha compilación de libreswan con soporte de DH2. Verifique a versión antes de concluír que o cliente está roto.

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

Un signo de exclamación final fixa unha soa proposta. Úseo para illar unha proba e quíteo despois para que a pasarela poida negociar algo máis forte máis adiante.

Comprobe o daemon e o porto antes de reintentar

NetworkManager-l2tp inicia a súa propia instancia de xl2tpd. Se o servizo do sistema xa posúe o porto UDP 1701, o cliente recorre a un porto de orixe efémero, algo que o RFC 3193 permite e que algúns servidores descartan en silencio. Comprobe o propietario do socket antes do seguinte intento.

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

Os segredos xerados obsoletos son outra causa silenciosa. Os ficheiros que hai baixo /etc/ipsec.d/ co nome dunha conexión antiga poden sobrevivir ao perfil que os creou, así que elimine os que nada referencia e volva intentalo.

Por último, comprobe de onde vén o consello. Un ipsec.conf escrito para IKEv1 XAuth describe outro tipo de VPN, e a súa proposta non é a única liña que estará mal nun perfil L2TP. Anote o conxunto de transformacións que introduciu xunto ao perfil, para que a seguinte persoa non repita a sonda.