Az L2TP/IPsec nem működik: válasszuk szét az IPsec, az alagút-hitelesítés és a PPP-bejelentkezés szintjét

Egyetlen L2TP/IPsec kapcsolaton belül három dolog hitelesít, és közülük csak egy érinti a betárcsázó személyt. Az IPsec az alagút végpontjait bizonyítja, az L2TP vezérlőkapcsolat saját titkával újra bizonyíthatja a partnereket, majd a PPP bizonyítja a felhasználói fiókot a munkameneten belül. Bármelyik szakasz hibája általános bejelentkezési hibának látszik az ügyfél párbeszédpanelén, a kiszolgáló naplójában viszont teljesen másképp néz ki. Haladjon végig a szakaszokon sorrendben, és álljon meg az elsőnél, amely elbukik, mert a kipróbálatlan szakasz alatti minden szakasz szintén kipróbálatlan.

Három hitelesítési szakasz, három különböző identitás

Az IPsec bizonyítja, ki birtokolja a végpontokat, előre megosztott kulccsal vagy tanúsítvánnyal. Ez az identitás gépekhez vagy átjárókhoz tartozik, soha nem a billentyűzetnél ülő emberhez. Amikor a partnerek ebben a szakaszban nem tudnak megegyezni, egyáltalán nem cserélődik L2TP csomag.

Az L2TP vezérlőkapcsolat hozzáadhat egy második, külön kihívás-válasz cserét, amelyet egy közös titok vezérel, amellyel mindkét végnek rendelkeznie kell.

Az RFC 2661 ezt a vezérlőkapcsolat-hitelesítést választhatóvá teszi, ami megmagyarázza, miért okoz ugyanaz a hiba eltérő tüneteket két kiszolgálón. Az a telepítés, amely soha nem állított be alagút-titkot, teljesen kihagyja a szakaszt; amelyik csak az egyik oldalon állította be, az még a PPP felajánlása előtt elbukik. Ezután a PPP PAP, CHAP vagy MSCHAPv2 használatával hitelesíti a felhasználót, és átadja a nevet egy fióktárnak, amely lehet helyi, a chap-secrets fájlban vagy RADIUS-on. Egy rossz jelszó ezen a ponton még mindig működő alagutat és sikertelen munkamenetet hagy.

Olvassuk el a megállási pontot, mielőtt bármit szerkesztenénk

Kezdjük a ipsec --version paranccsal, hogy tudjuk, a státuszkimenet a strongSwanhoz vagy a Libreswanhoz tartozik. Ezután a kiszolgáló naplóját olvassuk, nem az ügyfél párbeszédpanelét, mert a kiszolgáló rögzíti, melyik szakasz utasított el.

Egyetlen sor általában eldönti a hibajegyet: az IKE- vagy javaslati panasz az első szakasz, a vezérlőkapcsolat-üzenet a második szakasz, a PPP-módszer vagy fiók elutasítása pedig a harmadik szakasz. Másoljuk be azt a sort a hibajegybe az időbélyeggel együtt. Az ügyfél oldaláról találgatni elpazarolja az egyetlen bizonyítékot, amellyel már rendelkezünk.

Tartsuk a kulcsanyagot és a jelszavakat azon a beillesztésen kívül; a szakasz neve irányítja a munkát, és egy kiszivárgott előre megosztott kulcs rosszabb következményekkel nyitja újra a hibajegyet.

Első szakasz: van az IPsecnek társítása?

Futtassuk a ipsec statusall parancsot strongSwanon vagy a ipsec whack --status parancsot Libreswanon, és keressünk létrejött gyermektársítást nem nulla számlálókkal. A ip xfrm state mindkettőn a kernel nézetét mutatja. Egy telepített SA-pár növekvő számlálókkal azt jelenti, hogy az első szakasz kész, és továbbléphetünk.

A társítás teljes hiánya a partner címére, a javaslatkészletre vagy az előre megosztott kulcsra mutat, és néha olyan eszközre, amely átírja az UDP 500-at, miközben eldobja az UDP 4500-at. Az a társítás, amely létrejön, majd néhány másodperc után eltűnik, általában élettartam-eltérés a két vég között, nem hitelesítőadat-probléma. Ellenőrizzük, hogy mindkét oldal ugyanazokat a titkosítási és hash-javaslatokat listázza-e, mielőtt bármit újragépelnénk. Ha nem, egyetlen kulcs sem fog soha működni.

Álljunk meg, amíg a társítás hiányzik. A PPP-beállítások szerkesztése ezen a ponton semmit nem változtat, és elrejti a valódi hibát a következő ember elől.

Második szakasz: hitelesített-e az L2TP vezérlőkapcsolat?

Amint az IPsec fut, figyeljük az L2TP démont egy létrejött állapotot elérő vezérlőkapcsolatért, mert a PPP előtte nem kezdődhet el. A vezérlőkapcsolat elutasítása azt jelenti, hogy az alagút titka eltér a végek között, vagy az egyik vég olyan titkot követel, amelyet a másik soha nem küld. Az ügyfelek gyakran egyetlen shared secret feliratú mezőt kínálnak, és az rendszerint az IPsec-hez tartozik, nem az L2TP-hez. Kitöltése nem állítja be az alagút titkát, és törlése nem tiltja le.

Ha egyik oldal sem állított be alagút-titkot, hagyjuk ki ezt a szakaszt, és a vezérlőkapcsolat hibáját inkább elérhetőségi problémaként kezeljük. Erősítsük meg, hogy az UDP 1701 eléri a démont, és mindkét vég ugyanabban a beágyazásban egyezik meg. Egy ilyen, a két feltétel egyikére írt tűzfal-szabály gyakori oka a félig megnyíló kapcsolatnak.

Csak az a munkamenet haladta meg valóban az alagút szakaszt, amely elkezdi a PPP-tárgyalást.

Harmadik szakasz: elutasítja a PPP a fiókot?

A PPP hibája kívülről másképp néz ki: az alagút létrejött, a munkamenet elindul, és a démon hitelesítési módszer hibáját vagy fiók elutasítását naplózza. Olvassuk el az üzenetben megnevezett módszert. A PAP és a CHAP különböző okokból bukik el, és az a kiszolgáló, amely az egyiket elutasítja, el fogja utasítani azt az ügyfelet, amely csak azt kínálja.

Linux kiszolgálón vizsgáljuk meg a démon által a PPP-nek átadott beállításfájlt, jellemzően a /etc/ppp/options.xl2tpd fájlt, és erősítsük meg, mely módszerek elfogadottak, és hol oldódnak fel a fiókok. Egy név, amely létezik a RADIUS-ban, de nem a helyi titokfájlban, tisztán elbukik, és rossz jelszónak látszik. Ezután ellenőrizzük, hogy az ügyfél olyan módszert kínál-e, amelyet a kiszolgáló elfogad, nem pedig egy erősebbet, amelynek tárgyalását a kiszolgáló elutasítja. Az előre megosztott kulcs megváltoztatása e szakasz javítására egy délutánt pazarol el, és semmit nem változtat.

Amikor a munkamenet végre feláll, a címkiosztás, a DNS és az útvonalak még ellenőrizetlenek, és mindegyik csendben, a maga módján bukik el. Tartsuk külön a három réteget a jegyzeteinkben: egy helyes kulcs hibás fiókkal mindig elbukik, és egy réteg javítása soha nem javítja a másikat.