Dalawang pagkakakilanlan sa isang IKEv2 login: makina, tapos user

Ang sertipiko ng kliyente ay naberipika, natapos ang unang palitan, at pagkatapos huminto ang koneksyon na may error tungkol sa karagdagang pag-ikot ng pagpapatunay. Walang mali sa kadena ng sertipiko at walang nagbago sa network. Ang gateway ay na-configure na humingi ng ikalawang patunay mula sa panig na kumokonekta, at ang kliyente ay hindi kailanman nagpapadala nito. Ang pagpapasya kung sino ang nagpapatunay ng ano, sa aling pagkakasunod-sunod, ay ang buong gawain, at nagsisimula ito sa pagbasa ng patakaran mula sa endpoint kung saan ka nakatayo. Dalawang patunay ng magkaibang uri, sa isang takdang pagkakasunod-sunod, ay isang desisyon sa disenyo at hindi isang checkbox.

Ang sintomas: pagpalya pagkatapos ng matagumpay na unang patunay

Natapos ang unang palitan at mukhang maayos ang log, hanggang sa humingi ang gateway ng pagkakakilanlan ng user sa pamamagitan ng EAP. Pagkatapos ay tumitigil ang handshake o nagbabalik ng error sa protocol na tumutukoy sa karagdagang pag-ikot. Ang isang ganap na wastong sertipiko ng makina ay tinatanggihan dahil sa dahilang walang kaugnayan sa bisa nito. Humingi ng ikalawang patunay ang patakaran, at hindi kailanman dumating ang sagot ng kliyente.

Ang dalawang paglalarawan ng pagpalyang iyon ay tama depende sa kinatatayuan mo. Mula sa panig ng kliyente ay mukhang server na tumatanggi sa wastong sertipiko, at mula sa panig ng server ay mukhang kliyenteng hindi makatapos ng login. Ang parehong pangyayari ay binabasa bilang problema sa pagtitiwala sa isang log at problema sa kakayahan sa isa pa. Tanging ang naka-configure na patakaran ang nagsasabi kung alin ito.

Ano ang idinadagdag ng extension, at ano ang hindi

May dalang extension ang IKEv2 para sa pagpapatakbo ng mahigit isang palitan ng pagpapatunay sa loob ng isang session. Binabalangkas ng RFC 4739, kasama ng iba pang pagkakasunod-sunod, ang isang kliyenteng nagpapatunay ng pagkakakilanlan ng sertipiko at pagkatapos ay nagpapatunay ng isang tao sa pamamagitan ng EAP. Ang dokumento ay Eksperimental, na nangangahulugang walang implementasyon ang may utang sa iyo ng feature. Huwag magpalagay ng anuman tungkol sa suporta hanggang sa makipagkasundo ang kapares dito.

Dapat suportahan ng magkabilang panig ang extension at sumang-ayon dito sa panahon ng palitan. Ang gateway na naka-configure para sa ikalawang pag-ikot ay hindi mapipilit ang kliyente na gawin ito, at ang kliyenteng sumusuporta dito ay hindi ito gagamitin maliban kung hihilingin ng server. Ang kawalan ng simetrya na iyon ang dahilan kung bakit kadalasang lumalabas ang pagpalya bilang timeout o error sa protocol sa halip na malinaw na pahayag tungkol sa kakayahan. Ang pagbasa ng configuration ng isang panig ay nagsasabi sa iyo ng kalahati ng mangyayari.

Isang patunay bawat endpoint ang normal na hugis, at hindi ito ang disenyong ito. Ipinapakita ng gateway ang sertipiko nito, sumasagot ang user sa EAP, at ang bawat panig ay nagpapatunay sa isa pa nang eksaktong isang beses. Nagmumula ang dalawang patunay na iyon sa magkasalungat na endpoint, kaya wala sa kanila ang nagsasabi ng anumang hiwalay tungkol sa makina at sa taong gumagamit nito.

Ang EAP-TLS ay isang ikatlong hugis, at hindi rin ito ang isang ito. Doon, ang sertipiko ng kliyente ay ipinapakita sa loob ng isang paraan ng EAP, kaya ang kliyente ay gumagawa pa rin ng isang pagpapatunay ng IKE. Maaaring magmukhang magkapareho ang mga kredensyal sa kaso ng maraming pag-ikot habang ang protocol ay may dalang isang pag-ikot sa halip na dalawa. Iyon ang dahilan kung bakit ang disenyong kinopya mula sa isang deployment ng EAP-TLS ay pumapalya sa puntong inaasahan ang ikalawang patunay.

Iba ang pagbasa sa parehong file sa gateway

Iba ang pagbasa sa parehong file ng swanctl depende sa kung saan ito tumatakbo, at iyon ang bahaging nagpapalito sa mga tao. Sa laptop ang gateway ang kapares, at sa gateway ang laptop naman, kaya isulat ang panig na local bilang kung sino ako at ang panig na remote bilang kung sino ang tatanggapin ko. Inilalarawan ng bloke na local kung paano nagpapatunay ang endpoint na ito sa sarili nito, at isinasaad ng bloke na remote kung ano ang hinihingi nito mula sa kabilang dulo. Binabaliktad ng pagkopya ng bloke sa pagitan ng dalawang file ang kahulugan nito nang walang binabago kahit isang karakter. Halos walang sinasabi ang paghahambing ng dalawang file, dahil ang parehong mga salita ay may magkasalungat na kahulugan sa bawat isa.

Ang posisyon ng isang seksyon ay nagtatakda ng pagkakasunod-sunod nito maliban kung mapapawalang-bisa ito ng numero ng pag-ikot. Ang mga karagdagang seksyong local o remote ay naglalarawan kaya ng mga karagdagang pag-ikot sa halip na mga alternatibo, at ang tahasang numero ng pag-ikot sa sanggunian ng swanctl.conf ay umiiral nang eksakto upang gawing sinasadya ang pagkakasunod-sunod na iyon. Kung wala ito, binabago ng paglipat ng bloke ang pag-uugali. Iyon din ang dahilan kung bakit ang dalawang configuration na mukhang pantay sa papel ay maaaring kumilos sa magkasalungat na pagkakasunod-sunod.

Ang tuntuning iyon sa pagkakasunod-sunod ay gumagawa ng mode ng pagpalya na dapat tandaan. Ang ikalawang bloke na remote ay hindi isa pang katanggap-tanggap na opsyon; ito ay ikalawang kahilingan, kaya ang patakarang binabasa na parang alinman/o ay kumikilos na at-pagkatapos. Maaaring tanggapin ng patakaran ng gateway ang sertipiko ng naka-enroll na makina at pagkatapos ay hingin ang palitan ng EAP ng user na iyon, sa ganoong pagkakasunod-sunod.

Ibahin ang mga pag-ikot sa mga malayang salik

Ang dalawang pag-ikot ay hindi awtomatikong dalawang malayang salik. Ang pag-uulit ng isang patunay, o paghawak ng dalawang kredensyal sa isang tindahan, ay hindi nagbibigay ng lakas na dapat idinagdag ng disenyo. Ang kalayaan ay katangian ng kung paano hinahawakan ang mga lihim at kung ano ang nagsasapanganib sa mga ito, hindi ng kung gaano karaming palitan ang pinapatakbo ng protocol. Ang disenyong nagbibilang ng mga pag-ikot bilang mga salik ay nagpapalabis sa kung ano ang mayroon ito. Ang pagkakaibang iyon ay pinakamahalaga kapag tinanong ng isang tanong sa pagsunod kung gaano karaming salik ang aktuwal na ginagamit ng login.

Pinatutunayan ng sertipiko ng makina ang pagmamay-ari ng tinanggap nitong susi, at wala nang iba. Hindi ito isang attestation ng hardware at hindi isang ulat ng kalusugan ng device, kaya ang patakarang nangangailangan ng impormasyon sa kalagayan ay nangangailangan ng ibang mekanismo. Hindi rin ang field na subject ay isang tag ng imbentaryo na maaari mong pagkatiwalaan, dahil ang subject ay pinipili ng sinumang nag-isyu o nag-enroll ng sertipiko. Kung kailangan ng disenyo ng patunay na malusog ang makina, ang patunay na iyon ay dapat magmula sa isang bahaging sumusukat sa makina.

Isulat kung ano talaga ang pinatutunayan ng bawat pag-ikot bago ito idagdag. Kapag ang dalawang pag-ikot ay nagpapatunay ng parehong bagay nang dalawang beses, ang pangalawa ay nagdaragdag ng latency at mga tiket sa suporta sa halip na katiyakan. Ang tala na iyon din ang pumipigil sa pagtatalo tungkol sa kung sulit ang dagdag na pag-ikot sa gastos nito.

Isulat ang tuntunin ng pagpapares at subukan ang mga pagtanggi

Magpasya kung aling mga pagkakakilanlan ng makina ang maaaring ipares sa aling mga tao, at isulat ang tuntunin kung saan naroon ang pagpapatupad. Ang dalawang wastong kredensyal na magkatabi ay walang pinatutunayang anuman tungkol sa pagpapares, dahil ang pagpapares ay isang desisyon sa awtorisasyon at hindi resulta ng pagpapatunay. Dapat ipatupad ng mga talaan ng enrollment o ng backend ng pagpapatunay ang ugnayang gusto ng organisasyon.

Pagkatapos subukan ang dapat pumalya: isang tinanggap na user sa isang hindi aprubadong makina, isang hindi aprubadong user na may hawak ng kredensyal ng makina, at isang kapares na hindi kayang gawin ang karagdagang pag-ikot. Kung tahimik na natatanggap ng tatlo ang parehong access, inilalarawan ng patakaran ang isang layunin sa halip na ipatupad ito. Ihambing ang ipinahayag na configuration sa iniuulat ng daemon, dahil ang koneksyong hindi kailanman tumugma ay mukhang katulad ng tuntuning pumasa:

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

Suriin ang napagkasunduang mga pag-ikot at ang resultang awtorisasyon, hindi lamang ang matagumpay na login. At huwag kunin ang mga lumang setting ng XAuth ng IKEv1 bilang shortcut: itugma ang protocol, ang mga papel, ang pagkakasunod-sunod at ang tunay na pag-uugali ng kliyente sa halip na burahin ang kinakailangang pag-ikot hanggang magtagumpay ang koneksyon. Ang pagbura ng pag-ikot na pumapalya ay kung paano tahimik na nagiging isang disenyong may isang patunay ang isang disenyong may dalawang patunay na walang sinumang nagsuri. Panatilihin ang pagbura sa talaan ng pagbabago.