IKEv1 s XAuth i OTP: šta svaki upit traži

IKEv1 s PSK, XAuth i OTP ne traži jednu komplikovanu lozinku. On slaže zajednički ključ između partnera, korisničku razmjenu i drugi faktor za koji backend odlučuje kako će se tražiti. Svaki sloj ima svog vlasnika i svoju poruku o grešci. Njihovo miješanje tjera ljude da ponovo upisuju jednokratni kod u polje koje čuva grupnu tajnu.

Uparite svaki upit sa slojem koji ga traži prije instaliranja još jednog klijenta ili resetovanja akreditive.

Tri tajne, tri vlasnika

Unaprijed dijeljeni ključ pripada odnosu partnera i konfiguriše se jednom od strane onoga koji posjeduje oba kraja. Korisnička akreditiva pripada autentifikacijskom backendu i provjerava se pri svakoj prijavi. Drugi faktor pripada sistemu tokena čiji se odgovor mijenja pri svakom pokušaju. Nijedan ne zamjenjuje drugi, a implementacija koja ih tretira kao jednu lozinku pada na sloju koji niko nije dokumentovao.

Zapišite tri kolone: vlasnik, trajanje i poruku o grešci koju svaki daje. Ta tabela je dijagnostički alat, a nazivi polja u klijentu nisu.

PSK: partner, ne osoba

Unaprijed dijeljeni ključ autentifikuje par gatewaya u ovom zastarjelom rasporedu, pa ga korisnička prijava nikada ne zamjenjuje. To je i vrijednost koja najčešće bude pogrešna na način da proizvede opću grešku pregovaranja umjesto upita. Kada tunel padne prije nego se pojavi bilo koji korisnički upit, sumnjivci su ključ ili prijedlozi.

Korisnička akreditiva ne može popraviti kvar prve faze. Njena rotacija troši jedinu akreditivu koju možete sigurno rotirati i pojačava pogrešnu teoriju.

XAuth: zastarjela korisnička razmjena

XAuth dodaje razmjenu korisničke autentifikacije povrh autentifikacije partnera u IKEv1, a gateway odlučuje koji je backend provjerava. Zavisno od tog backenda, razmjena može prihvatiti lozinku imenika, RADIUS akreditivu ili odgovor tokena. Riječ XAuth imenuje transport razmjene, a ne tip akreditive.

Provjerite na koji backend pokazuje profil gatewaya. To vam kaže šta će korisnik biti pitan i šta reset lozinke zaista mijenja, a nijedno se ne vidi u profilu klijenta.

OTP: šta god backend zatraži

Neke implementacije traže poseban jednokratni kod nakon lozinke, a druge definišu kombinovani format unosa s dokumentovanim separatorom. Oba postoje, a profil pred vama odlučuje koji. Izmišljanje spojenog unosa jer je radilo na drugoj lokaciji najčešći je način da spalite token za registraciju. Dokumentacija samog gatewaya jedini je izvor koji to rješava.

Koristite dokumentovani format s klijentom koji može dovršiti razmjenu koju gateway nudi.

Gdje granica klijenta ugrize

Fortinet dokumentuje 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, kao što napomena o kompatibilnosti FortiClient bilježi. Ni drugi klijenti nisu zamjenjivi: OpenConnect i openfortivpn govore određene gateway protokole, a ne proizvoljne IKEv1 profile. Provjerite IKE verziju, PSK mod, XAuth podršku i model interakcije instaliranog klijenta pojedinačno. Klijent koji se povezuje drugom metodom nije dokazao prvobitni zahtjev.

IKEv1 je zastario, pa je novo uvođenje na nepodržanom starom klijentu kratkotrajno rješenje. Zatražite od vlasnika gatewaya podržan put migracije, uključujući kako će se tu obrađivati drugi faktor.

Dijagnostika bez isključivanja faktora

Razdvojite faze u dnevniku: pregovaranje partnera, korisničku razmjenu, rezultat drugog faktora, zatim dodjelu adrese i rute. Zabilježite komponentu i fazu umjesto da isprobavate kod u svakom polju. Isključivanje faktora da bi test prošao daje tunel koji ništa ne dokazuje o implementaciji.

Čuvajte tajne registracije i zajednički ključ u zaštićenom skladištu prema procesu organizacije. Jednokratni kod u trajnoj datoteci faktor je koji je prestao biti faktor.