NO_PROPOSAL_CHOSEN az L2TP-nél? Először szkennelje az átjárót

A felhasználónév-kérés soha nem jelenik meg, és a kliens NO_PROPOSAL_CHOSEN hibát jelent. Ezen a ponton a hitelesítő adatok és az előre megosztott kulcs irrelevánsak, mert a két fél nem egyezett meg abban, hogyan védjék az 1. fázist. A legtöbb ember úgy reagál, hogy beilleszt egy online talált titkosítási karakterláncot. Az átjáró szkennelése ugyanarra a kérdésre bizonyítékokkal válaszol, és nagyjából ugyanannyi ideig tart.

Mit zár ki az üzenet

Az elutasítás fő módban, bármilyen L2TP- vagy PPP-csere előtt történik, így sem az alagutat, sem a felhasználói adatbázist nem kérdezték meg. Az 1. fázis a titkosításról, az integritásról és egy Diffie-Hellman-csoportról tárgyal. A 2. fázis az adatok ESP-javaslatáról tárgyal. Az 1. fázis hibáját nem lehet a 2. fázis PFS-beállításának módosításával kijavítani, és egy befejezett IKE-társítás nem bizonyítja, hogy az ESP-javaslat megfelelő.

Jegyezze fel a backendet, mielőtt szerkeszti a szintaxist: ipsec --version. A libreswan és a strongSwan ugyanazokhoz az algoritmusokhoz eltérő írásmódokat fogad el a javaslatból.

Ezután olvassa el az elutasítást a kontextusban ezzel: journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Szkennelje az átjárót a transzformkészletéért

A szkenner közvetlenül megkérdezi az átjárót, milyen transzformációkról fog tárgyalni. Először állítsa le a helyi IPsec-szolgáltatást, hogy a vizsgálat ne versenyezzen a saját klienseppel, majd olvassa el az SA-sorokat. Kezelje a listát a partnerre vonatkozó bizonyítékként, nem pedig menüként, amelyet teljes egészében be kell kapcsolni.

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

A régebbi eszközök gyakran kínálnak 3DES-t, SHA1-et és MODP1024-et, mert ezek voltak az alapértelmezések a termék szállításakor, és senki nem vizsgálta felül őket. Őrizze meg a szkennelés nyers kimenetét, mert ez az egyetlen feljegyzés arról, mit kínált a partner azon a napon. Ha ez a legerősebb elérhető átfedés, a helyes eszkaláció az átjáró tulajdonosához szól, nem egy olyan klienskonfigurációhoz, amely mindenki számára újra engedélyezi a gyenge kriptográfiát.

Párosítsa az átfedést a biztonság kikapcsolása nélkül

Csak azokat a transzformációkat adja meg, amelyek a szkennelésben és a házirendjében is szerepelnek. Az alábbi példa egy olyan átjárót tükröz, amely az 1. fázisban 3DES-t, SHA1-et és MODP1024-et kínál. Vegye figyelembe a backendre vonatkozó fenntartást: a libreswan 4.x nem fordítja le a modp1024 csoportot, tehát ez a strongSwanra vagy a DH2-támogatással rendelkező libreswan-buildre vonatkozik. Ellenőrizze a verziót, mielőtt arra jut, hogy a kliens hibás.

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

A végén álló felkiáltójel egyetlen javaslatot rögzít. Használja teszt elkülönítésére, majd távolítsa el, hogy az átjáró később valami erősebbről tárgyalhasson.

Ellenőrizze a démont és a portot az újabb próbálkozás előtt

A NetworkManager-l2tp saját xl2tpd-példányt indít. Ha a rendszerszolgáltatás már birtokolja az UDP 1701-et, a kliens egy efemer forrásportra esik vissza, amit az RFC 3193 engedélyez, és egyes szerverek csendben eldobnak. Ellenőrizze a socket tulajdonosát a következő kísérlet előtt.

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

Az elavult generált titkok egy másik csendes ok. A következő helyen lévő fájlok /etc/ipsec.d/ egy régi kapcsolatról elnevezve túlélhetik a létrehozó profilt, ezért távolítsa el azokat, amelyekre semmi nem hivatkozik, és próbálja újra.

Végül ellenőrizze, honnan származik a tanács. Egy ipsec.conf, amelyet IKEv1 XAuth-hoz írtak, más VPN-típust ír le, és a javaslata nem az egyetlen sor, amely hibás lesz egy L2TP-profilban. Jegyezze fel a megadott transzformkészletet a profil mellé, hogy a következő ember ne ismételje meg a vizsgálatot.