Bi identitate IKEv2 saio-hasiera bakarrean: lehenengo makina, gero erabiltzailea

Bezeroaren ziurtagiri bat balioztatzen da, lehenengo trukea osatzen da eta gero konexioa gelditu egiten da autentifikazio-txanda gehigarri bati buruzko errore batekin. Ziurtagiri-katean ez dago ezer gaizki eta sarean ez da ezer aldatu. Atebidea konektatzen den aldetik bigarren froga bat eskatzeko konfiguratuta dago, eta bezeroak ez du inoiz bat bidaltzen. Nork zer frogatzen duen eta zein ordenatan erabakitzea da zeregin osoa, eta zu zauden muturretik politikak irakurtzen hasten da. Mota desberdineko bi froga, ordena finkoan, diseinu-erabakia da, ez kontrol-laukia.

Sintoma: lehen froga arrakastatsuaren ondorengo hutsegitea

Lehen trukea osatzen da eta erregistroa osasuntsu ageri da, atebideak EAP bidez erabiltzaile-identitatea eskatu arte. Orduan eskuko keinua gelditu egiten da edo txanda gehigarria izendatzen duen protokolo-errore bat itzultzen du. Guztiz baliozkoa den makinaren ziurtagiria baztertzen da bere baliozkotasunarekin zerikusirik ez duen arrazoi batengatik. Politikak bigarren froga bat eskatu zuen, eta bezeroaren erantzuna ez zen inoiz iritsi.

Hutsegite horren bi deskribapenak zuzenak dira zu non zauden arabera. Bezeroaren aldetik ziurtagiri baliozkoa ukatzen duen zerbitzari bat ematen du, eta zerbitzariaren aldetik saio-hasiera amaitu ezin duen bezero bat. Gertaera bera konfiantza-arazo gisa irakurtzen da erregistro batean eta gaitasun-arazo gisa bestean. Konfiguratutako politikak bakarrik esaten dizu zein den.

Zer gehitzen duen luzapenak eta zer ez

IKEv2-k saio bakarrean autentifikazio-truke bat baino gehiago egiteko luzapen bat darama. RFC 4739-k, beste segida batzuen artean, ziurtagiri-identitatea frogatzen duen eta gero pertsona bat EAP bidez autentifikatzen duen bezero bat marrazten du. Dokumentua Experimental da, hau da, inplementazio batek ere ez dizu funtzio hori zor. Ez ezazu ezer suposatu euskarriari buruz bikoteak negoziatu arte.

Bi aldek luzapena onartu eta trukean zehar adostu behar dute. Bigarren txanda baterako konfiguratutako atebide batek ezin du bezero bat behartu bat egitera, eta onartzen duen bezero batek ez du erabiliko zerbitzariak eskatu ezean. Asimetria hori da hutsegitea normalean denbora-muga edo protokolo-errore gisa agertzearen arrazoia, gaitasunari buruzko adierazpen argi baten ordez. Alde bateko konfigurazioa irakurtzeak gertatuko denaren erdia esaten dizu.

Mutur bakoitzeko froga bat da forma ohikoa, eta hau ez da diseinu hori. Atebideak bere ziurtagiria aurkezten du, erabiltzaileak EAP bidez erantzuten du, eta alde bakoitzak bestea behin zehazki autentifikatu du. Bi froga horiek kontrako muturretatik datoz, beraz batek ere ez du ezer bereizirik esaten makina eta hura erabiltzen duen pertsonari buruz.

EAP-TLS hirugarren forma bat da, eta hau ere ez da hura. Han bezeroaren ziurtagiria EAP metodo baten barruan aurkezten da, beraz bezeroak IKE autentifikazio bakarra osatzen du oraindik. Kredentzialak txanda anitzeko kasuaren berdinak izan daitezke, protokoloak bi ordez txanda bat daraman bitartean. Horregatik EAP-TLS inplementazio batetik kopiatutako diseinuak bigarren froga espero den tokian huts egiten du.

Fitxategi berak beste modu batera irakurtzen du atebidean

swanctl fitxategi berak beste modu batera irakurtzen du non exekutatzen den arabera, eta hori da jendea estropezu egiten duen zatia. Ordenagailuan atebidea da bikotea, eta atebidean ordenagailua da bikotea, beraz idatzi local aldea nor naizen eta remote aldea nor onartuko dudan. local bloke batek mutur honek nola autentifikatzen duen deskribatzen du, eta remote bloke batek beste muturrari zer eskatzen dion adierazten du. Bi fitxategien artean bloke bat kopiatzeak haren esanahia alderantzikatzen du karaktere bat ere aldatu gabe. Bi fitxategiak alderatzeak ia ezer ez dizu esaten, hitz berberek esanahi kontrajarriak baitituzte bakoitzean.

Atal baten posizioak bere ordena ezartzen du, txanda-zenbaki batek gainidazten ez badu. Beraz, local edo remote atal gehigarriek txanda gehigarriak deskribatzen dituzte, ez alternatibak, eta swanctl.conf erreferentzian dagoen txanda-zenbaki esplizitua existitzen da ordena hori nahita egiteko. Hori gabe, bloke bat mugitzeak portaera aldatzen du. Horregatik, paperean baliokideak diruditen bi konfiguraziok kontrako ordenean joka dezakete.

Ordena-arau horrek gogoratzeko moduko hutsegite-modua sortzen du. Bigarren remote bloke bat ez da beste aukera onargarri bat; bigarren eskakizun bat da, eta horregatik edo/edo bezala irakurtzen den politika bat eta-gero bezala jokatzen du. Atebide-politika batek erregistratutako makinaren ziurtagiria onar dezake eta gero erabiltzaile horren EAP trukea eskatu, ordena horretan.

Bereizi txandak faktore independenteetatik

Bi txanda ez dira automatikoki bi faktore independente. Froga bat errepikatzeak, edo bi kredentzial biltegi berean edukitzeak, ez du diseinuak gehitu beharreko indarra ematen. Independentzia sekretuak nola gordetzen diren eta zer-k konprometitzen dituen propietatea da, ez protokoloak zenbat truke egiten dituen. Txandak faktore gisa zenbatzen dituen diseinu batek duena baino gehiago esaten du. Bereizketa hori garrantzitsuena da betetze-egitasmo batek saio-hasierak benetan zenbat faktore erabiltzen dituen galdetzen duenean.

Makina-ziurtagiri batek bere onartutako gakoaren jabetza frogatzen du, eta besterik ez. Ez da hardware-egiaztagiria ez gailu-osasun txostena, beraz jarrera-informazioa behar duen politika batek beste mekanismo bat behar du. subject eremua ere ez da fidagarria den inbentario-etiketa bat, subject ziurtagiria jaulki edo erregistratu zuenak aukeratzen baitu. Diseinuak makina osasuntsu dagoen froga bat behar badu, froga hori makina neurtzen duen osagai batetik etorri behar du.

Idatzi txanda bakoitzak benetan zer frogatzen duen gehitu aurretik. Bi txandak gauza bera bi aldiz frogatzen dutenean, bigarrenak latentzia eta laguntza-txartelak gehitzen ditu, ziurtasuna ordez. Ohar hori da txanda gehigarriak bere kostua merezi duen ala ez eztabaida gelditzen duena ere.

Idatzi parekatze-araua eta probatu ukapenak

Erabaki zein makina-identitate pareka daitezkeen zein pertsonekin, eta idatzi araua betearazpena bizi den tokian. Elkarren ondoan dauden bi kredentzial baliozkok ez dute parekatzeaz ezer frogatzen, parekatzea baimen-erabakia baita, ez autentifikazio-emaitza. Erregistroek edo autentifikazio-backendak erakundeak nahi duen harremana betearazi behar dute.

Gero probatu huts egin beharko luketena: erabiltzaile onartu bat onartu gabeko makina batean, makina-kredentziala duen erabiltzaile ez-onartu bat eta txanda gehigarria egin ezin duen bikote bat. Hirurek isilka sarbide bera jasotzen badute, politikak asmo bat deskribatzen du, hura betearazi ordez. Alderatu deklaratutako konfigurazioa daemonak jakinarazten duenarekin, inoiz bat etorri ez zen konexio bat pasa zen arau baten berdinak baitirudi:

swanctl --list-conns
swanctl --list-sas

Egiaztatu negoziatutako txandak eta ondoriozko baimena, ez soilik saio-hasiera arrakastatsua. Eta ez jo atzera IKEv1 XAuth ezarpen zaharretara bide labur gisa: bat etorri protokoloa, rolak, ordena eta bezeroaren benetako portaera, konexio batek lortu arte beharrezko txanda bat ezabatu ordez. Huts egiten duen txanda ezabatzea da bi frogako diseinu bat isilka inork berrikusi ez zuen froga bakarreko diseinu bilakatzen den modua. Utzi ezabaketa aldaketa-erregistroan.