Divas identitātes vienā IKEv2 pieteikšanās reizē: vispirms mašīna, tad lietotājs

Klienta sertifikāts tiek validēts, pirmā apmaiņa noslēdzas, un tad savienojums apstājas ar kļūdu par papildu autentifikācijas kārtu. Sertifikātu ķēdē nekas nav nepareizi un tīklā nekas nav mainījies. Vārteja ir konfigurēta pieprasīt otru pierādījumu no pievienojošās puses, un klients to nekad neaizsūta. Izlemt, kas ko pierāda un kādā secībā, ir viss uzdevums, un tas sākas ar politikas nolasīšanu no tā galapunkta, kurā jūs stāvat. Divi dažāda veida pierādījumi noteiktā secībā ir projektēšanas lēmums, nevis izvēles rūtiņa.

Simptoms: neveiksme pēc veiksmīga pirmā pierādījuma

Pirmā apmaiņa noslēdzas un žurnāls izskatās vesels, līdz vārteja pieprasa lietotāja identitāti caur EAP. Tad rokas sasveicināšanās apstājas vai atgriež protokola kļūdu, kas nosauc papildu kārtu. Pilnīgi derīgs mašīnas sertifikāts tiek noraidīts iemesla dēļ, kam nav nekāda sakara ar tā derīgumu. Politika prasīja otru pierādījumu, un klienta atbilde tā arī nenāca.

Abi šīs neveiksmes apraksti ir precīzi atkarībā no tā, kur jūs stāvat. No klienta puses tas izskatās kā serveris, kas noraida derīgu sertifikātu, un no servera puses kā klients, kas nevar pabeigt pieteikšanos. Viens un tas pats notikums vienā žurnālā tiek lasīts kā uzticēšanās problēma, bet otrā kā iespēju problēma. Tikai konfigurētā politika pasaka, kura no tām.

Ko paplašinājums pievieno un ko ne

IKEv2 satur paplašinājumu, lai vienā sesijā veiktu vairāk nekā vienu autentifikācijas apmaiņu. RFC 4739 ieskicē, starp citām secībām, klientu, kas pierāda sertifikāta identitāti un pēc tam autentificē personu caur EAP. Dokumenta statuss ir Experimental, kas nozīmē, ka neviena implementācija jums šo funkciju nav parādā. Neizdariet pieņēmumus par atbalstu, kamēr partneris par to nav vienojies.

Abām pusēm ir jāatbalsta paplašinājums un jāvienojas par to apmaiņas laikā. Vārteja, kas konfigurēta otrajai kārtai, nevar piespiest klientu to veikt, un klients, kas to atbalsta, to neizmantos, ja serveris to neprasīs. Tieši šī asimetrija ir iemesls, kāpēc neveiksme parasti parādās kā taimauts vai protokola kļūda, nevis kā skaidrs paziņojums par iespējām. Vienas puses konfigurācijas nolasīšana pasaka pusi no tā, kas notiks.

Viens pierādījums uz galapunktu ir parastā forma, un tas nav šis projekts. Vārteja uzrāda savu sertifikātu, lietotājs atbild caur EAP, un katra puse ir autentificējusi otru tieši vienu reizi. Šie divi pierādījumi nāk no pretējiem galapunktiem, tāpēc neviens atsevišķi neko nepasaka par mašīnu un cilvēku, kas to lieto.

EAP-TLS ir trešā forma, un arī tā nav šī. Tur klienta sertifikāts tiek uzrādīts EAP metodes ietvaros, tāpēc klients joprojām veic vienu IKE autentifikāciju. Akreditācijas dati var izskatīties identiski vairāku kārtu gadījumam, kamēr protokols nes vienu kārtu divu vietā. Tāpēc projekts, kas nokopēts no EAP-TLS ieviešanas, cieš neveiksmi tieši tajā vietā, kur tiek gaidīts otrais pierādījums.

Tas pats fails uz vārtejas tiek lasīts citādi

Tas pats swanctl fails tiek lasīts citādi atkarībā no tā, kur tas darbojas, un tieši šī daļa cilvēkus paklūpina. Klēpjdatorā vārteja ir partneris, bet uz vārtejas partneris ir klēpjdators, tāpēc local pusi rakstiet kā kas es esmu, bet remote pusi kā ko es pieņemšu. local bloks apraksta, kā šis galapunkts autentificē sevi, un remote bloks norāda, ko tas prasa no otra gala. Bloka kopēšana starp diviem failiem apgriež tā nozīmi, nemainot nevienu rakstzīmi. Divu failu salīdzināšana gandrīz neko nepasaka, jo tie paši vārdi katrā nozīmē pretējo.

Sadaļas novietojums nosaka tās secību, ja vien to nepārspēj kārtas numurs. Tāpēc papildu local vai remote sadaļas apraksta papildu kārtas, nevis alternatīvas, un skaidrais kārtas numurs swanctl.conf atsaucē pastāv tieši tāpēc, lai šī secība būtu apzināta. Bez tā bloka pārvietošana maina uzvedību. Tāpēc arī divas konfigurācijas, kas uz papīra izskatās līdzvērtīgas, var darboties pretējā secībā.

Šis secības noteikums rada neveiksmes veidu, ko ir vērts atcerēties. Otrais remote bloks nav vēl viena pieņemama iespēja; tas ir otrs pieprasījums, tāpēc politika, kas lasās kā vai/vai, uzvedas kā un-tad. Vārtejas politika var pieņemt reģistrētās mašīnas sertifikātu un pēc tam pieprasīt tā lietotāja EAP apmaiņu tieši šajā secībā.

Atšķiriet kārtas no neatkarīgiem faktoriem

Divas kārtas nav automātiski divi neatkarīgi faktori. Pierādījuma atkārtošana vai divu akreditācijas datu glabāšana vienā krātuvē nedod spēku, ko projektam vajadzēja pievienot. Neatkarība ir īpašība tam, kā tiek glabāti noslēpumi un kas tos apdraud, nevis tam, cik apmaiņu protokols veic. Projekts, kas kārtas skaita kā faktorus, pārvērtē to, kas tam ir. Šī atšķirība ir vissvarīgākā tad, kad atbilstības jautājums jautā, cik faktoru pieteikšanās faktiski izmanto.

Mašīnas sertifikāts pierāda savas pieņemtās atslēgas piederību un neko vairāk. Tas nav aparatūras atestācija un nav ierīces veselības ziņojums, tāpēc politikai, kurai vajadzīga stāvokļa informācija, vajadzīgs cits mehānisms. Arī subject lauks nav uzticama inventarizācijas birka, jo subject izvēlas tas, kas sertifikātu izdeva vai reģistrēja. Ja projektam vajadzīgs pierādījums, ka mašīna ir vesela, šim pierādījumam jānāk no komponentes, kas mašīnu mēra.

Pierakstiet, ko katra kārta faktiski pierāda, pirms to pievienojat. Kad divas kārtas vienu un to pašu pierāda divreiz, otrā pievieno aizturi un atbalsta biļetes, nevis pārliecību. Šī piezīme arī aptur strīdu par to, vai papildu kārta ir sava izmaksu vērta.

Uzrakstiet savienošanas noteikumu un pārbaudiet atteikumus

Izlemiet, kuras mašīnu identitātes drīkst savienoties ar kuriem cilvēkiem, un uzrakstiet noteikumu tur, kur dzīvo izpilde. Divi derīgi akreditācijas dati blakus viens otram neko nepierāda par savienošanu, jo savienošana ir autorizācijas lēmums, nevis autentifikācijas rezultāts. Reģistrācijas ierakstiem vai autentifikācijas backend ir jāizpilda attiecības, ko organizācija vēlas.

Pēc tam pārbaudiet, kam vajadzētu ciest neveiksmi: pieņemts lietotājs neapstiprinātā mašīnā, neapstiprināts lietotājs ar mašīnas akreditācijas datiem un partneris, kas nevar veikt papildu kārtu. Ja visi trīs klusi saņem tādu pašu piekļuvi, politika apraksta nodomu, nevis to izpilda. Salīdziniet deklarēto konfigurāciju ar to, ko ziņo dēmons, jo savienojums, kas nekad nav sakritis, izskatās identiski kā noteikums, kas izgāja:

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

Pārbaudiet sarunātās kārtas un no tām izrietošo autorizāciju, ne tikai veiksmīgo pieteikšanos. Un neķerieties pie vecajiem IKEv1 XAuth iestatījumiem kā pie saīsnes: saskaņojiet protokolu, lomas, secību un klienta reālo uzvedību, nevis dzēsiet nepieciešamo kārtu, kamēr savienojums neizdodas. Neveiksmīgās kārtas dzēšana ir veids, kā projekts ar diviem pierādījumiem klusi kļūst par projektu ar vienu pierādījumu, ko neviens nav pārskatījis. Saglabājiet dzēšanu izmaiņu žurnālā.