IKEv1 s XAuth a OTP: co který prompt žádá
Skupinový PSK, uživatelská výměna XAuth a výzva OTP jsou tři různé vstupy. Přiřaďte každý prompt jeho vlastníkovi, než nainstalujete dalšího klienta.
IKEv1 s PSK, XAuth a OTP nežádá jedno složité heslo. Vrství sdílený klíč mezi protějšky, uživatelskou výměnu a druhý faktor, o kterém backend rozhoduje, jak se má vyžádat. Každá vrstva má svého vlastníka a svou chybovou zprávu. Jejich záměna vede lidi k tomu, aby znovu zadávali jednorázový kód do pole, které ukládá skupinové tajemství.
Přiřaďte každý prompt vrstvě, která ho vyžaduje, než nainstalujete dalšího klienta nebo resetujete přihlašovací údaj.
Tři tajemství, tři vlastníci
Předem sdílený klíč patří vztahu protějšků a konfiguruje ho jednou ten, kdo vlastní oba konce. Uživatelský údaj patří autentizačnímu backendu a ověřuje se při každém přihlášení. Druhý faktor patří tokenovému systému, jehož odpověď se mění při každém pokusu. Žádný nenahrazuje jiný a nasazení, které s nimi zachází jako s jedním heslem, selhává ve vrstvě, kterou nikdo nezdokumentoval.
Zapište tři sloupce: vlastník, životnost a chybovou zprávu, kterou každý vydá. Tahle tabulka je diagnostický nástroj, nikoli názvy polí v klientovi.
| 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: protějšek, ne osoba
Předem sdílený klíč autentizuje dvojici bran v tomto zastaralém uspořádání, takže přihlášení uživatele ho nikdy nenahradí. Je to také hodnota, která nejčastěji bývá špatná tak, že místo promptu vznikne obecná chyba vyjednávání. Když tunel selže dřív, než se objeví jakýkoli uživatelský prompt, podezřelými jsou klíč nebo návrhy.
Uživatelský údaj nemůže opravit selhání první fáze. Jeho rotace plýtvá jediným údajem, který můžete bezpečně rotovat, a posiluje špatnou teorii.
XAuth: zastaralá uživatelská výměna
XAuth přidává výměnu uživatelské autentizace nad autentizaci protějšku v IKEv1 a brána rozhoduje, který backend ji ověří. Podle tohoto backendu může výměna přijmout heslo z adresáře, údaj RADIUS nebo odpověď tokenu. Slovo XAuth pojmenovává přenos výměny, ne typ údaje.
Zkontrolujte, na který backend profil brány ukazuje. To vám řekne, na co se uživatele zeptají a co reset hesla skutečně změní, a ani jedno není v profilu klienta vidět.
OTP: co si backend vyžádá
Některá nasazení žádají po heslu samostatný jednorázový kód, jiná definují kombinovaný formát vstupu s dokumentovaným oddělovačem. Existují oba a rozhoduje profil před vámi. Vymýšlet spojení, protože fungovalo jinde, je nejčastější způsob, jak spálit token registrace. Dokumentace samotné brány je jediný zdroj, který to rozsoudí.
Použijte dokumentovaný formát s klientem, který dokáže dokončit výměnu, kterou brána nabízí.
Kde hranice klienta kousne
Fortinet dokumentuje, že FortiClient 7.4.4 a novější už nepodporují IKEv1 pro IPsec VPN, což je hranice produktu a verze, nikoli plošné odstranění, jak poznámka ke kompatibilitě FortiClient zaznamenává. Ani ostatní klienti nejsou zaměnitelní: OpenConnect a openfortivpn mluví konkrétními protokoly bran, ne libovolnými profily IKEv1. Zkontrolujte zvlášť verzi IKE, režim PSK, podporu XAuth a model interakce nainstalovaného klienta. Klient, který se připojuje jinou metodou, původní požadavek neprokázal.
IKEv1 je zastaralé, takže nové zavedení na nepodporovaném starém klientovi je krátkodobé řešení. Požádejte vlastníka brány o podporovanou cestu migrace, včetně toho, jak se tam bude řešit druhý faktor.
Diagnostika bez vypnutí faktoru
Oddělte v logu fáze: vyjednávání protějšků, uživatelskou výměnu, výsledek druhého faktoru, pak přidělení adresy a trasy. Zaznamenejte komponentu a fázi místo zkoušení kódu v každém poli. Vypnutí faktoru, aby test prošel, vytvoří tunel, který o nasazení nic nedokazuje.
Uchovávejte registrační tajemství a sdílený klíč v chráněném úložišti podle procesu organizace. Jednorázový kód v trvalém souboru je faktor, který přestal být faktorem.