NO_PROPOSAL_CHOSEN a L2TP? Primer escanegeu la passarel·la

L’indicatiu d’usuari no apareix mai i el client informa de NO_PROPOSAL_CHOSEN. En aquell moment, les credencials i la clau prèviament compartida són irrellevants, perquè els dos extrems no han acordat com protegir la fase 1. La majoria de la gent respon enganxant una cadena de xifratge que ha trobat en línia. Un escaneig de la passarel·la respon la mateixa pregunta amb proves i triga aproximadament el mateix.

Què descarta el missatge

El rebuig es produeix en mode principal, abans de qualsevol intercanvi L2TP o PPP, així que ni el túnel ni la base de dades d’usuaris s’han consultat. La fase 1 negocia el xifratge, la integritat i un grup Diffie-Hellman. La fase 2 negocia la proposta ESP per a les dades. Una fallada de la fase 1 no es pot arreglar canviant un paràmetre PFS de la fase 2, i una associació IKE completada no demostra que la proposta ESP encaixi.

Anoteu el backend abans d’editar la sintaxi: ipsec --version. libreswan i strongSwan accepten grafies diferents de la proposta per als mateixos algorismes.

Després llegiu el rebuig en context amb journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Escanegeu la passarel·la per conèixer el seu conjunt de transformacions

Un escàner pregunta directament a la passarel·la quines transformacions negociarà. Atureu primer el servei IPsec local perquè la sonda no competeixi amb el vostre client i, tot seguit, llegiu les línies SA. Tracteu la llista com una prova sobre l’altre extrem, no com un menú per activar-ho tot alhora.

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

Els equips més antics sovint ofereixen 3DES, SHA1 i MODP1024, perquè eren els valors per defecte quan es va enviar el producte i ningú no els va revisar. Guardeu la sortida crua de l’escaneig, perquè és l’únic registre del que l’altre extrem va oferir aquell dia. Si aquesta és la superposició més forta disponible, l’escalada correcta és cap al propietari de la passarel·la, no cap a una configuració de client que torna a habilitar criptografia feble per a tothom.

Feu encaixar la superposició sense desactivar la seguretat

Introduïu només les transformacions que apareixen tant a l’escaneig com a la vostra política. L’exemple següent reflecteix una passarel·la que ofereix 3DES, SHA1 i MODP1024 a la fase 1. Fixeu-vos en l’advertiment del backend: libreswan 4.x no compila el grup modp1024, així que això s’aplica a strongSwan o a una compilació de libreswan amb suport de DH2. Verifiqueu la versió abans de concloure que el client està espatllat.

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

Un signe d’exclamació final fixa una sola proposta. Feu-lo servir per aïllar una prova i traieu-lo després perquè la passarel·la pugui negociar alguna cosa més forta més endavant.

Comproveu el dimoni i el port abans de tornar-ho a provar

NetworkManager-l2tp inicia la seva pròpia instància d’xl2tpd. Si el servei del sistema ja té el port UDP 1701, el client recorre a un port d’origen efímer, cosa que el RFC 3193 permet i que alguns servidors descarten en silenci. Comproveu el propietari del sòcol abans del següent intent.

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

Els secrets generats obsolets són una altra causa silenciosa. Els fitxers que hi ha sota /etc/ipsec.d/ amb el nom d’una connexió antiga poden sobreviure al perfil que els va crear, així que elimineu els que ningú no referencia i torneu-ho a provar.

Finalment, comproveu d’on ve el consell. Un ipsec.conf escrit per a IKEv1 XAuth descriu un altre tipus de VPN, i la seva proposta no és l’única línia que estarà malament en un perfil L2TP. Anoteu el conjunt de transformacions que heu introduït al costat del perfil, perquè la propera persona no repeteixi la sonda.