د 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 پر مهال خبرې کوي او ځواب ورکوونکی یې تنګولای شي. ناسم والی یو جوړ شوی IKE SA بې child SA جوړوي، چې ځینې کلاینټان په خوښۍ سره تړلی ښیي.
پخوانۍ اړیکه د یوې پولې په توګه وګورئ
RFC 9395 د IKEv1 پروتوکول زوړ اعلان کړ، نو پخوانۍ هایبرډ اړیکه د نیټې سره د مطابقت پوله ده، بنسټ نه. د بدلون پر مهال دواړه پروفایل څنګ په څنګ چل کړئ، ځکه مهم ازموینه دا نه ده چې نوی پروفایل پورته کیږي، بلکې دا ده چې هماغه کارن په هماغه وسیله هماغو سرچینو ته رسیږي.
د سند تصدیق تر پایه سخت وساتئ. کله چې کلاینټ خپل سند وړاندې کول پرېږدي، هغه هڅه پیدا کیږي چې د سرور کتنه نرمه کړئ تر څو لاس ورکول بشپړ شي، او دا یوازینی پاتې ثبوت په شین نښان بدلوي.
له پخواني پروفایل تقاعد مخکې څلور شیان ولیکئ: EAP طریقه، هویت تار، د اجازې سرچینه او هغه نیټه چې ملاتړ پای ته رسيږي.