L2TP: 15-ös végzetes jelzés, NO_PROPOSAL_CHOSEN és hiányzó modp1024

A kapcsolat megakad, a kliens kilép, és a képernyő utolsó sora death_handler: Fatal signal 15 received. Az a sor megszakadásról számol be, nem okról. Egy sorral feljebb az IPsec-naplóban szinte mindig ott van NO_PROPOSAL_CHOSEN, és a pár a csere 2. fázisára mutat, ahol a felek összevetik a titkosítási és hash-választásaikat, és megállnak, ha nincs közös. Ebben a szakaszban a hitelesítő adatok még nem lettek elküldve, ezért a jelszó újragépelése nem változtathat az eredményen.

Linux-kliensen általában két dolog üríti ki ezt a metszetet. Előfordulhat, hogy a helyi démon már nem valósítja meg a profil által kért Diffie-Hellman-csoportot, vagy a profil az 1. fázis javaslatát hordozza a 2. fázis mezőjében. Mindkettő nyomot hagy a naplóban, és egyik sem fiókprobléma.

Mit mond valójában a két üzenet

Az IKE fordulókban tárgyal. Az 1. fázis védett csatornát épít, és saját algoritmusokat választ; a 2. fázis, a gyermek SA, külön készlet alatt viszi a forgalmat. A NO_PROPOSAL_CHOSEN az az értesítés, amelyet a válaszadó akkor küld vissza, amikor a felkínált kombinációk egyike sem elfogadható, és [ HASH N(NO_PROP) ] formában jelenik meg egy INFORMATIONAL-cserén belül.

A 15-ös jelzés más esemény: valami szólt a helyi folyamatnak, hogy álljon le, és a kezelő ezt naplózta. Amikor a két sor együtt jelenik meg, a sorrend oksági, előbb az elutasítás, aztán a leállítás.

Olvassa el a tárgyalást, mielőtt a hitelesítő adatokhoz nyúl

Emelje meg a naplózási szintet ott, ahová a démon ír, majd csatlakozzon újra a kimenetet figyelve. NetworkManager-gazdagépen az L2TP beépülő modul továbbadja ezt a szintet a háttérrendszernek, és az üzenetek a disztribúciótól függően a journalba vagy a klasszikus syslog-fájlba kerülnek. Bármelyikük megmutatja a cserét: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' vagy tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

A pluto nevét tartalmazó sor a libreswanból, a charon a strongSwanból származik, és mindkettő ugyanazt az állapotot írja le más szavakkal. Az a forma érdemes a keresésre, amely megnevezi a hiányzó csoportot, például algorithm 'modp1024' is not supported, mert a homályos hibát konkrétumra fordítja.

Hová tűnt a modp1024

A Diffie-Hellman 2. csoport elég gyenge ahhoz, hogy több disztribúció 3.30-tól ne fordítsa bele a libreswanba. Ekkor egy évekkel korábban írt, vagy egy csak aes128-sha1-modp1024-et felsoroló átjáró-útmutatóból átvett profil olyat kér a helyi démontól, amit az egyáltalán nem tud végrehajtani. Az újabb NetworkManager-l2tp buildek valószínűbbé teszik ezt az eredményt: az 1.2.16-tól Windows 10 és iOS stílusú javaslatokkal helyettesítik a készletet, és a libreswan észlelésekor elhagyják a modp1024-et. A túloldal gyakran ártatlan, és továbbra is pontosan azt a csoportot kínálja, amelyet beállított.

Ez az aszimmetria teszi véletlenszerűvé a hibát. Egy régebbi kliens csatlakozik, ugyanaz a profil egy frissített laptopon nem, és a kiszolgáló konfigurációja soha nem mozdult. A kárt a verziók elcsúszása okozza.

Két javítás, eltérő hatókörrel

Az olcsó javítás az, hogy hagyja abba az algoritmusok beégetését. Ürítse ki mindkét javaslatmezőt a szerkesztőben, és hagyja, hogy a beépülő modul olyan készletet válasszon, amelyet a távoli fél elfogad; ha az átjáró támogatja a modern csoportokat, a tárgyalás további munka nélkül lezárul.

A második javítás a strongSwan telepítésével tartja elérhetővé a régi átjárót, amelynek csomagjai a legtöbb disztribúción még mindig megvalósítják a 2. csoportot. Ez démoncsere, tehát ára van: ellenőrizze, hogy a gazdagép más alagútjai függnek-e a libreswan konfigurációjától, mielőtt eltávolítja, és számítson SELinux-elutasításokra a NetworkManager és a strongSwan beépülő modul között Fedorán. Ezek az elutasítások az auditnaplóban jelennek meg, nem az IKE-nyomban, ezért egy alagút sikeres telepítés után azonnal töröttnek tűnhet. A működő sorrend: először dnf install strongswan, aztán rpm -e libreswan.

Illeszkedő javaslatsorok és a körülöttük lévő csapdák

Amikor a mezőket kézzel kell kitölteni, az 1. és a 2. fázis eltérő értékeket vesz fel. Egy Meraki stílusú túloldallal működőnek ismert pár az 1. fázisban aes128-sha1-modp1024-et kínál, mögötte 3des-sha1-modp1024-gyel, mindkettőt felkiáltójel zárja, amely szigorúvá teszi a készletet, így csak azok a javaslatok kerülnek elküldésre.

A 2. fázis aztán aes128-sha1 és 3des-sha1 értékre szűkül, ugyanazzal a szigorú jelöléssel és minden Diffie-Hellman-utótag nélkül. A -modp1024-et hordozó 2. fázisú sor egy 1. fázisú érték a rossz mezőben, és a válaszadó minden újrapróbálkozásnál elutasítja. Másolja azt a sort egy második profilba, és a második profil ugyanúgy elbukik, és így egy elírásból az egész flottát érintő incidens lesz.

Más hibák ugyanazt a felugró ablakot viselik anélkül, hogy javaslat-eltérések lennének. KDE-n az L2TP-típus a beépülő modul telepítése mellett is szerepelhet, miközben minden kapcsolat azonnal meghal, mert a kapcsolatszerkesztő és a futásidejű segédprogramok külön csomagként érkeznek. Képernyő nélküli gazdagépek újrahasznosíthatnak egy profilt egy működő asztali gépről: másolja ki a /etc/NetworkManager/system-connections/ helyről, állítsa a módot 600-ra, majd futtassa a nmcli con reload parancsot. Hozza fel a nmcli con up id work-l2tp paranccsal, mivel a csupasz forma UUID-t kér, és távolítson el minden elavult ifname bejegyzést, különben a kezelő Could not find source connection választ ad, miközben minden más helyes.

Az előre megosztott kulcs tárolható egyszerű szövegként vagy 0s és utána base64 formában; mindkét forma működik, de az értéknek bájtra egyeznie kell az átjáróval, beleértve a vele együtt átmásolt záró szóközöket.