L2TP NO_PROPOSAL_CHOSEN: melyik fázis hibázott valójában?

A NO_PROPOSAL_CHOSEN még azelőtt megérkezik, hogy bármelyik PPP-felhasználónevet megvizsgálnák, ami hasznos tény, és egyben az oka annak, hogy az üzenet félrevezet. Azt jelenti, hogy az egyik fél elutasított egy javaslatot; azt nem jelenti, melyik paraméter tért el, és semmit sem mond arról, hogy az elutasítás az IKE-társulás építése közben vagy később, a forgalom védelméről folytatott tárgyalás során történt-e. E két lehetőség mögött két különböző javítás áll, és csak az egyik érinti azt a PFS-jelölőnégyzetet, amelyhez az emberek először nyúlnak.

Egy üzenet, két javaslatkészlet

Az IKEv1 L2TP/IPsec elrendezésben két tárgyalás követi egymást. Az 1. fázis egy titkosítási algoritmusból, egy integritási algoritmusból és egy Diffie-Hellman-csoportból építi fel az IKE biztonsági társulást. A 2. fázis ezután arról tárgyal, hogyan védjük a forgalmat, és a PFS-követelmény ehhez a második beszélgetéshez tartozik.

Mivel a fázisok egymás után következnek, a hiba helye megmondja, melyik listát hasonlítsa össze. Ebben rejlik az üzenet teljes diagnosztikai értéke, és érdemes kinyerni, mielőtt bármely beállításhoz nyúl.

Miért nem javíthatja a PFS-jelölőnégyzet az 1. fázist

A PFS kikapcsolása a 2. fázis egyik tulajdonságát változtatja meg. Ha a felek soha nem egyeztek meg az 1. fázisban, az ESP-beszélgetés egyáltalán nem jön létre, így a jelölőnégyzetnek semmilyen hatása nincs az elutasításra, és éppen ezért ad ugyanazt a hibát más időbélyeggel.

A fordított hiba ugyanolyan gyakori. A sikeres IKE-társulás nem bizonyítja, hogy az ESP-javaslat elfogadható, és egyáltalán nem bizonyítja, hogy a 2. fázis csoportja megegyezik. A létrejött felügyeleti alagutat csak az 1. fázisra vonatkozó bizonyítékként kezelje. Az emberek a zöld sort „az alagút él” jelentéssel olvassák, majd egy órát töltenek a rossz fázissal, mert semmi nem mondta meg nekik, hogy a második tárgyalás nem indult el.

Olvassa el a naplót, mielőtt algoritmusokat választ

Gyűjtse össze az elutasítást közvetlenül megelőző üzeneteket attól a háttérrendszertől, amely valóban kezeli a kapcsolatot, és korrelálja őket ugyanazzal a kísérlettel. E korreláció nélkül egy másik kapcsolat történetét olvassa, és abból von le következtetéseket.

journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall          # strongSwan
ipsec whack --status     # Libreswan

Ezekből a sorokból válaszoljon két kérdésre: létrejött-e az 1. fázisú társulás, és melyik csere hibázott. Ez a két válasz egyetlen attribútumlistára szűkíti a keresést. A környező kontextus nélküli csupasz értesítés erre nem képes, bármennyire csábító is egy fórumtémából származó javaslatot kipróbálni. Egy működő karakterlánc átmásolása egy másik háttérrendszerű gépről általában egy elutasítást egy másikkal helyettesít, kicsit később.

A háttérrendszer szintaxisa nem utazik

Jegyezze fel a NetworkManager-l2tp verzióját és az IPsec-háttérrendszer verzióját, mielőtt bármit összehasonlít. A Libreswan és a strongSwan nem osztozik a javaslatszintaxisban vagy azonos algoritmuskészletekben, ezért egy karakterlánc, amely az egyikben működik, a másikban szintaktikai hiba. A telepített háttérrendszer szabályzat alapján az IKEv1-et is elutasíthatja, és akkor egyetlen javaslatot sem fogadnak el soha.

A projekt README-je dokumentálja ezeket a háttérrendszer-különbségeket, és külön tartja az 1. és a 2. fázis mezőit. Struktúradokumentációként olvassa, ne úgy, mint meghívást minden történelmi titkosítás és egy gyenge csoport engedélyezésére, mert az a kapcsolat, amely csak így jön létre, nem az a kapcsolat, amelyet építenie kellett.

Egyezzen meg a készletben, majd ellenőrizze a szakaszokat

Kérdezze meg az átjáró üzemeltetőjétől, mely IKE- és ESP-készletek támogatottak és engedélyezettek, majd hasonlítsa ezt a választ az ügyfél tényleges javaslataihoz, ne a konfigurációs fájljához. Ha a nézeteltérés kifejezetten a 2. fázis PFS-éről szól, állapodjon meg egy támogatott csoportban vagy egy kifejezetten engedélyezett, PFS nélküli szabályzatban. Ne a hiba nevéből következtessen a szabályzatra.

Amikor az egyetlen átfedés olyan kriptográfiát igényel, amelyet a szervezet már nem fogad el, a döntés az átjáróé vagy egy protokollváltásé. Az ügyfél karakterláncának szélesítése addig, amíg valami megegyezik, módja annak, hogy egy ismert gyengeséget zöld pipával az oldalán szállítsunk.

A valódi eltérés kijavítása után erősítse meg az IPsec létrejöttét, mielőtt az L2TP-t és a PPP-t vizsgálná, és minden későbbi hitelesítési elutasítást a következő szakaszhoz tartozónak tekintsen. Ezután próbálja ki a megújítást az engedélyezett tesztfolyamatban, mert az első társulás létrejötte semmit nem mond az élettartama hátralévő részéről.