Kaks identiteeti ühes IKEv2-sisselogimises: kõigepealt masin, seejärel kasutaja

Kliendi sertifikaat valideeritakse, esimene vahetus lõpeb ja siis peatub ühendus veaga täiendava autentimisvooru kohta. Sertifikaadiahelas pole midagi valesti ja võrgus pole miski muutunud. Lüüs on seadistatud nõudma teist tõendit ühenduvalt poolelt ja klient ei saada seda kunagi. Otsustada, kes mida tõestab ja mis järjekorras, on kogu ülesanne, ja see algab poliitika lugemisest sellest otspunktist, kus te seisate. Kaks eri liiki tõendit kindlas järjekorras on disainiotsus, mitte märkeruut.

Sümptom: ebaõnnestumine pärast edukat esimest tõendit

Esimene vahetus lõpeb ja logi näeb terve välja, kuni lüüs küsib EAP kaudu kasutaja identiteeti. Siis jääb käepigistus seisma või tagastab protokollivea, mis nimetab täiendava vooru. Täiesti kehtiv masina sertifikaat lükatakse tagasi põhjusel, millel pole selle kehtivusega mingit seost. Poliitika nõudis teist tõendit ja kliendi vastus ei jõudnud kunagi kohale.

Selle ebaõnnestumise mõlemad kirjeldused on õiged sõltuvalt sellest, kus te seisate. Kliendi poolelt näeb see välja nagu server, mis lükkab tagasi kehtiva sertifikaadi, ja serveri poolelt nagu klient, kes ei suuda sisselogimist lõpetada. Sama sündmus loetakse ühes logis usaldusprobleemiks ja teises võimekuseprobleemiks. Ainult seadistatud poliitika ütleb teile, milline neist see on.

Mida laiendus lisab ja mida mitte

IKEv2 kannab laiendust rohkem kui ühe autentimisvahetuse tegemiseks ühes seansis. RFC 4739 visandab muuhulgas järjestuse, kus klient tõestab sertifikaadi identiteeti ja autentib seejärel inimese EAP kaudu. Dokument on staatusega Experimental, mis tähendab, et ükski implementatsioon ei võlgne teile seda funktsiooni. Ärge eeldage toetuse kohta midagi enne, kui vastaspool selle läbi räägib.

Mõlemad pooled peavad laiendust toetama ja selle vahetuse käigus kokku leppima. Teise vooru jaoks seadistatud lüüs ei saa klienti selleks sundida ja klient, kes seda toetab, ei kasuta seda, kui server ei küsi. Just see asümmeetria on põhjus, miks ebaõnnestumine ilmub tavaliselt aegumise või protokolliveana, mitte selge võimekusavaldusena. Ühe poole seadistuse lugemine ütleb teile pooled sellest, mis juhtub.

Üks tõend otspunkti kohta on tavaline kuju ja see pole see disain. Lüüs esitab oma sertifikaadi, kasutaja vastab EAP kaudu ja kumbki pool on teise täpselt üks kord autentinud. Need kaks tõendit tulevad vastandlikest otspunktidest, seega ei ütle kumbki eraldi midagi masina ja seda kasutava inimese kohta.

EAP-TLS on kolmas kuju ja ka see pole see. Seal esitatakse kliendi sertifikaat EAP-meetodi sees, seega klient lõpetab ikkagi ühe IKE autentimise. Volitused võivad paista identsed mitme vooru juhtumiga, samal ajal kui protokoll kannab ühte vooru kahe asemel. Seetõttu ebaõnnestub EAP-TLS-i juurutusest kopeeritud disain täpselt kohas, kus teist tõendit oodatakse.

Sama fail loetakse lüüsil teisiti

Sama swanctl-fail loetakse teisiti sõltuvalt sellest, kus see töötab, ja just see ajab inimesed segadusse. Sülearvutis on lüüs vastaspool ja lüüsil on sülearvuti vastaspool, seega kirjutage local pool nii, kes ma olen, ja remote pool nii, keda ma vastu võtan. local plokk kirjeldab, kuidas see otspunkt end autendib, ja remote plokk ütleb, mida see teiselt poolelt nõuab. Ploki kopeerimine kahe faili vahel pöörab selle tähenduse ümber, muutmata ühtki tähemärki. Kahe faili võrdlemine ei ütle teile peaaegu midagi, sest samad sõnad tähendavad kummaski vastandlikku.

Jaotise asukoht määrab selle järjekorra, kui vooru number seda ei ületa. Seega kirjeldavad täiendavad local või remote jaotised täiendavaid voorusid, mitte alternatiive, ja selgesõnaline vooru number, mis on swanctl.conf viites sees, on olemas just selleks, et see järjestus oleks teadlik. Ilma selleta muudab ploki liigutamine käitumist. Seetõttu võivad kaks paberil võrdväärsena näivat seadistust käituda vastupidises järjekorras.

See järjestusreegel tekitab rikkerežiimi, mida tasub meeles pidada. Teine remote plokk pole veel üks vastuvõetav valik; see on teine nõue, mistõttu poliitika, mis loetakse kas/või, käitub nagu ja-seejärel. Lüüsi poliitika võib registreeritud masina sertifikaadi vastu võtta ja seejärel nõuda selle kasutaja EAP-vahetust, just selles järjekorras.

Eristage voorusid sõltumatutest faktoritest

Kaks vooru ei ole automaatselt kaks sõltumatut faktorit. Tõendi kordamine või kahe volituse hoidmine samas hoidlas ei anna jõudu, mille disain pidi lisama. Sõltumatus on omadus selle kohta, kuidas saladusi hoitakse ja mis neid kahjustab, mitte selle kohta, kui palju vahetusi protokoll teeb. Disain, mis loeb voorusid faktoriteks, hindab oma võimet üle. See erinevus on kõige olulisem siis, kui vastavusküsimus küsib, kui palju faktoreid sisselogimine tegelikult kasutab.

Masina sertifikaat tõestab oma vastuvõetud võtme valdamist ja mitte enamat. See pole riistvara atestatsioon ega seadme terviseraport, seega vajab seisunditeabe poliitika teist mehhanismi. Ka subject väli pole usaldusväärne inventarisilt, sest subject valib see, kes sertifikaadi väljastas või registreeris. Kui disain vajab tõendit, et masin on terve, peab see tõend tulema komponendist, mis masinat mõõdab.

Kirjutage üles, mida iga voor tegelikult tõestab, enne kui selle lisate. Kui kaks vooru tõestavad sama asja kaks korda, lisab teine latentsust ja tugipileteid, mitte kindlust. See märkus on ka see, mis peatab vaidluse, kas täiendav voor on oma hinda väärt.

Kirjutage paaritusreegel ja testige keeldumisi

Otsustage, millised masina identiteedid tohivad milliste inimestega paarduda, ja kirjutage reegel sinna, kus elab jõustamine. Kaks kehtivat volitust kõrvuti ei tõesta paarituse kohta midagi, sest paaritamine on autoriseerimisotsus, mitte autentimise tulemus. Registreerimiskirjed või autentimise taustaprogramm peavad jõustama suhte, mida organisatsioon soovib.

Seejärel testige, mis peaks ebaõnnestuma: heakskiidetud kasutaja heakskiitmata masinas, heakskiitmata kasutaja, kellel on masina volitus, ja vastaspool, kes ei suuda täiendavat vooru teha. Kui kõik kolm saavad vaikselt sama juurdepääsu, kirjeldab poliitika kavatsust, selle asemel et seda jõustada. Võrrelge deklareeritud seadistust sellega, mida deemon teatab, sest ühendus, mis kunagi ei sobitunud, näeb välja identne reegliga, mis läbis:

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

Kontrollige läbiräägitud voorusid ja sellest tulenevat autoriseerimist, mitte ainult edukat sisselogimist. Ja ärge haarake vanade IKEv1 XAuth seadete järele kui otsetee järele: sobitage protokoll, rollid, järjekord ja kliendi tegelik käitumine, selle asemel et kustutada nõutav voor, kuni ühendus õnnestub. Ebaõnnestuva vooru kustutamine on viis, kuidas kahe tõendi disain muutub vaikselt ühe tõendi disainiks, mida keegi ei vaadanud. Jätke kustutamine muudatuste kirjesse.