Dve identiteti v eni prijavi IKEv2: najprej stroj, nato uporabnik

Potrdilo odjemalca se overi, prva izmenjava se zaključi in nato se povezava ustavi z napako o dodatnem krogu preverjanja pristnosti. V verigi potrdil ni nič narobe in v omrežju se ni nič spremenilo. Prehod je konfiguriran tako, da zahteva drugo dokazilo s strani, ki se povezuje, odjemalec pa ga nikoli ne pošlje. Odločiti, kdo kaj dokazuje in v kakšnem vrstnem redu, je cela naloga in se začne z branjem politike s končne točke, na kateri stojite. Dve dokazili različne vrste v fiksnem vrstnem redu sta načrtovalska odločitev in ne potrditveno polje.

Simptom: neuspeh po uspešnem prvem dokazilu

Prva izmenjava se zaključi in dnevnik je videti zdrav, dokler prehod ne zahteva identitete uporabnika prek EAP. Takrat se rokovanje ustavi ali vrne napako protokola, ki imenuje dodatni krog. Popolnoma veljavno potrdilo stroja je zavrnjeno zaradi razloga, ki nima nobene zveze z njegovo veljavnostjo. Politika je zahtevala drugo dokazilo in odgovor odjemalca ni nikoli prispel.

Oba opisa tega neuspeha sta pravilna glede na to, kje stojite. Z odjemalčeve strani je videti kot strežnik, ki zavrača veljavno potrdilo, s strežnikove strani pa kot odjemalec, ki ne more dokončati prijave. Isti dogodek se v enem dnevniku bere kot težava z zaupanjem, v drugem pa kot težava z zmožnostmi. Samo konfigurirana politika vam pove, katera je.

Kaj razširitev doda in kaj ne

IKEv2 nosi razširitev za izvedbo več kot ene izmenjave preverjanja pristnosti v eni seji. RFC 4739 orisuje, med drugimi zaporedji, odjemalca, ki dokaže identiteto s potrdilom in nato overi osebo prek EAP. Dokument ima status Experimental, kar pomeni, da vam nobena izvedba te funkcije ne dolguje. Ničesar ne predpostavljajte o podpori, dokler se partner ne dogovori zanjo.

Obe strani morata podpirati razširitev in se o njej dogovoriti med izmenjavo. Prehod, konfiguriran za drugi krog, odjemalca ne more prisiliti, da ga izvede, odjemalec, ki jo podpira, pa je ne bo uporabil, če strežnik tega ne zahteva. Prav ta asimetrija je razlog, da se neuspeh običajno pokaže kot časovna omejitev ali napaka protokola namesto jasne izjave o zmožnosti. Branje konfiguracije ene strani vam pove polovico tega, kar se bo zgodilo.

Eno dokazilo na končno točko je običajna oblika in to ni ta načrt. Prehod predstavi svoje potrdilo, uporabnik odgovori prek EAP in vsaka stran je overila drugo natanko enkrat. Ti dve dokazili prihajata z nasprotnih končnih točk, zato nobeno posebej ne pove ničesar o stroju in osebi, ki ga uporablja.

EAP-TLS je tretja oblika in tudi to ni ta. Tam se potrdilo odjemalca predstavi znotraj metode EAP, zato odjemalec še vedno zaključi eno overitev IKE. Poverilnice so lahko videti enako kot v primeru več krogov, medtem ko protokol nosi en krog namesto dveh. Zato načrt, kopiran iz namestitve EAP-TLS, spodleti natanko na točki, kjer se pričakuje drugo dokazilo.

Ista datoteka se na prehodu bere drugače

Ista datoteka swanctl se bere drugače glede na to, kje se izvaja, in prav to je del, na katerem se ljudje spotaknejo. Na prenosniku je prehod nasprotna stran, na prehodu pa je to prenosnik, zato stran local pišite kot kdo sem in stran remote kot koga bom sprejel. Blok local opisuje, kako se ta končna točka overi, blok remote pa navaja, kaj zahteva od drugega konca. Kopiranje bloka med obema datotekama obrne njegov pomen, ne da bi spremenilo en sam znak. Primerjava obeh datotek vam ne pove skoraj ničesar, ker iste besede v vsaki pomenijo nasprotno.

Položaj odseka določa njegov vrstni red, razen če ga preglasi številka kroga. Zato dodatni odseki local ali remote opisujejo dodatne kroge in ne alternativ, izrecna številka kroga v sklicu swanctl.conf pa obstaja prav zato, da je ta vrstni red nameren. Brez nje premikanje bloka spremeni vedenje. Zato se lahko tudi dve konfiguraciji, ki sta na papirju videti enakovredni, obnašata v nasprotnem vrstnem redu.

To pravilo vrstnega reda ustvari način neuspeha, ki si ga velja zapomniti. Drugi blok remote ni še ena sprejemljiva možnost; je druga zahteva, zato se politika, ki se bere kot ali/ali, obnaša kot in-nato. Politika prehoda lahko sprejme potrdilo vpisanega stroja in nato zahteva izmenjavo EAP tega uporabnika, v tem vrstnem redu.

Ločite kroge od neodvisnih dejavnikov

Dva kroga nista samodejno dva neodvisna dejavnika. Ponavljanje dokazila ali hramba dveh poverilnic v istem shrambi ne da moči, ki bi jo načrt moral dodati. Neodvisnost je lastnost tega, kako so skrivnosti shranjene in kaj jih ogrozi, ne pa tega, koliko izmenjav izvede protokol. Načrt, ki šteje kroge kot dejavnike, precenjuje to, kar ima. Ta razlika je najpomembnejša, ko vprašanje skladnosti vpraša, koliko dejavnikov prijava dejansko uporablja.

Potrdilo stroja dokazuje posedovanje njegovega sprejetega ključa in nič več. Ni strojna atestacija in ni poročilo o zdravju naprave, zato politika, ki potrebuje informacije o stanju, potrebuje drug mehanizem. Tudi polje subject ni zanesljiva inventarna oznaka, ker subject izbere tisti, ki je potrdilo izdal ali vpisal. Če načrt potrebuje dokazilo, da je stroj zdrav, mora to dokazilo priti iz komponente, ki stroj meri.

Zapišite, kaj vsak krog v resnici dokazuje, preden ga dodate. Ko dva kroga iste stvari dokažeta dvakrat, drugi doda zakasnitev in zahtevke za podporo namesto gotovosti. Ta zapisek je tudi tisto, kar ustavi razpravo o tem, ali si dodatni krog zasluži svoje stroške.

Napišite pravilo seznanjanja in preizkusite zavrnitve

Odločite, katere identitete strojev se smejo seznanjati s katerimi osebami, in pravilo zapišite tam, kjer živi izvajanje. Dve veljavni poverilnici druga ob drugi ne dokažeta ničesar o seznanjanju, ker je seznanjanje odločitev o avtorizaciji in ne rezultat overjanja. Vpisi registracije ali zaledni sistem overjanja morajo uveljaviti razmerje, ki ga organizacija želi.

Nato preizkusite, kaj bi moralo spodleteti: sprejet uporabnik na neodobrenem stroju, neodobren uporabnik s poverilnico stroja in partner, ki ne more izvesti dodatnega kroga. Če vsi trije tiho dobijo enak dostop, politika opisuje namero, namesto da bi jo uveljavila. Primerjajte razglašeno konfiguracijo s tem, kar poroča demon, ker je povezava, ki se nikoli ni ujemala, videti enako kot pravilo, ki je šlo skozi:

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

Preverite izpogajane kroge in iz njih izhajajočo avtorizacijo, ne le uspešno prijavo. In ne segajte po starih nastavitvah IKEv1 XAuth kot bližnjici: uskladite protokol, vloge, vrstni red in dejansko vedenje odjemalca, namesto da izbrišete potreben krog, dokler povezava ne uspe. Izbris kroga, ki spodleti, je pot, po kateri načrt z dvema dokaziloma tiho postane načrt z enim dokazilom, ki ga ni nihče pregledal. Izbris ohranite v dnevniku sprememb.