NO_PROPOSAL_CHOSEN by L2TP? Skandeer eers die gateway

Die gebruikersnaamvraag verskyn nooit nie, en die kliënt rapporteer NO_PROPOSAL_CHOSEN. Geloofsbriewe en die vooraf gedeelde sleutel is op daardie punt irrelevant, want die twee kante het nie ooreengekom oor hoe om fase 1 te beskerm nie. Die meeste mense reageer deur ’n syferstring te plak wat hulle aanlyn gevind het. ’n Skandering van die gateway beantwoord dieselfde vraag met bewyse en neem omtrent net so lank.

Wat die boodskap uitsluit

Die verwerping gebeur in hoofmodus, voor enige L2TP- of PPP-uitruiling, so die tonnel en die gebruikersdatabasis is nog nie geraadpleeg nie. Fase 1 onderhandel oor enkripsie, integriteit en ’n Diffie-Hellman-groep. Fase 2 onderhandel oor die ESP-voorstel vir data. ’n Fout in fase 1 kan nie reggestel word deur ’n fase-2-PFS-instelling te verander nie, en ’n voltooide IKE-assosiasie bewys nie dat die ESP-voorstel pas nie.

Teken die backend aan voordat jy die sintaks wysig: ipsec --version. libreswan en strongSwan aanvaar verskillende voorstelspellings vir dieselfde algoritmes.

Lees dan die verwerping in konteks met journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Skandeer die gateway vir sy transformasieversameling

’n Skandeerder vra die gateway direk watter transformasies dit sal onderhandel. Stop eers die plaaslike IPsec-diens sodat die ondersoek nie met jou eie kliënt meeding nie, en lees dan die SA-lyne. Behandel die lys as bewyse oor die eweknie, nie as ’n spyskaart om alles tegelyk te aktiveer nie.

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

Ouer toestelle bied dikwels 3DES, SHA1 en MODP1024 aan, want dit was die verstekke toe die produk verskeep is en niemand het dit herbesoek nie. Hou die rou skandeeruitset, want dit is die enigste rekord van wat die eweknie daardie dag aangebied het. As dit die sterkste oorvleueling is wat beskikbaar is, is die regte eskalasie na die gateway-eienaar, nie na ’n kliëntkonfigurasie wat swak kriptografie vir almal weer aanskakel nie.

Pas die oorvleueling aan sonder om veiligheid uit te skakel

Voer net die transformasies in wat in beide die skandering en jou beleid voorkom. Die voorbeeld hieronder weerspieël ’n gateway wat 3DES, SHA1 en MODP1024 in fase 1 aanbied. Let op die backend-voorbehoud: libreswan 4.x kompileer nie die modp1024-groep nie, so dit geld vir strongSwan of ’n libreswan-bou met DH2-ondersteuning. Verifieer die weergawe voordat jy tot die gevolgtrekking kom dat die kliënt stukkend is.

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

’n Uitroepteken aan die einde pen ’n enkele voorstel vas. Gebruik dit om ’n toets te isoleer, en verwyder dit dan sodat die gateway later iets sterker kan onderhandel.

Kontroleer die daemon en die poort voordat jy weer probeer

NetworkManager-l2tp begin sy eie xl2tpd-instansie. As die stelseldiens reeds UDP 1701 besit, val die kliënt terug op ’n efemere bronpoort, wat RFC 3193 toelaat en sommige bedieners stilweg laat val. Kontroleer die sokkie-eienaar voor die volgende poging.

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

Verval generatiewes geheime is nog ’n stil oorsaak. Lêers onder /etc/ipsec.d/ wat vir ’n ou verbinding benoem is, kan die profiel wat hulle geskep het, oorleef, so verwyder dié waarna niks verwys nie en probeer weer.

Kontroleer laastens waar die raad vandaan kom. ’n ipsec.conf wat vir IKEv1 XAuth geskryf is, beskryf ’n ander VPN-tipe, en sy voorstel is nie die enigste reël wat in ’n L2TP-profiel verkeerd sal wees nie. Teken die transformasieversameling wat jy ingevoer het, langs die profiel aan, sodat die volgende persoon nie die ondersoek herhaal nie.