Az átjáró tanúsítványa rendben van: miért vall kudarcot mégis az IKEv2 PEAP bejelentkezés

A VPN-átjárója tanúsítványa érvényes, a lánc validálódik, és az IKEv2-ügyfél mégis elutasítja a bejelentkezést egy tanúsítvány érvényességi időtartamáról szóló üzenettel. Az első ösztön az átjáró tanúsítványának újrakibocsátása vagy az EAP-módszer váltása, és mindkettő általában hibás. A bejelentkezési kísérlet két külön kiszolgáló-identitást hordoz: az IKE által használt átjáró-tanúsítványt és azt a tanúsítványt, amelyet a PEAP-et lezáró fél bemutat. Az egyik rendben van, a másik pedig az oka annak, hogy az ügyfél megállt.

Két identitás, egy bejelentkezési kísérlet

A VPN-profilban lévő tanúsítvány az IKE-csere része: azt bizonyítja, hogy az átjáró az a partner, akit a profil megnevez, a beállított IKE-házirend szerint. Az itt meghiúsuló tanúsítvány egy másik beszélgetéshez tartozik, ahhoz a TLS-munkamenethez, amelyet a PEAP a felhasználót hitelesítő féllel nyit, ami gyakran egy RADIUS-kiszolgáló, például NPS, és nem maga az átjáró. Egy harmadik ellenőrzés, a felhasználói hitelesítő adat, ezen a munkameneten belül történik. Egy érvényes jelszó nem tud megjavítani egy lejárt kiszolgálótanúsítványt, és egy érvényes átjáró-tanúsítvány nem tud jótállni a PEAP-végpontért.

Ez a rétegződés magyarázza, miért bukkan fel tanúsítványhiba olyan helyen, ahol az egyetlen beállított tanúsítvány az átjáróé volt. Azt is magyarázza, miért nem változtat semmit az a tanúsítvány újrakibocsátása.

Olvassa a naplósort a fázishoz

Keresse meg az üzenetet, amely megnevezi az okot és a dátumokat. Az érvényességi időtartamra vonatkozó panasz egy alanyhiba mellett azt jelenti, hogy a kiszolgáló elutasította a neki adott tanúsítványt, nem pedig azt, hogy a felhasználó elutasította a bejelentkezést. Ezután keresse meg a fázist: a strongSwan charon-naplója IKE_SA .* established mutat, mielőtt az EAP-csere elkezdődik, tehát az e sor utáni tanúsítványhiba az EAP-identitáshoz tartozik, míg az előtte lévő hiba az átjáróra mutat. A Windows-ügyfél kapcsolódási paneljének fázisszövege ugyanezt mondja.

Ellenőrizze az ügyfél óráját, mielőtt bármely tanúsítványhoz hozzányúlna. Az órákban eltérő eszköz ugyanazt az érvényességi hibát adja, mint egy valóban lejárt tanúsítvány. Az óra beállítása öt másodperces javítás, és egy olyan tanúsítvány cseréje, amely soha nem volt a probléma, kiesés.

Állapítsa meg, melyik végpont zárja le a PEAP-et

Átjáró és RADIUS együttes felépítésében az átjáró továbbítja az EAP-t, és nem zárja le azt. A strongSwan eap-radius bővítménye a RADIUS-kiszolgálónak adja át a cserét, amely a PEAP TLS-munkamenet és annak tanúsítványának birtokosa. Korreláljon egy sikertelen kísérletet mindkét naplóban, és erősítse meg, melyik folyamat választott ténylegesen tanúsítványt ehhez a munkamenethez.

Az NPS esetében a tanúsítványnak a helyi számítógép tárolójában kell lennie, viselnie kell a kiszolgáló-hitelesítés célját, egyeznie kell az ügyfelek által várt névvel, és olvashatónak kell lennie a szolgáltatásfiók számára. A Microsoft NPS-hez szóló tanúsítványkövetelményei felsorolják ezeket a feltételeket. Más EAP-kiszolgálóknak saját kiválasztási szabályaik vannak, ezért ne másolja az NPS sajátosságait egy FreeRADIUS-telepítésbe, és fordítva. A szabály, amely mindkét esetben érvényes, az, hogy a PEAP-et lezáró végpont birtokolja a módosítani kívánt tanúsítványt.

Ott cserélje ki a tanúsítványt, ahol az EAP lezárul

Újítsa meg vagy cserélje ki a tanúsítványt a PEAP-et lezáró végponton a támogatott eljárással, megtartva a kiszolgáló-hitelesítés célját és a várt nevet. Telepítse a teljes láncot oda, ahol a szolgáltatás keresi, és adjon a szolgáltatásnak hozzáférést a titkos kulcshoz. Indítsa újra vagy kösse újra a szolgáltatást, mert sok szolgáltatás a memóriában tartja a régi tanúsítványt, és továbbra is azt mutatja be. Egy gépre másolt fájl semmit sem bizonyít arról, melyik tanúsítványt mutatja be a szolgáltatás valójában.

Erősítse meg a változást úgy, hogy a következő kísérletet a szolgáltatás saját naplójával korrelálja, vagy megvizsgálja a munkamenet által bemutatott tanúsítványt. Ha az a napló még a régi ujjlenyomatot mutatja, az újraindítás nem fogott.

Ne feltételezze, hogy egy könyvtár legújabb fájlja az, amelyet használnak. A helyes névvel és hibás engedélyekkel rendelkező másolat semmit sem változtat. A változást a bemutatott identitás alapján ítélje meg, nem egy fájl időbélyege alapján.

Mit ne tegyen

Ne kapcsolja ki a PEAP-validálást, és ne kényszerítsen gyengébb belső módszert a hiba megkerüléséhez. Ez megváltoztatja a házirendet, és eltávolítja azt a kiszolgáló-hitelesítési tulajdonságot, amely elcsípte a lejárt tanúsítványt. Egy működő ellenőrzést cserélne egy működő kapcsolatra, és a következő lejárt tanúsítvány minden bejelentés nélkül érkezne.

Ne tekintse egy másik operációs rendszer sikeres kapcsolatát bizonyítéknak arra, hogy a tanúsítvány elfogadható. Az az ügyfél más EAP-módszert, más megbízhatósági tárolót vagy egyáltalán semmilyen kiszolgáló-validálást használhat, ezért a sikere semmit sem mond az itt meghiúsult ellenőrzésről. Tartson fenn egy szándékos negatív tesztet, például egy rossz nevű tanúsítványt vagy egy nem megbízható láncot, amely a várakozásnak megfelelően meghiúsul. Ha ez a teszt most átmegy, akkor eltávolított egy ellenőrzést, nem pedig megjavított egy tanúsítványt. Jegyezze fel, melyik identitás hiúsult meg, hogy a következő ember ne kezdje újra az átjáró tanúsítványával.