Du identoj en unu IKEv2-saluto: unue la maŝino, poste la uzanto

Klienta atestilo validiĝas, la unua interŝanĝo kompletiĝas, kaj poste la konekto haltas kun eraro pri plia aŭtentiga raŭndo. Nenio en la atestila ĉeno estas malĝusta kaj nenio en la reto ŝanĝiĝis. La pordego estas agordita postuli duan pruvon de la flanko, kiu konektiĝas, kaj la kliento neniam sendas unu. Decidi, kiu pruvas kion, kaj en kiu ordo, estas la tuta tasko, kaj ĝi komenciĝas legante la politikon de la finpunkto, sur kiu vi staras. Du pruvoj de malsamaj specoj, en fiksa ordo, estas projektdecido kaj ne markobutono.

La simptomo: malsukceso post sukcesa unua pruvo

La unua interŝanĝo kompletiĝas kaj la protokolo aspektas sana, ĝis la pordego petas uzanto-identecon per EAP. Tiam la manpremo haltas aŭ redonas protokolan eraron, kiu nomas la plian raŭndon. Tute valida maŝina atestilo estas malakceptata pro kaŭzo, kiu havas nenion komunan kun ĝia valideco. La politiko petis duan pruvon, kaj la respondo de la kliento neniam alvenis.

Ambaŭ priskriboj de tiu malsukceso estas ĝustaj laŭ tio, kie vi staras. De la flanko de la kliento ĝi aspektas kiel servilo, kiu malakceptas validan atestilon, kaj de la flanko de la servilo kiel kliento, kiu ne povas fini la saluton. La sama okazaĵo legeblas kiel fida problemo en unu protokolo kaj kiel kapabla problemo en la alia. Nur la agordita politiko diras al vi, kiu ĝi estas.

Kion la etendaĵo aldonas, kaj kion ne

IKEv2 portas etendaĵon por pli ol unu aŭtentiga interŝanĝo ene de unu seanco. RFC 4739 skizas, inter aliaj sinsekvoj, klienton, kiu pruvas atestilan identecon kaj poste aŭtentigas personon per EAP. La dokumento estas Experimental, kio signifas, ke neniu efektivigo ŝuldas al vi tiun funkcion. Ne supozu ion pri subteno, ĝis la kunulo intertraktos ĝin.

Ambaŭ flankoj devas subteni la etendaĵon kaj interkonsenti pri ĝi dum la interŝanĝo. Pordego agordita por dua raŭndo ne povas devigi klienton plenumi unu, kaj kliento, kiu subtenas ĝin, ne uzos ĝin se la servilo ne petas. Tiu malsimetrio estas la kialo, kial la malsukceso kutime montriĝas kiel tempolimo aŭ protokola eraro anstataŭ klara deklaro pri kapablo. Legi la agordon de unu flanko diras al vi duonon de tio, kio okazos.

Unu pruvo por finpunkto estas la normala formo, kaj tio ne estas ĉi tiu projekto. La pordego prezentas sian atestilon, la uzanto respondas per EAP, kaj ĉiu flanko aŭtentigis la alian precize unufoje. Tiuj du pruvoj venas de kontraŭaj finpunktoj, do neniu el ili diras ion apartan pri la maŝino kaj la persono, kiu uzas ĝin.

EAP-TLS estas tria formo, kaj ankaŭ tio ne estas ĉi tiu. Tie klienta atestilo prezentiĝas ene de EAP-metodo, do la kliento ankoraŭ finas unu solan IKE-aŭtentigon. La legitimiloj povas aspekti identaj al la plurraŭnda kazo, dum la protokolo portas unu raŭndon anstataŭ du. Tial projekto kopiita el EAP-TLS-starigo malsukcesas ĝuste tie, kie la dua pruvo estas atendata.

La sama dosiero legeblas alie ĉe la pordego

La sama swanctl-dosiero legeblas alie laŭ tio, kie ĝi ruliĝas, kaj tio estas la parto, kiu faligas homojn. Sur la tekkomputilo la pordego estas la kunulo, kaj sur la pordego la tekkomputilo estas, do skribu la flankon local kiel kiu mi estas kaj la flankon remote kiel kiun mi akceptos. Bloko local priskribas, kiel ĉi tiu finpunkto aŭtentigas sin, kaj bloko remote indikas, kion ĝi postulas de la alia fino. Kopii blokon inter la du dosieroj inversigas ĝian signifon sen ŝanĝi eĉ unu signon. Kompari la du dosierojn diras al vi preskaŭ nenion, ĉar la samaj vortoj signifas malajn aferojn en ĉiu el ili.

La pozicio de sekcio difinas ĝian ordon, krom se raŭnda numero superas ĝin. Tial pliaj sekcioj local aŭ remote priskribas pliajn raŭndojn kaj ne alternativojn, kaj la eksplicita raŭnda numero en swanctl.conf-referenco ekzistas ĝuste por igi tiun ordigadon intenca. Sen ĝi, movi blokon ŝanĝas la konduton. Tial ankaŭ du agordoj, kiuj surpapera aspektas egalaj, povas konduti en kontraŭa ordo.

Tiu ordiga regulo produktas la malsukcesan reĝimon, kiun valoras memori. Dua bloko remote ne estas plia akceptebla opcio; ĝi estas dua postulo, tial politiko, kiu legeblas kiel aŭ/aŭ, kondutas kiel kaj-post. Pordega politiko povas akcepti la atestilon de la enskribita maŝino kaj poste postuli la EAP-interŝanĝon de tiu uzanto, en tiu ordo.

Distingi raŭndojn de sendependaj faktoroj

Du raŭndoj ne estas aŭtomate du sendependaj faktoroj. Ripeti pruvon, aŭ teni du legitimilojn en la sama konservejo, ne donas la fortecon, kiun la projekto devintus aldoni. Sendependeco estas eco de tio, kiel la sekretoj estas tenataj kaj kio kompromitas ilin, ne de tio, kiom da interŝanĝoj la protokolo rulas. Projekto, kiu kalkulas raŭndojn kiel faktorojn, trotaksas tion, kion ĝi havas. Tiu distingo plej gravas, kiam konformeca demando demandas, kiom da faktoroj la saluto efektive uzas.

Maŝina atestilo pruvas posedon de sia akceptita ŝlosilo, kaj nenion pli. Ĝi ne estas aparatara atesto nek raporto pri saneco de aparato, do politiko, kiu bezonas statinformojn, bezonas alian mekanismon. Ankaŭ la kampo subject ne estas inventara etikedo, kiun vi povas fidi, ĉar subject elektas tiu, kiu eldonis aŭ enskribis la atestilon. Se la projekto bezonas pruvon, ke la maŝino estas sana, tiu pruvo devas veni de komponento, kiu mezuras la maŝinon.

Notu, kion ĉiu raŭndo efektive pruvas, antaŭ ol aldoni ĝin. Kiam du raŭndoj pruvas la samon dufoje, la dua aldonas latentecon kaj subtenbiletojn anstataŭ certecon. Tiu noto ankaŭ estas tio, kio haltigas diskuton pri tio, ĉu la plia raŭndo meritas sian koston.

Skribu la parigregulon kaj testu la malakceptojn

Decidu, kiuj maŝinaj identecoj rajtas pariĝi kun kiuj homoj, kaj skribu la regulon tie, kie loĝas la plenumo. Du validaj legitimiloj unu apud la alia pruvas nenion pri la pariĝo, ĉar la pariĝo estas rajtiga decido kaj ne aŭtentiga rezulto. La enskribaj rikordoj aŭ la aŭtentiga dorsistemaĵo devas plenumi la rilaton, kiun la organizo volas.

Poste testu, kio devus malsukcesi: akceptita uzanto sur neaproba maŝino, neaproba uzanto tenanta la legitimilon de la maŝino, kaj kunulo, kiu ne povas fari la plian raŭndon. Se ĉiuj tri kviete ricevas la saman aliron, la politiko priskribas intencon anstataŭ plenumi ĝin. Komparu la deklaritajn agordojn kun tio, kion la demono raportas, ĉar konekto, kiu neniam kongruis, aspektas idente al regulo, kiu trapasis:

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

Kontrolu la intertraktitajn raŭndojn kaj la rezultan rajtigon, ne nur la sukcesan saluton. Kaj ne prenu malnovajn IKEv1 XAuth-agordojn kiel fuŝsolvon: kongruigu la protokolon, la rolojn, la ordon kaj la realan konduton de la kliento anstataŭ forigi bezonatan raŭndon ĝis konekto sukcesos. Forigi la raŭndon, kiu malsukcesas, estas la maniero, kiel projekto kun du pruvoj kviete fariĝas projekto kun unu pruvo, kiun neniu reviziis. Konservu la forigon en la ŝanĝprotokolo.