Paano lumilipat ang hybrid na pagpapatotoo ng IKEv1 sa pagpapatotoo ng user sa IKEv2
Hinihiwalay ng hybrid mode ang patunay ng gateway sa patunay ng user. Pinapanatili ng paglipat sa IKEv2 ang paghihiwalay na iyon ngunit binabago ang palitan, ang paraang EAP at ang mga pagsusuri ng sertipiko.
Bawat lumang profile ng VPN na humihingi muna ng sertipiko ng server at pagkatapos ng username ay may dalawang pangyayari ng pagpapatotoo sa isang palitan, at ang hugis na iyon ay mas matagal kaysa sa protokol na nagdala nito. Ang hybrid mode ng IKEv1 ay ginawa mismo para dito: pinatutunayan ng gateway ang sarili nito sa pampublikong susi habang pinatutunayan ng user ang sarili nito mamaya sa pamamagitan ng XAuth. Ipinapahayag ng IKEv2 ang parehong dalawang-hakbang na ideya sa ibang makina, at sa mga pagkakaibang iyon nabibigo ang mga migrasyon. Walang numero ng bersyon na nagpapalit ng isa sa isa pa, at ang pagkopya ng mga lumang pangalan ng opsyon sa bagong profile ay nagbubunga ng client na nakikipagnegosasyon at pagkatapos ay walang pinatutunayang anuman.
Ano ang ginawa ng hybrid mode sa loob ng IKEv1
Sa hybrid na profile, pinipirmahan ng tumutugon na panig ang palitan ng unang yugto gamit ang sarili nitong sertipiko habang ang nagpasimula ay sadyang walang ipinapakita. Kaya't ang patunay ng pagkakakilanlan ay asimetriko, at iyon ang nagbigay-daan sa gateway na panatilihin ang umiiral na PKI habang pinapanatili ng mga user ang kanilang mga password sa direktoryo. Kapag natapos ang unang yugto, tumatakbo ang XAuth bilang isang kahilingan at tugon na nagdadala ng mga katangian ng username at password sa loob ng naka-encrypt nang channel ng ISAKMP.
Pansinin kung saan lumalapag ang pagtitiwala. Sinasagot ng sertipiko kung aling gateway ang naabot ng client; sinasagot ng XAuth kung aling user ang gustong pumasok. Walang pumapalit sa isa pa, at ang client na itinakda upang tanggapin ang anumang sertipiko ng server ay tahimik na itinapon ang unang sagot. Ginagamit din ang tatak na hybrid para sa agresibong mode na may paunang ibinahaging susi at XAuth, ibang kaayusan na may parehong karanasan ng user, kaya basahin ang profile at hindi ang pangalan. Ang parehong variant ay nagmula sa mga draft na hindi naging pamantayan, at kaya't dalawang tagagawa ay makapagpatupad ng hybrid mode at walang makipag-ugnayan sa kaninuman.
Paano naaabot ng IKEv2 ang parehong dalawang patunay
Hinahati ng IKEv2 ang gawain sa IKE_SA_INIT at IKE_AUTH. Ang unang palitan ay sumasang-ayon sa mga panukala at susi na walang anumang pagkakakilanlan; ang pangalawa ay nagdadala ng IDi, IDr at mga payload ng AUTH. Sa ilalim ng EAP, lumalabas na walang laman ang unang payload ng AUTH ng nagpasimula, nagpapatunay muna ang tumutugon na panig gamit ang sertipiko at pirma nito, at pagkatapos ay tumatakbo ang usapan ng EAP sa loob ng mga mensahe ng IKE_AUTH.
Ang mekanismong nagpapaligtas nito ay materyal ng susi. Ang matagumpay na paraang EAP ay nagluluwas ng susi ng sesyon, at ang huling payload ng AUTH ng nagpasimula ay kinakalkula mula rito, kaya't ang patunay ng user at ang mga susi ng tunel ay nakatali. Walang katumbas ang XAuth: dumarating ang mga katangian nito pagkatapos ng unang yugto at wala itong naiaambag sa mga susi. Ang puwang na iyon ang dinisenyo ng balangkas ng IKEv2 na takpan, at kaya't ang gumaganang pag-login sa IKEv2 ay nagpapatunay ng sertipiko ng server bago magtanong ng anuman.
Ang pagkakasunod-sunod na ito ay kapaki-pakinabang ding diyagnosis. Kapag nagrereklamo ang client tungkol sa mga kredensyal bago ka nito pinakitaan ng sertipiko, wala talaga itong ginagawang palitan ng EAP sa IKEv2.
Panatilihing hiwalay ang tatlong pagkakakilanlan
Nasisira ang migrasyon kapag ang tatlong pagkakakilanlan ay gumuho sa isang field. Naroon ang pagkakakilanlan ng gateway na binibigyang bisa ng client, karaniwang isang DNS name sa subject o SAN ng sertipiko. Naroon ang pagkakakilanlan ng user na inihaharap sa EAP, marahil isang login sa domain, isang address o isang tahasang string ng pagkakakilanlan ng EAP. At naroon ang pinagmumulan ng awtorisasyon na nagmamapa sa user na iyon sa mga network at ruta.
Ginagawang nakikita ng swanctl syntax ng strongSwan ang paghahati: itinatakda ng koneksyon ang remote { auth = pubkey } para sa gateway at local { auth = eap-mschapv2 } para sa user, bitbit nang hiwalay ang pagkakakilanlan ng EAP.
Kapag ang pagkakakilanlan ng user sa bagong profile ay naiiba sa mga lumang katangian ng XAuth, halimbawa isang UPN kaysa sa maikling pangalan, nakikita ng server ng pagpapatotoo ang hindi kilalang user at ang kabiguan ay mukhang maling password. Suriin ang string ng pagkakakilanlan bago suriin ang mga kredensyal.
I-map ang mga opsyon at pagkatapos asahan ang mga bitag
Maikli ang pagmamapa at bawat hilera ay may bitag na lumilitaw lamang sa oras ng pagpapatotoo.
| Legacy hybrid element | IKEv2 equivalent | Where it bites |
|---|---|---|
| Gateway certificate, no client certificate | Responder authenticated with pubkey, initiator with EAP | The server needs an EAP method configured, not just a certificate |
| XAuth username and password | EAP-MSCHAPv2 or an inner method | Password policy and account format differ from the old directory field |
| XAuth attribute replies | IKEv2 configuration payload | Attribute numbering is unrelated; nothing is renamed |
| Proxy IDs from quick mode | TS_i and TS_r in IKE_AUTH | Narrowing on the responder can leave an IKE SA with no child SA |
Wala sa mga hilerang iyon ang simpleng pagpapalit ng pangalan. Naghahatid ang payload ng konfigurasyon ng mga address at resolver sa pamamagitan ng naka-type na listahan ng katangian, samantalang ang espasyo ng katangian ng XAuth ay sarili nitong imbensyon; ang ituring silang mapagpapalit ay siyang paraan para ang isang profile ay humingi ng setting na hinding-hindi ipapadala ng gateway.
Ang mga tagapili ng trapiko ay karapat-dapat sa sarili nitong babala. Ipinahayag ng IKEv1 ang kawili-wiling trapiko sa pamamagitan ng mga proxy ID na nakatali sa palitan ng quick mode, samantalang ang IKEv2 ay nakikipagnegosasyon sa mga tagapili habang IKE_AUTH at maaaring paliitin sila ng tumutugon na panig. Ang hindi pagkakatugma ay nagbubunga ng naitatag na IKE SA na walang child SA, na masayang ipinapakita ng ilang client bilang konektado.
Ituring ang lumang koneksyon bilang isang hangganan
Idinedeklara ng RFC 9395 na lipas na ang IKEv1, kaya't ang lumang hybrid na koneksyon ay hangganan ng pagkakatugma na may petsa, hindi pundasyon. Patakbuhin ang dalawang profile nang magkatabi habang nagbabago, dahil ang mahalagang pagsubok ay hindi kung bubukas ang bagong profile kundi kung ang parehong user sa parehong aparato ay umabot sa parehong mga mapagkukunan.
Panatilihing mahigpit ang pagpapatunay ng sertipiko sa buong proseso. Kapag huminto ang client sa paghaharap ng sarili nitong sertipiko, ang tukso ay luwagan ang pagsusuri ng server hanggang matapos ang pakikipagkamay, at ipinagpapalit niyon ang tanging natitirang patunay sa isang berdeng icon.
Isulat ang apat na bagay bago retiradohin ang lumang profile: ang paraang EAP, ang string ng pagkakakilanlan, ang pinagmumulan ng awtorisasyon at ang petsang nagtatapos ang suporta.