Dvi tapatybės viename IKEv2 prisijungime: pirma mašina, paskui naudotojas

Kliento sertifikatas patvirtinamas, pirmasis mainas baigiamas, ir tada ryšys sustoja su klaida apie papildomą autentifikavimo etapą. Sertifikatų grandinėje niekas neteisinga ir tinkle niekas nepasikeitė. Šliuzas sukonfigūruotas reikalauti antrojo įrodymo iš jungiančiosios pusės, o klientas jo niekada neatsiunčia. Nuspręsti, kas ką įrodo ir kokia tvarka, yra visas darbas, ir jis prasideda skaitant politiką iš to galinio taško, kuriame stovite. Du skirtingų rūšių įrodymai fiksuota tvarka yra projektinis sprendimas, o ne žymimasis langelis.

Simptomas: nesėkmė po sėkmingo pirmojo įrodymo

Pirmasis mainas baigiasi ir žurnalas atrodo sveikas, kol šliuzas paprašo naudotojo tapatybės per EAP. Tada rankos paspaudimas sustoja arba grąžinama protokolo klaida, įvardijanti papildomą etapą. Visiškai galiojantis mašinos sertifikatas atmetamas dėl priežasties, neturinčios nieko bendra su jo galiojimu. Politika prašė antrojo įrodymo, o kliento atsakymas taip ir neatėjo.

Abu tos nesėkmės aprašymai yra tikslūs priklausomai nuo to, kur stovite. Iš kliento pusės tai atrodo kaip serveris, atmetantis galiojantį sertifikatą, o iš serverio pusės — kaip klientas, negalintis užbaigti prisijungimo. Tas pats įvykis viename žurnale skaitomas kaip pasitikėjimo problema, o kitame — kaip galimybių problema. Tik sukonfigūruota politika pasako, kuri iš jų.

Ką plėtinys prideda ir ko ne

IKEv2 turi plėtinį, leidžiantį vienoje sesijoje atlikti daugiau nei vieną autentifikavimo mainą. RFC 4739 aprašo, be kitų sekų, klientą, kuris įrodo sertifikato tapatybę ir tada per EAP autentifikuoja asmenį. Dokumento būsena yra Experimental, o tai reiškia, kad jokia implementacija jums šios funkcijos neskolinga. Nekelkite jokių prielaidų apie palaikymą, kol partneris dėl jo nesusitars.

Abi pusės turi palaikyti plėtinį ir susitarti dėl jo mainų metu. Šliuzas, sukonfigūruotas antram etapui, negali priversti kliento jo atlikti, o jį palaikantis klientas juo nesinaudos, jei serveris neprašys. Būtent ši asimetrija yra priežastis, kodėl nesėkmė paprastai pasireiškia kaip laiko limitas arba protokolo klaida, o ne kaip aiškus pareiškimas apie galimybes. Vienos pusės konfigūracijos perskaitymas pasako pusę to, kas nutiks.

Vienas įrodymas vienam galiniam taškui yra įprasta forma, ir tai ne tas projektas. Šliuzas pateikia savo sertifikatą, naudotojas atsako per EAP, ir kiekviena pusė tiksliai vieną kartą autentifikavo kitą. Tie du įrodymai ateina iš priešingų galinių taškų, todėl nė vienas atskirai nieko nesako apie mašiną ir žmogų, kuris ja naudojasi.

EAP-TLS yra trečioji forma, ir ji taip pat ne ši. Ten kliento sertifikatas pateikiamas EAP metodo viduje, todėl klientas vis tiek atlieka vieną IKE autentifikavimą. Kredencialai gali atrodyti identiški kelių etapų atvejui, nors protokolas neša vieną etapą vietoj dviejų. Todėl projektas, nukopijuotas iš EAP-TLS diegimo, žlunga būtent ten, kur tikimasi antrojo įrodymo.

Tas pats failas šliuze skaitomas kitaip

Tas pats swanctl failas skaitomas kitaip priklausomai nuo to, kur jis vykdomas, ir būtent tai kliudo žmonėms. Nešiojamajame kompiuteryje šliuzas yra partneris, o šliuze partneris yra nešiojamasis kompiuteris, todėl local pusę rašykite kaip kas aš esu, o remote pusę kaip ką priimsiu. local blokas aprašo, kaip šis galinis taškas autentifikuoja save, o remote blokas nurodo, ko jis reikalauja iš kito galo. Bloko kopijavimas tarp dviejų failų apverčia jo reikšmę nepakeitus nė vieno ženklo. Dviejų failų palyginimas beveik nieko nesako, nes tie patys žodžiai kiekviename reiškia priešingus dalykus.

Skyriaus vieta nustato jo tvarką, nebent ją viršytų etapo numeris. Todėl papildomi local arba remote skyriai aprašo papildomus etapus, o ne alternatyvas, ir aiškus etapo numeris swanctl.conf nuorodoje egzistuoja būtent tam, kad ta tvarka būtų sąmoninga. Be jo bloko perkėlimas keičia elgesį. Todėl dvi konfigūracijos, kurios popieriuje atrodo lygiavertės, gali veikti priešinga tvarka.

Ši tvarkos taisyklė sukuria nesėkmės būdą, kurį verta įsiminti. Antrasis remote blokas nėra dar viena priimtina galimybė; tai antrasis reikalavimas, todėl politika, skaitoma kaip arba/arba, elgiasi kaip ir-tada. Šliuzo politika gali priimti registruotos mašinos sertifikatą ir tada pareikalauti to naudotojo EAP maino, būtent ta tvarka.

Atskirkite etapus nuo nepriklausomų veiksnių

Du etapai nėra automatiškai du nepriklausomi veiksniai. Įrodymo kartojimas arba dviejų kredencialų laikymas toje pačioje saugykloje neduoda stiprumo, kurį projektas turėjo pridėti. Nepriklausomumas yra savybė to, kaip saugomi paslaptys ir kas jas kompromituoja, o ne to, kiek mainų atlieka protokolas. Projektas, skaičiuojantis etapus kaip veiksnius, pervertina tai, ką turi. Šis skirtumas svarbiausias tada, kai atitikties klausimas klausia, kiek veiksnių prisijungimas iš tikrųjų naudoja.

Mašinos sertifikatas įrodo savo priimto rakto valdymą ir nieko daugiau. Tai nėra aparatūros atestacija ir ne įrenginio sveikatos ataskaita, todėl politikai, kuriai reikia būsenos informacijos, reikia kito mechanizmo. subject laukas taip pat nėra patikima inventorizacijos žymė, nes subject pasirenka tas, kas sertifikatą išdavė arba užregistravo. Jei projektui reikia įrodymo, kad mašina sveika, tas įrodymas turi ateiti iš komponento, kuris mašiną matuoja.

Užsirašykite, ką kiekvienas etapas iš tikrųjų įrodo, prieš jį pridėdami. Kai du etapai tą patį įrodo du kartus, antrasis prideda delsą ir palaikymo bilietus, o ne užtikrinimą. Ta pastaba taip pat sustabdo ginčą, ar papildomas etapas vertas savo kainos.

Parašykite poravimo taisyklę ir išbandykite atsisakymus

Nuspręskite, kurios mašinų tapatybės gali būti poruojamos su kuriais žmonėmis, ir parašykite taisyklę ten, kur gyvena vykdymas. Du galiojantys kredencialai greta vienas kito nieko neįrodo apie poravimą, nes poravimas yra autorizacijos sprendimas, o ne autentifikavimo rezultatas. Registracijos įrašai arba autentifikavimo backend turi užtikrinti santykį, kurio nori organizacija.

Tada išbandykite, kas turėtų žlugti: priimtas naudotojas nepatvirtintoje mašinoje, nepatvirtintas naudotojas su mašinos kredencialu ir partneris, negalintis atlikti papildomo etapo. Jei visi trys tyliai gauna tą pačią prieigą, politika aprašo ketinimą, o ne jį vykdo. Palyginkite deklaruotą konfigūraciją su tuo, ką praneša demonas, nes ryšys, kuris niekada nesutapo, atrodo identiškai kaip taisyklė, kuri praėjo:

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

Tikrinkite suderėtus etapus ir iš to kylančią autorizaciją, o ne tik sėkmingą prisijungimą. Ir nesiekite senų IKEv1 XAuth nustatymų kaip trumpiausio kelio: suderinkite protokolą, vaidmenis, tvarką ir tikrąjį kliento elgesį, o ne trinkite reikalingą etapą, kol ryšys pavyks. Nesėkmingo etapo trynimas yra būdas, kuriuo projektas su dviem įrodymais tyliai tampa projektu su vienu įrodymu, kurio niekas neperžiūrėjo. Palikite trynimą pakeitimų žurnale.