IKEv1 kun XAuth kaj OTP: kion petas ĉiu kampo

IKEv1 kun PSK, XAuth kaj OTP ne petas unu komplikan pasvorton. Ĝi tavoligas komunan ŝlosilon inter la flankoj, uzantan interŝanĝon kaj duan faktoron, pri kiu la backend decidas kiel peti ĝin. Ĉiu tavolo havas sian propran posedanton kaj sian propran erarmesaĝon. Konfuzi ilin igas homojn retajpi unufojan kodon en kampon, kiu konservas grupan sekreton.

Kunigu ĉiun kampon al la tavolo, kiu petas ĝin, antaŭ ol instali alian klienton aŭ restarigi akreditilon.

Tri sekretoj, tri posedantoj

La antaŭe komuna ŝlosilo apartenas al la rilato inter la flankoj kaj estas agordata unufoje de tiu, kiu posedas ambaŭ finojn. La uzanta akreditilo apartenas al la aŭtentiga backend kaj estas validigata ĉe ĉiu ensaluto. La dua faktoro apartenas al ĵetona sistemo, kies respondo ŝanĝiĝas ĉe ĉiu provo. Neniu anstataŭas alian, kaj instalado, kiu traktas ilin kiel unu pasvorton, malsukcesas ĉe la tavolo, kiun neniu dokumentis.

Skribu tri kolumnojn: posedanto, daŭro kaj la erarmesaĝo, kiun ĉiu produktas. Tiu tabelo estas la diagnoza ilo, kaj la kampnomoj de la kliento ne estas.

PSK: la flanko, ne la persono

La antaŭe komuna ŝlosilo aŭtentigas la paron de enirejoj en ĉi tiu malnova aranĝo, do la ensaluto de la uzanto neniam anstataŭas ĝin. Ĝi ankaŭ estas la valoro plej verŝajne malĝusta tiel, ke ĝi produktas ĝeneralan intertraktan eraron anstataŭ kampon. Kiam la tunelo malsukcesas antaŭ ol aperas iu uzanta kampo, la suspektatoj estas la ŝlosilo aŭ la proponoj.

Uzanta akreditilo ne povas ripari malsukceson de la unua fazo. Ĝia rotacio malŝparas la solan akreditilon, kiun vi povas sekure rotacii, kaj fortigas la malĝustan teorion.

XAuth: la malnova uzanta interŝanĝo

XAuth aldonas uzantan aŭtentigan interŝanĝon super la aŭtentigo de la flankoj en IKEv1, kaj la enirejo decidas, kiu backend validigas ĝin. Depende de tiu backend, la interŝanĝo povas akcepti dosierujan pasvorton, RADIUS-akreditilon aŭ ĵetonan respondon. La vorto XAuth nomas la transporton de la interŝanĝo, ne la tipon de akreditilo.

Kontrolu, al kiu backend la enireja profilo montras. Tio diras al vi, kion oni petos de la uzanto kaj kion restarigo de pasvorto vere ŝanĝas, kaj neniu el ambaŭ videblas en klienta profilo.

OTP: kion ajn petas la backend

Iuj instaladoj petas apartan unufojan kodon post la pasvorto, kaj aliaj difinas kombinitan enigan formaton kun dokumentita apartigilo. Ambaŭ ekzistas, kaj la profilo antaŭ vi decidas kiun. Elpensi kunmeton ĉar ĝi funkciis aliloke estas la plej ofta maniero forbruli aliĝan ĵetonon. La propra dokumentaro de la enirejo estas la sola fonto, kiu solvas tion.

Uzu la dokumentitan formaton kun kliento, kiu povas fini la interŝanĝon, kiun la enirejo proponas.

Kie mordas la limo de la kliento

Fortinet dokumentas, ke FortiClient 7.4.4 kaj pli novaj jam ne subtenas IKEv1 por IPsec VPN, kio estas produkta kaj versia limo, ne universala forigo, kiel kompatiga noto de FortiClient registras. Ankaŭ aliaj klientoj ne estas interŝanĝeblaj: OpenConnect kaj openfortivpn parolas difinitajn enirejajn protokolojn, ne arbitrajn IKEv1-profilojn. Kontrolu aparte la IKE-version, PSK-reĝimon, XAuth-subtenon kaj interagmodelon de la instalita kliento. Kliento, kiu konektiĝas per alia metodo, ne pruvis la originan postulon.

IKEv1 estas eksmoda, do nova disvastigo sur nesubtenata malnova kliento estas mallongdaŭra solvo. Petu de la posedanto de la enirejo subtenatan migradan vojon, inkluzive de tio, kiel la dua faktoro estos traktata tie.

Diagnozi sen malŝalti la faktoron

Apartigu la etapojn en la protokolo: intertraktado de flankoj, la uzanta interŝanĝo, la rezulto de la dua faktoro, poste atribuo de adreso kaj vojo. Notu la komponanton kaj la etapon anstataŭ provi la kodon en ĉiu kampo. Malŝalti la faktoron por ke testo pasu produktas tunelon, kiu pruvas nenion pri la disvastigo.

Konservu aliĝajn sekretojn kaj la komunan ŝlosilon en protektita konservejo laŭ la procedo de la organizo. Unufoja kodo en daŭra dosiero estas faktoro, kiu ĉesis esti tia.