Elrontotta az Ubuntu-frissítés az L2TP/IPsecet? Hasonlítsa össze az IKEv1 javaslatokat

A kapcsolat csütörtökön működött, a frissítés pénteken lefutott, hétfőn pedig az ügyfél a “connecting” állapotban forog, majd feladja. Ugyanaz a laptop, ugyanaz a kiszolgáló, ugyanaz a fiók, ugyanaz az előre megosztott kulcs. A profilban semmit nem szerkesztettek, ezért a nyilvánvaló gyanúsítottak, a jelszó és a tűzfal, az idejét pazarolják.

Ami megváltozott, az azon átalakítások listája, amelyeket a gépe hajlandó kínálni. Az Ubuntun használt két IPsec verem, a strongSwan és a Libreswan, kiszűri azokat az algoritmusokat, amelyeket már nem tart biztonságosnak, az előttük álló NetworkManager-bővítménynek pedig saját listája van, amely más ütemezés szerint mozog. Egy 3DES-re, SHA1-re és 1024 bites Diffie-Hellman-csoportra rögzített kiszolgáló végül semmit sem hallhat meg abból, amit elfogad.

Mit is változtatott meg a frissítés

Az IKEv1 javaslatot két réteg táplálja. A démon egy befordított alapértelmezett javaslatkészletet szállít, az L2TP-bővítmény pedig vagy erre hagyatkozik, vagy saját listát ad. A NetworkManager-l2tp 1.2.16 előtt a bővítmény erre hagyatkozott, így a javaslata az volt, amit a telepített démon ésszerűnek tartott. Az 1.2.16-tól a bővítmény egy dokumentált listát küld, amelyet Windows- és Apple-ügyfelek alapján modelleztek, és ez a lista szélesebb a régi alapértelmezettnél, de már nem tartalmaz minden örökölt kombinációt a sor élén.

Ez a szétválás megmagyaráz egy hibamódot, amelyet az emberek zavarónak találnak: két gép ugyanazon az Ubuntu-kiadáson eltérően viselkedhet, mert az egyiken a disztribúciós csomag van, a másikon egy backport, a démon verziója pedig mindkettőn azonosnak látszik egy hibajelentésben. A bővítmény verzióját ellenőrizze, ne csak a démonét, mielőtt arra jut, hogy a frissítés semmi relevánsat nem változtatott.

Ugyanebben a területben van egy kisebb csapda. A két démon másképp írja az elliptikus görbés Diffie-Hellman-csoportokat, az egyik ecp384-et ír, a másik ecp_384-et. Illessze be a rossz írásmódot az Advanced párbeszédablakba, és a démon értelmezhetetlenként utasítja el a beállítást, ami a naplóban tárgyalási problémaként jelenik meg, nem konfigurációs elírásként.

Olvassa el a hibát, mielőtt bármit módosít

Kezdje azzal, melyik hátteret futtatja, mert a válasz dönti el a szintaxist és a napló helyét is.

ipsec --version
nmcli connection show "Your VPN name" | grep -i ipsec

Aztán olvassa el magát a cserét. A strongSwanon a démon az aktuális kiadáson a journalba, a régebbin a /var/log/syslog fájlba ír, és az érdekes rész a küldött javaslat, nem az utolsó sor. Olyan megfogalmazást keres, hogy nincs megfelelő javaslat, ami algoritmusprobléma; hitelesítési hibát, ami a kulcsra vagy a fiókra mutat; vagy egyszerű időtúllépést, ami az elérhetőségre mutat.

Ezt a három eredményt túl gyakran kezelik egyetlen tünetként. Az üres démonnaplóval járó időtúllépés azt jelenti, hogy a csomagok nem érkeznek meg. A javaslat elutasítása azt jelenti, hogy megérkeztek és elutasították őket. Ha a naplója csendes, emelje a bővítmény hibakeresési szintjét egy próbálkozásra, majd utána csökkentse, mert a részletes kimenet gyorsan megtölti a journalt.

Az 1. fázis és a 2. fázis külön fogadások

Az IKEv1 kétszer tárgyal. A fő mód az IKE biztonsági társítást egy titkosítási algoritmusból, egy integritásalgoritmusból, egy Diffie-Hellman-csoportból és egy hitelesítési módszerből építi fel. A gyors mód ezután felépíti az ESP-társítást, amely az L2TP-t szállítja majd. A kiszolgáló szabadon elfogadhatja az elsőt és elutasíthatja a másodikat, ezért a félig helyes profil később hibázik, mint várná, és másik hibának látszik.

Phase 1: 3des-sha1-modp1024!
Phase 2: 3des-sha1!

A felkiáltójel a strongSwan szintaxisa szigorú bejegyzéshez: csak ezt az egy kombinációt kínáld, semmi mást. Nélküle a bejegyzés egy tartaléklistához csatlakozik, ami jó, ha a partner modern, és ellentétes hatású, ha egyetlen keményen kódolt szabályzattal rendelkező készülék. A fenti párt a forma szemléltetésének tekintse, ne ajánlásnak bármihez, amit ma épít.

Módosítson egy mezőt, majd ismételje meg a tesztet

Egy jelenlegi bővítményen a leggyorsabb első teszt mindkét javaslatmező teljes törlése és az újracsatlakozás, mert a szállított alapértelmezett lista már tartalmazza a szokásos Windows- és Apple-kombinációkat. Egy régebbi bővítményen a törlésük visszaadja az irányítást egy démonnak, amely esetleg eldobta azt az algoritmust, amelyre a kiszolgálója ragaszkodik, és a hiba súlyosabb lesz.

Ha a törlés nem segít, állítsa be a szigorú párt, amelyet a kiszolgálója dokumentál, egyszerre egy fázist. Módosítsa az 1. fázist, csatlakozzon újra, és olvassa el a naplót, mielőtt a 2. fázishoz nyúl. Amikor egy kombináció végre működik, írja le a kiszolgálómodell és a bővítményverzió mellé, mert az alapértelmezések újra elmozdulnak, és ez a feljegyzés az, ami a következő frissítést ötperces ellenőrzéssé alakítja.