IKEv1 sa XAuth i OTP: šta svaki upit traži
Grupni PSK, korisnička razmena XAuth i OTP izazov su tri različita unosa. Uparite svaki upit sa njegovim vlasnikom pre instaliranja još jednog klijenta.
IKEv1 sa PSK, XAuth i OTP ne traži jednu komplikovanu lozinku. Slaže deljeni ključ između peerova, korisničku razmenu i drugi faktor čiji način traženja određuje backend. Svaki sloj ima svog vlasnika i svoju poruku o grešci. Mešanje dovodi do toga da ljudi ponovo ukucaju jednokratni kod u polje koje čuva grupnu tajnu.
Uparite svaki upit sa slojem koji ga traži pre instaliranja drugog klijenta ili resetovanja akreditive.
Tri tajne, tri vlasnika
Deljeni ključ pripada odnosu između peerova i konfiguriše se jednom od strane onoga ko upravlja oba kraja. Korisnička akreditiva pripada backendu za autentifikaciju i proverava se pri svakoj prijavi. Drugi faktor pripada sistemu tokena čiji se odgovor menja pri svakom pokušaju. Nijedan ne zamenjuje drugi, a postavka koja ih tretira kao jednu lozinku pada na sloju koji niko nije dokumentovao.
Zapišite tri kolone: vlasnik, životni vek i poruku o grešci koju svaki proizvodi. Dijagnostički alat je ta tabela, a ne imena polja u klijentu.
| 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: peera, ne osobe
U ovom starom rasporedu deljeni ključ autentifikuje par gejtveja, pa ga prijava korisnika nikada ne zamenjuje. To je i vrednost koja se najčešće pogreši na način koji proizvodi opštu grešku pregovaranja umesto upita. Kada tunel padne pre nego što se pojavi bilo koji korisnički upit, osumnjičeni su ključ ili predlozi.
Korisnička akreditiva ne može popraviti neuspeh prve faze. Njena rotacija troši jedinu akreditivu koju možete bezbedno rotirati i učvršćuje pogrešnu teoriju.
XAuth: stara korisnička razmena
XAuth dodaje razmenu autentifikacije korisnika povrh autentifikacije peera u IKEv1, a gejtvej odlučuje koji backend je proverava. U zavisnosti od tog backenda, razmena može prihvatiti lozinku direktorijuma, akreditivu RADIUS ili odgovor tokena. Reč XAuth imenuje transport razmene, ne tip akreditive.
Proverite na koji backend pokazuje profil gejtveja. To govori šta će korisnik biti pitan i šta reset lozinke zaista menja, a ni jedno se ne vidi u profilu klijenta.
OTP: šta god backend zatraži
Neke postavke traže poseban jednokratni kod posle lozinke, a druge definišu kombinovani format unosa sa dokumentovanim separatorom. Oba postoje, a profil pred vama odlučuje koji. Izmišljanje spajanja zato što je radilo na drugoj lokaciji najčešći je način da spalite registracioni token. O tome odlučuje samo dokumentacija samog gejtveja.
Koristite dokumentovani format sa klijentom koji može da dovrši razmenu koju gejtvej nudi.
Gde granica klijenta ujeda
Fortinet navodi da FortiClient 7.4.4 i noviji više ne podržavaju IKEv1 za IPsec VPN, što je granica proizvoda i verzije, a ne univerzalno uklanjanje, kako beleži napomena o kompatibilnosti FortiClient. Ni drugi klijenti nisu zamenljivi: OpenConnect i openfortivpn govore određene protokole gejtveja, ne proizvoljne IKEv1 profile. Proverite pojedinačno verziju IKE, režim PSK, podršku za XAuth i model interakcije instaliranog klijenta. Klijent koji se povezuje drugom metodom nije dokazao prvobitni zahtev.
IKEv1 je zastareo, pa je novo uvođenje na nepodržanom starom klijentu kratkotrajno rešenje. Zatražite od vlasnika gejtveja podržanu putanju migracije, uključujući kako će tamo biti obrađen drugi faktor.
Dijagnostika bez isključivanja faktora
Razdvojite faze u dnevniku: pregovaranje peerova, korisnička razmena, rezultat drugog faktora, zatim dodela adrese i rute. Beležite komponentu i fazu umesto da isprobavate kod u svakom polju. Isključivanje faktora da bi test prošao stvara tunel koji ništa ne dokazuje o postavci.
Čuvajte registracione tajne i deljeni ključ u zaštićenom skladištu po procesu organizacije. Jednokratni kod u trajnoj datoteci je faktor koji je prestao da bude faktor.