EAP ala bezeroaren ziurtagiriak? IKEv2 autentifikazioa erabakitzen

Zure atebideak bere identitatea ziurtagiri batekin froga dezake, eta zurea EAP bidez, eta konbinazio hori ohikoa da, ez kontraesankorra. Bi mekanismoek galdera desberdinak erantzuten dituzte: mutur hau espero dudana da, eta erabiltzaile edo gailu hau baimenduta dago. Profil batean EAP ikusteak ez du zerbitzariaren balidazioa itzaltzen. Profila ezarpen bakar gisa irakurtzea da jendea kredentzial okerra berrezartzera eramaten duena.

Erabaki zein aldarrikapenek huts egin duen bi objektuetako edozein ukitu aurretik. Hutsegitearen etapek esango dizu, ordenan irakurtzen baduzu.

Bi kredentzial, bi aldarrikapen

Zerbitzariaren ziurtagiri batek izen bat gako bati lotzen dio, eta bezeroak lotura hori bere konfiantza biltegian egiaztatzen du. Bezeroaren ziurtagiri batek identitate bat gako bati lotzen dio, eta atebideak egiaztatzen du aurkeztutako ziurtagiria konfiantzazko zerbaitetara kateatzen den. EAPek autentifikazio truke bat darama, zeinaren edukia hautatutako metodoaren araberakoa den. Hiru egitura dira, bizitza desberdinak, jabe desberdinak eta hutsegite modu desberdinak dituztenak.

Gako pribatu bat irekitzen duen pasaesaldi bat ez da kontu pasahitz bat, bi gonbidapenak elkarren segundotan agertzen direnean ere. Bat gailuaren gako biltegian lokala da, eta bestea atebidearen atzean dagoen autentifikazio zerbitzari batek balidatzen du.

EAP edukiontzi bat da, ez metodo bat

EAP esparru bat da: atebideak eta bezeroak metodo bat negoziatzen dute, eta metodoak erabakitzen du pasahitz bat, token bat, barrunbe tunelatutako truke bat edo ziurtagiri bat inplikatuta dagoen, strongSwan-en IKEv2 dokumentazioak azaltzen duen bezala. Horregatik EAP-TLS ez da batere antzekoa EAP-MSCHAPv2-rekin bezeroaren aldetik, biak menu batean EAP gisa agertu arren. EAP soilik aipatzen duen profil batek ez dizu esan erabiltzaileari zer eskatuko zaion.

Irakurri metodoa eta backend-a elkarrekin. Backend-ak kontu formatua, blokeo portaera eta pasahitz berrezarpenak benetan zer aldatzen duen zehazten du, eta horietako ezer ez da ikusgai bezeroaren profilean.

Inplementazio mistoa normala da

Zerbitzari ziurtagiria gehi EAP erabiltzailearentzat da urruneko sarbideko atebide gehienek inplementatzen duten forma, bezeroari egiaztagarria den mutur bat ematen diolako eta operadoreari erabiltzaile bakoitzeko identitatea kontu biltegi zentral batean. Bezeroaren ziurtagiriekin egindako inplementazioak ere badaude, normalean gailuaren identitatea pasahitz bat baino garrantzitsuagoa den tokietan. Biak dira legitimoa, eta akatsa da joan den astean ikusitakoa aurrez aurre duzuna dela suposatzea.

Eskatu operadoreari dokumentatutako metodoa eta kontu formatua, bezero bateko eremu izenetatik ondorioztatu beharrean.

Hutsegitearen etapetik erabakitzea

Ordenatu behaketak. Erabiltzailearen edozein gonbidapen baino lehenagoko konfiantza errore bat zerbitzari ziurtagiriaren arazoa da eta pasahitz batek ere ez du konponduko. Gonbidapen bati uko egiteak jarraitzen badio, erabiltzailearen autentifikazioaren arazoa da, EAP metodoa eta backend-a susmagarri gisa. Autentifikazio arrakastatsuari child-SA hutsegiteak jarraitzen badio, ez da bietako bat ere.

Beste bi bereizketa garrantzitsuak dira. Zerbitzariaren ziurtagiria ukatzen duen bezeroak normalean izen desadostasuna edo autoritate ezezaguna jakinarazten du, eta hori konfiantza biltegiko kontua da. Erabiltzailea ukatzen duen atebideak EAP metodoa eta arrazoi kategoria erregistratzen ditu sarritan, eta hori kontu edo politika kontua da.

Bi modeloak erabiltzea

Ziurtagirietan lana igortzea, berritzea, baliogabetzea eta galdutako gailuak kentzea da, eta zuk kontrolatzen duzun egutegi baten arabera gertatzen da. EAPn lana kontuaren bizi-zikloa, metodoen laguntza bezero plataforma bakoitzean eta backend-ak eskatzen duen bigarren faktorea da. Ez modeloa da abstraktuan merkeagoa; talde desberdinak kargatzen dituzte. Idatzi zure inplementazioak zein erabiltzen duen benetan, laguntza scriptak konfigurazioak baino gehiago desberdintzen direlako.

Mantendu bereizita zure oharretan. Ziurtagiri baten iraungipenak data jakin batean hutsegitea eragiten du, kontu blokeoak pasahitz aldaketaren ondoren hutsegitea eragiten du, eta metodo desadostasunak plataforma bakarrean soilik eragiten du hutsegitea.

Identitatea onartu ondoren

Autentifikazioa ate bat da. Child segurtasun elkartea, trafiko hautatzaileak, DNS eta aplikazioaren beraren baimenak geroagoko ateak dira, eta bakoitzak bere baldintzetan huts egiten du. Ezer lortzen ez duen identitate onartu bat ez da autentifikazio arazoa.

Erregistratu metodoa, erabilitako kontua edo ziurtagiria eta huts egin zuen etapa. Ohar horrek hurrengo gorabehera bilaketa bihurtzen du, esperimentu beharrean.