EAP vagy kliens-tanúsítvány? Az IKEv2-hitelesítés eldöntése

Az átjárója tanúsítvánnyal igazolhatja a saját identitását, miközben az Önéét EAP-val igazolja, és ez a kombináció megszokott, nem ellentmondásos. A két mechanizmus különböző kérdésekre válaszol: ez a végpont-e az, amelyet várok, és engedélyezett-e ez a felhasználó vagy eszköz. Az EAP látványa egy profilban nem kapcsolja ki a kiszolgáló ellenőrzését. A profil egyetlen beállításként való olvasása az, ami miatt az emberek a rossz hitelesítő adatot állítják vissza.

Állapítsa meg, melyik állítás hibázott, mielőtt bármelyik objektumhoz hozzányúlna. A hiba szakasza megmondja, ha sorrendben olvassa.

Két hitelesítő adat, két állítás

A kiszolgáló-tanúsítvány egy nevet köt kulcshoz, és a kliens ezt a kötést a saját bizalmi tárolójához ellenőrzi. A kliens-tanúsítvány egy identitást köt kulcshoz, és az átjáró ellenőrzi, hogy a bemutatott tanúsítvány láncolódik-e valamihez, amiben megbízik. Az EAP hitelesítési cserét hordoz, amelynek tartalma a választott módszertől függ. Ez három szerkezet eltérő élettartammal, eltérő tulajdonossal és eltérő hibamódokkal.

A privát kulcsot feloldó jelmondat nem fiókjelszó, akkor sem, ha a két kérés másodperceken belül jelenik meg. Az egyik helyi az eszköz kulcstárolójában, a másikat pedig az átjáró mögötti hitelesítési kiszolgáló ellenőrzi.

Az EAP egy tartály, nem módszer

Az EAP egy keretrendszer: az átjáró és a kliens módszert tárgyal, és a módszer dönti el, hogy jelszó, token, alagúton belüli belső csere vagy tanúsítvány vesz részt benne, ahogy a strongSwan IKEv2-dokumentációja kifejti. Ezért az EAP-TLS kliensoldalról egyáltalán nem hasonlít az EAP-MSCHAPv2-re, pedig mindkettő EAP-ként jelenik meg a menüben. Az a profil, amely csak EAP-t nevez meg, nem mondta meg, mit fognak kérdezni a felhasználótól.

A módszert és a backendet együtt olvassa. A backend határozza meg a fiókformátumot, a zárolási viselkedést és azt, hogy a jelszó-visszaállítás valójában mit változtat, és ebből semmi nem látható a kliensprofilban.

A vegyes telepítés normális

A kiszolgáló-tanúsítvány plusz EAP a felhasználó számára az a forma, amelyet a legtöbb távelérési átjáró telepít, mert ellenőrizhető végpontot ad a kliensnek, és felhasználónkénti identitást ad az üzemeltetőnek egy központi fióktárolóban. Vannak kliens-tanúsítványos telepítések is, általában ott, ahol az eszköz identitása fontosabb egy jelszónál. Mindkettő jogos, és a hiba azt feltételezni, hogy amit múlt héten látott, az van Ön előtt.

Kérje meg az üzemeltetőt a dokumentált módszerre és fiókformátumra, ahelyett hogy kliens mezőneveiből következtetne rájuk.

Döntés a hiba szakasza alapján

Rendezze sorba a megfigyeléseket. A felhasználói kérés előtti bizalmi hiba kiszolgáló-tanúsítvány probléma, és egyetlen jelszó sem javítja meg. A kérést követő elutasítás felhasználó-hitelesítési probléma, az EAP-módszer és a backend a gyanúsítottak. A sikeres hitelesítést követő child-SA hiba egyik sem.

Két további megkülönböztetés számít. A kiszolgáló-tanúsítványt elutasító kliens általában névegyezés hiányát vagy ismeretlen hatóságot jelent, ami bizalmi tároló kérdése. A felhasználót elutasító átjáró gyakran naplózza az EAP-módszert és egy okkategóriát, ami fiók vagy szabályzat kérdése.

A két modell üzemeltetése

A tanúsítványoknál a munka kibocsátás, megújítás, visszavonás és elveszett eszközök eltávolítása, és az Ön által vezérelt ütemezés szerint történik. Az EAP-nál a munka a fiók életciklusa, a módszerek támogatása minden kliensplatformon és bármilyen második tényező, amelyet a backend megkövetel. Egyik modell sem olcsóbb elvontan; különböző csapatokat terhelnek. Írja le, melyiket használja a telepítése valójában, mert a támogató szkriptek jobban különböznek, mint a konfiguráció.

Tartsa őket külön a jegyzeteiben. Egy tanúsítvány lejárata egy adott dátumon okoz hibát, a fiók zárolása jelszóváltás után okoz hibát, a módszer eltérése pedig csak egy platformon okoz hibát.

Miután az identitást elfogadták

A hitelesítés egy kapu. A gyermek biztonsági társulás, a forgalomválasztók, a DNS és az alkalmazás saját engedélyei későbbi kapuk, és mindegyik a maga feltételei szerint hibázik. Az elfogadott identitás, amely semmit nem ér el, nem hitelesítési probléma.

Jegyezze fel a módszert, a használt fiókot vagy tanúsítványt és a hibázott szakaszt. Ez a feljegyzés a következő eseményt kereséssé teszi kísérlet helyett.