IKEv1-ийн хосолмол баталгаажуулалт IKEv2-ийн хэрэглэгчийн баталгаажуулалт руу хэрхэн шилждэг
Хосолмол горим гарцын нотолгоог хэрэглэгчийн нотолгооноос тусгаарладаг байв. IKEv2 руу шилжих нь тэр тусгаарлалтыг хадгалдаг ч солилцоо, EAP арга, сертификатын шалгалтыг өөрчилдөг.
Серверийн сертификат, дараа нь хэрэглэгчийн нэрийг шаарддаг хуучин VPN профайл бүр нэг солилцоонд хоёр баталгаажуулалтын үйл явдлыг агуулдаг бөгөөд энэ хэлбэр нь түүнийг бий болгосон протоколоос урт насалдаг. IKEv1-ийн хосолмол горим яг үүний төлөө бүтээгдсэн: гарц өөрийгөө нийтийн түлхүүрээр нотолж, хэрэглэгч өөрийгөө дараа нь XAuth-аар нотолдог. IKEv2 мөн тэр хоёр шатлалт санааг өөр механизмаар илэрхийлдэг бөгөөд шилжилт яг эдгээр ялгаан дээр бүтэлгүйтдэг. Ямар ч хувилбарын дугаар нэгийг нөгөө болгон хувиргадаггүй бөгөөд хуучин сонголтын нэрийг шинэ профайлд хуулах нь тохиролцоод дараа нь юу ч баталгаажуулдаггүй клиентийг өгдөг.
Хосолмол горим IKEv1 дотор юу хийдэг байв
Хосолмол профайлд хариулагч эхний фазын солилцоог өөрийн сертификатаар гарын үсэг зурдаг бол санаачлагч зориуд юу ч үзүүлэхгүй. Тиймээс хувь хүний нотолгоо тэгш бус бөгөөд энэ нь гарцад одоо байгаа PKI-г хадгалж, хэрэглэгчдэд каталогийн нууц үгээ хадгалах боломж олгосон. Эхний фаз дууссаны дараа XAuth одоо шифрлэгдсэн ISAKMP сувгийн дотор хэрэглэгчийн нэр, нууц үгийн шинж чанарыг агуулсан хүсэлт ба хариу хэлбэрээр ажилладаг.
Итгэл хаана буухыг анхаарна уу. Сертификат нь клиент аль гарцад хүрснийг хариулна; XAuth нь аль хэрэглэгч нэвтрэхийг хүсч байгааг хариулна. Аль нь нөгөөгөө орлохгүй бөгөөд ямар ч серверийн сертификатыг хүлээн авахаар тохируулсан клиент эхний хариуг чимээгүй хаясан байна. Хосолмол гэсэн шошгыг мөн урьдчилан хуваалцсан түлхүүр нэмэх XAuth бүхий түрэмгий горимд хэрэглэдэг, ижил хэрэглэгчийн туршлагатай өөр зохион байгуулалт тул нэрийг биш профайлыг уншина уу. Хоёр хувилбар нь хэзээ ч стандарт болоогүй төслүүдээс гаралтай тул хоёр үйлдвэрлэгч хосолмол горимыг хэрэгжүүлээд хэнтэй ч харилцан ажиллахгүй байж болно.
IKEv2 мөн тэр хоёр нотолгоонд хэрхэн хүрдэг
IKEv2 ажлыг IKE_SA_INIT ба IKE_AUTH хооронд хуваадаг. Эхний солилцоо ямар ч хувь хүнгүйгээр санал, түлхүүрийг тохиролцдог; хоёр дахь нь IDi, IDr болон AUTH ачааг зөөдөг. EAP-ийн дор санаачлагчийн эхний AUTH ачаа хоосон гарч, хариулагч эхлээд өөрийн сертификат, гарын үсгээр баталгаажиж, дараа нь EAP яриа IKE_AUTH мессежүүдийн дотор үргэлжилдэг.
Үүнийг аюулгүй болгодог механизм нь түлхүүрийн материал юм. Амжилттай EAP арга сессийн түлхүүрийг экспортолдог бөгөөд санаачлагчийн эцсийн AUTH ачаа түүнээс тооцогддог тул хэрэглэгчийн нотолгоо ба туннелийн түлхүүрүүд холбогддог. XAuth-д ийм дүйцэл байхгүй: түүний шинж чанарууд эхний фазын дараа ирж, түлхүүрт юу ч нэмдэггүй. Яг энэ цоорхойг IKEv2-ийн хүрээ хаах зорилготой байсан бөгөөд тиймээс ажилладаг IKEv2 нэвтрэлт ямар нэгэн зүйл асуухаасаа өмнө серверийн сертификатыг шалгадаг.
Энэ дараалал нь бас ашигтай оношлогоо юм. Клиент танд сертификат үзүүлээгүй байхад нэвтрэх мэдээллийн талаар гомдоллож байвал тэр огт IKEv2 EAP солилцоо хийхгүй байна.
Гурван хувь хүнийг тусдаа бариарай
Гурван хувь хүн нэг талбарт нийлэхэд шилжилт буруу болдог. Клиентийн шалгадаг гарцын хувь хүн байна, ихэвчлэн сертификатын subject эсвэл SAN дахь DNS нэр. EAP-д танилцуулагдах хэрэглэгчийн хувь хүн байна, магадгүй домэйн нэвтрэлт, хаяг эсвэл тодорхой EAP хувь хүний мөр. Мөн тэр хэрэглэгчийг сүлжээ, маршруттай холбодог эрх олголтын эх сурвалж байна.
strongSwan-ы swanctl синтакс тусгаарлалтыг харагдахуйц болгодог: холболт гарцад remote { auth = pubkey }, хэрэглэгчид local { auth = eap-mschapv2 } тавьдаг бөгөөд EAP хувь хүн тусдаа зөөгддөг.
Шинэ профайл дахь хэрэглэгчийн хувь хүн хуучин XAuth шинж чанаруудаас ялгаатай бол, жишээ нь богино нэрийн оронд UPN, баталгаажуулалтын сервер үл мэдэгдэх хэрэглэгчийг харж, алдаа нь буруу нууц үг мэт харагдана. Нэвтрэх мэдээллийг шалгахаасаа өмнө хувь хүний мөрийг шалгаарай.
Сонголтуудыг зураглан, дараа нь урхинуудыг хүлээнэ үү
Зураглал богино бөгөөд мөр бүрт зөвхөн баталгаажуулалтын үед илэрдэг урхи байдаг.
| 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 |
Тэдгээр мөрүүдийн аль нь ч энгийн нэр солих биш. Конфигурацийн ачаа хаяг, резолверыг төрөлжсөн шинж чанарын жагсаалтаар хүргэдэг бол XAuth-ийн шинж чанарын орон зай өөрийн зохиомж байв; тэдгээрийг солилцох боломжтой гэж үзэх нь профайл гарцаас хэзээ ч илгээхгүй тохиргоог шаардаж эхлэх зам юм.
Трафикийн сонгогчид өөрийн анхааруулга хүртэх ёстой. IKEv1 сонирхолтой трафикийг quick mode солилцоонд уясан proxy ID-ээр илэрхийлдэг байсан бол IKEv2 сонгогчдыг IKE_AUTH-ийн үеэр тохиролцож, хариулагч тэдгээрийг нарийсгаж болно. Зөрүү нь child SA-гүй тогтоосон IKE SA үүсгэдэг бөгөөд зарим клиент үүнийг баяртайгаар холбогдсон гэж харуулдаг.
Хуучин холболтыг хил хязгаар гэж үзээрэй
RFC 9395 IKEv1-ийг хуучирсан гэж зарладаг тул хуучин хосолмол холболт нь огноотой нийцлийн хил бөгөөд суурь биш юм. Өөрчлөлтийн үеэр хоёр профайлыг зэрэгцүүлэн ажиллуулаарай, учир нь чухал шалгалт нь шинэ профайл босох эсэх биш, харин ижил хэрэглэгч ижил төхөөрөмж дээр ижил нөөцөд хүрэх эсэх юм.
Сертификатын шалгалтыг эцэс хүртэл хатуу бариарай. Клиент өөрийн сертификатыг үзүүлэхээ болиход handshake дуустал серверийн шалгалтыг сулруулах уруу таталт үүсдэг бөгөөд энэ нь үлдсэн цорын ганц нотолгоог ногоон дүрсээр солидог.
Хуучин профайлыг хасахаас өмнө дөрвөн зүйлийг бичээрэй: EAP арга, хувь хүний мөр, эрх олголтын эх сурвалж, дэмжлэг дуусах огноо.