IKEv1 XAuthhal és OTP-vel: mit kér minden mező
A csoportos PSK, a felhasználói XAuth-csere és az OTP-kihívás három különböző bemenet. Rendelje minden mezőt a tulajdonosához, mielőtt újabb klienst telepít.
Az IKEv1 PSK-val, XAuthhal és OTP-vel nem egyetlen bonyolult jelszót kér. Egymásra rétegez egy társak közötti megosztott kulcsot, egy felhasználói cserét és egy második tényezőt, amelynek kéréséről a backend dönt. Minden rétegnek saját tulajdonosa és saját hibaüzenete van. Ha összekeverik őket, az emberek egy egyszeri kódot írnak újra egy mezőbe, amely csoporttitkot tárol.
Rendelje minden mezőt ahhoz a réteghez, amely kéri, mielőtt újabb klienst telepít vagy hitelesítő adatot állít vissza.
Három titok, három tulajdonos
Az előre megosztott kulcs a társviszonyhoz tartozik, és egyszer konfigurálja az, aki mindkét végét birtokolja. A felhasználói hitelesítő adat a hitelesítési backendhez tartozik, és minden bejelentkezéskor ellenőrzik. A második tényező egy tokenrendszerhez tartozik, amelynek válasza minden kísérletnél változik. Egyik sem helyettesíti a másikat, és az a telepítés, amely egyetlen jelszóként kezeli őket, abban a rétegben hibázik, amelyet senki nem dokumentált.
Írjon fel három oszlopot: tulajdonos, élettartam és a hibaüzenet, amelyet mindegyik ad. Az a táblázat a diagnosztikai eszköz, nem a kliens mezőnevei.
| Layer | Owner | Lifetime |
|---|---|---|
| Pre-shared key | Peer configuration | Until operators change it |
| XAuth credential | Authentication backend | Per session, per policy |
| One-time code | Token system | Single use |
PSK: a társ, nem a személy
Az előre megosztott kulcs ebben a régi elrendezésben az átjárópárt hitelesíti, ezért a felhasználói bejelentkezés soha nem helyettesíti. Ez az az érték is, amely a legvalószínűbben hibás úgy, hogy mező helyett általános egyeztetési hibát eredményez. Ha az alagút bármely felhasználói mező megjelenése előtt meghiúsul, a kulcs vagy a javaslatok a gyanúsítottak.
Egy felhasználói hitelesítő adat nem tudja kijavítani az első fázis hibáját. A cseréje elpazarolja az egyetlen hitelesítő adatot, amelyet biztonságosan cserélhet, és megerősíti a rossz elméletet.
XAuth: a régi felhasználói csere
Az XAuth felhasználói hitelesítési cserét ad az IKEv1 társ-hitelesítése fölé, és az átjáró dönti el, melyik backend ellenőrzi. Attól a backendtől függően a csere elfogadhat címtár-jelszót, RADIUS-hitelesítő adatot vagy tokenválaszt. Az XAuth szó a csere szállítását nevezi meg, nem a hitelesítő adat típusát.
Ellenőrizze, melyik backendre mutat az átjáróprofil. Ez megmondja, mit kérnek a felhasználótól, és mit változtat valójában a jelszó-visszaállítás, és egyik sem látható a kliensprofilban.
OTP: amit a backend kér
Egyes telepítések a jelszó után külön egyszeri kódot kérnek, mások dokumentált elválasztóval kombinált beviteli formátumot határoznak meg. Mindkettő létezik, és az előtted lévő profil dönti el, melyik. Összefűzést kitalálni, mert máshol működött, a leggyakoribb módja egy regisztrációs token elégetésének. Magának az átjárónak a dokumentációja az egyetlen forrás, amely ezt eldönti.
Használja a dokumentált formátumot olyan klienssel, amely be tudja fejezni az átjáró által kínált cserét.
Ahol a kliens határa harap
A Fortinet dokumentálja, hogy a FortiClient 7.4.4 és újabb verziói már nem támogatják az IKEv1-et IPsec VPN-ekhez, ami termék- és verzióhatár, nem általános eltávolítás, ahogy FortiClient kompatibilitási megjegyzés rögzíti. Más kliensek sem csereszabatosak: az OpenConnect és az openfortivpn meghatározott átjáróprotokollokat beszél, nem önkényes IKEv1-profilokat. Ellenőrizze külön a telepített kliens IKE-verzióját, PSK-módját, XAuth-támogatását és interakciós modelljét. Az a kliens, amely más módszerrel csatlakozik, nem bizonyította az eredeti követelményt.
Az IKEv1 elavult, ezért egy nem támogatott régi kliensre épülő új bevezetés rövid életű megoldás. Kérjen az átjáró tulajdonosától támogatott migrációs utat, beleértve azt is, hogyan kezelik ott a második tényezőt.
Diagnózis a tényező kikapcsolása nélkül
Válassza szét a szakaszokat a naplóban: társ-egyeztetés, a felhasználói csere, a második tényező eredménye, majd a cím- és útvonal-kiosztás. Jegyezze fel az összetevőt és a szakaszt ahelyett, hogy minden mezőben kipróbálná a kódot. A tényező kikapcsolása, hogy egy teszt átmenjen, olyan alagutat ad, amely semmit nem bizonyít a telepítésről.
Tárolja a regisztrációs titkokat és a megosztott kulcsot védett tárolóban a szervezet folyamata szerint. Az állandó fájlban lévő egyszeri kód olyan tényező, amely megszűnt tényező lenni.