Dy identitete në një hyrje IKEv2: makina, pastaj përdoruesi

Një certifikatë klienti vërtetohet, shkëmbimi i parë përfundon dhe më pas lidhja ndalon me një gabim rreth një raundi shtesë vërtetimi. Asgjë në zinxhirin e certifikatave nuk është e gabuar dhe asgjë në rrjet nuk ka ndryshuar. Porta është konfiguruar të kërkojë një provë të dytë nga ana lidhëse, dhe klienti nuk dërgon kurrë një të tillë. Të vendosësh kush provon çfarë, në çfarë radhe, është e gjithë detyra, dhe fillon duke lexuar politikën nga pika ku ndodheni. Dy prova të llojeve të ndryshme, në një radhë fikse, është një vendim dizajni dhe jo një kuti kontrolli.

Simptoma: dështim pas një prove të parë të suksesshme

Shkëmbimi i parë përfundon dhe regjistri duket i shëndetshëm, derisa porta kërkon një identitet përdoruesi përmes EAP. Dorëzimi më pas ngec ose kthen një gabim protokolli që përmend raundin shtesë. Një certifikatë makine krejtësisht e vlefshme refuzohet për një arsye që nuk ka të bëjë me vlefshmërinë e saj. Politika kërkoi një provë të dytë, dhe përgjigjja e klientit nuk mbërriti kurrë.

Të dy përshkrimet e atij dështimi janë të sakta, varësisht nga ku ndodheni. Nga ana e klientit duket si një server që refuzon një certifikatë të vlefshme, dhe nga ana e serverit duket si një klient që nuk arrin ta përfundojë hyrjen. I njëjti ngjarje lexohet si problem besimi në një regjistër dhe si problem aftësie në tjetrin. Vetëm politika e konfiguruar ju tregon se cila është.

Çfarë shton shtojca, dhe çfarë nuk shton

IKEv2 mbart një shtojcë për të ekzekutuar më shumë se një shkëmbim vërtetimi brenda një sesioni të vetëm. RFC 4739 skicon, ndër sekuenca të tjera, një klient që provon një identitet certifikate dhe pastaj vërteton një person përmes EAP. Dokumenti është Eksperimental, që do të thotë se asnjë implementim nuk ju detyrohet ta ketë veçorinë. Mos supozoni asgjë për mbështetjen derisa pala tjetër ta negociojë atë.

Të dyja palët duhet ta mbështesin shtojcën dhe të bien dakord për të gjatë shkëmbimit. Një portë e konfiguruar për një raund të dytë nuk mund ta detyrojë një klient ta kryejë atë, dhe një klient që e mbështet nuk do ta përdorë nëse serveri nuk e kërkon. Kjo asimetri është arsyeja pse dështimi zakonisht shfaqet si një afat i skaduar ose një gabim protokolli, në vend të një deklarate të qartë për aftësinë. Leximi i konfigurimit të njërës palë ju tregon gjysmën e asaj që do të ndodhë.

Një provë për pikë fundore është forma normale, dhe nuk është ky dizajn. Porta paraqet certifikatën e saj, përdoruesi përgjigjet me EAP, dhe secila palë ka vërtetuar tjetrën saktësisht një herë. Këto dy prova vijnë nga pika fundore të kundërta, prandaj asnjëra nuk thotë diçka të veçantë për makinën dhe personin që e përdor atë.

EAP-TLS është një formë e tretë, dhe as kjo nuk është kjo. Atje një certifikatë klienti paraqitet brenda një metode EAP, kështu që klienti përsëri kryen një vërtetim të vetëm IKE. Kredencialet mund të duken identike me rastin e shumë raundeve, ndërsa protokolli mbart një raund në vend të dy. Kjo është arsyeja pse një dizajn i kopjuar nga një vendosje EAP-TLS dështon pikërisht aty ku pritet prova e dytë.

I njëjti skedar lexohet ndryshe në portë

I njëjti skedar swanctl lexohet ndryshe varësisht nga ku ekzekutohet, dhe kjo është pjesa që i ngatërron njerëzit. Në laptop portë është pala tjetër, dhe në portë laptopi është, prandaj shkruani anën lokale si kush jam unë dhe anën remote si kë do të pranoj. Një bllok lokal përshkruan se si kjo pikë fundore vërteton vetveten, dhe një bllok remote deklaron atë që kërkon nga ana tjetër. Kopjimi i një blloku midis dy skedarëve e përmbys kuptimin e tij pa ndryshuar asnjë karakter të vetëm. Krahasimi i dy skedarëve nuk ju tregon pothuajse asgjë, sepse të njëjtat fjalë kanë kuptime të kundërta në secilin.

Pozicioni i një seksioni përcakton radhën e tij, përveç kur një numër raundi e anulon atë. Seksionet shtesë lokale ose remote përshkruajnë pra raunde shtesë dhe jo alternativa, dhe numri i qartë i raundit në referencën e swanctl.conf ekziston pikërisht për ta bërë atë renditje të qëllimshme. Pa të, lëvizja e një blloku ndryshon sjelljen. Kjo është edhe arsyeja pse dy konfigurime që duken ekuivalente në letër mund të sillen në radhë të kundërta.

Ky rregull radhitjeje prodhon mënyrën e dështimit që ia vlen të mbahet mend. Një bllok i dytë remote nuk është një opsion tjetër i pranueshëm; është një kërkesë e dytë, prandaj një politikë që lexohet si ose/ose sillet si dhe-pastaj. Një politikë porte mund të pranojë certifikatën e makinës së regjistruar dhe pastaj të kërkojë shkëmbimin EAP të atij përdoruesi, në atë radhë.

Bëni dallimin midis raundeve dhe faktorëve të pavarur

Dy raunde nuk janë automatikisht dy faktorë të pavarur. Përsëritja e një prove, ose mbajtja e dy kredencialeve në të njëjtën depo, nuk e japin forcën që dizajni duhej të shtonte. Pavarësia është veti e mënyrës se si mbahen sekretet dhe e asaj që i kompromiton ato, jo e numrit të shkëmbimeve që ekzekuton protokolli. Një dizajn që numëron raundet si faktorë e mbivlerëson atë që ka. Ky dallim ka më shumë rëndësi kur një pyetje përputhshmërie pyet sa faktorë përdor në të vërtetë hyrja.

Një certifikatë makine provon posedimin e çelësit të saj të pranuar, dhe asgjë më shumë. Nuk është një attestim harduerik dhe as një raport shëndeti pajisjeje, prandaj një politikë që kërkon informacion gjendjeje kërkon një mekanizëm tjetër. As fusha subject nuk është një etiketë inventari në të cilën mund të kesh besim, sepse subject zgjidhet nga kushdo që lëshoi ose regjistroi certifikatën. Nëse dizajni ka nevojë për provë se makina është e shëndetshme, ajo provë duhet të vijë nga një komponent që mat makinën.

Shkruani çfarë provon në të vërtetë secili raund para se ta shtoni. Kur dy raunde provojnë të njëjtën gjë dy herë, i dyti shton vonesë dhe bileta mbështetjeje në vend të sigurisë. Ky shënim është gjithashtu ai që ndal një debat nëse raundi shtesë ia vlen koston.

Shkruani rregullin e çiftimit dhe provoni refuzimet

Vendosni cilat identitete makine mund të çiftohen me cilët njerëz, dhe shkruani rregullin aty ku ndodhet zbatimi. Dy kredenciale të vlefshme krah për krah nuk provojnë asgjë për çiftimin, sepse çiftimi është një vendim autorizimi dhe jo një rezultat vërtetimi. Regjistrat e regjistrimit ose backend-i i vërtetimit duhet të zbatojnë marrëdhënien që organizata dëshiron.

Pastaj provoni çfarë duhet të dështojë: një përdorues i pranuar në një makinë të papranuar, një përdorues i papranuar që mban kredencialin e makinës, dhe një palë që nuk mund ta kryejë raundin shtesë. Nëse të tre marrin në heshtje të njëjtën qasje, politika përshkruan një qëllim në vend që ta zbatojë atë. Krahasoni konfigurimin e deklaruar me atë që raporton daemon-i, sepse një lidhje që nuk u përputh kurrë duket identike me një rregull që kaloi:

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

Kontrolloni raundet e negociuara dhe autorizimin që rezulton, jo vetëm hyrjen e suksesshme. Dhe mos u mbështetni te cilësimet e vjetra XAuth të IKEv1 si shkurtore: përputhni protokollin, rolet, radhën dhe sjelljen reale të klientit, në vend që të fshini një raund të kërkuar derisa një lidhje të funksionojë. Fshirja e raundit që dështon është mënyra se si një dizajn me dy prova kthehet në heshtje në një dizajn me një provë që askush nuk e shqyrtoi. Mbajeni fshirjen në regjistrin e ndryshimeve.