IKEv2 یوازې یو لاس نیول نه دی: لومړی IKE SA، بیا تصدیق، بیا CHILD SA

شاید فکر وکړئ چې IKEv2 اړیکه یوه تبادله ده چې ستاسو ترافیک په کوډ شوي حالت کې پای ته رسوي. لږ تر لږه دوه دي، او لومړی یې هیڅوک تصدیق نه کوي. دواړه خواوې د کنټرول پیغامونو سره پیل کوي، د کرپټوګرافیک پیرامیټرونو په اړه سره موافق کیږي، هویت ثابتوي او یوازې وروسته له هغې د هغه حالت په اړه خبرې کوي چې د اپلیکیشن بستې وړي. همدا ترتیب هغه ناسمونو ته توضیح ورکوي چې خلک یې تل راپور ورکوي: دروازه ځواب ورکوي، کلاینټ وايي وصل دی، او شخصي اپلیکیشن بیا هم د وخت پای ته رسیږي. لاندې هغه څه دي چې هر پړاو واقعاً کوي او تر هغې وروسته څه باید رښتیا وي.

افسانه: که دروازه ځواب ورکړ، تاسو وصل یاست

لومړي پیغام ته ځواب ثابتوي چې پای ټکی د رسیدو وړ دی او د خبرو کولو لپاره چمتو دی. دا ثابتوي نه چې حساب ومنل شو، د سندونو زنځیر تایید شو، یا کومه معلوماتي پالیسي ولګیده.

هغه ناکامۍ وروسته پیښیږي او بېلې نښې لري. د سند ردول یا د EAP ناکامي هغه وخت راځي چې لومړۍ تبادله دمخه بریالۍ شوې، نو ځکه د UDP 500 ته ping او شنه کلاینټ نښه ډیر لږ څه وایي.

IKE_SA_INIT: په پیرامیټرونو موافق شئ، نه په هویت

لومړۍ تبادله د IKE امنیتي ټولنې لپاره وړاندیزونه وړي: د کوډ کولو او بشپړتیا الګوریتمونه، یوه شبه تصادفي فنکشن او د Diffie-Hellman ګروپ. دواړه خواوې nonce هم تبادله کوي، او هره خوا د هغو ارزښتونو څخه رامنځته شوي ګډ راز څخه د IKE SA لپاره کلیدي مواد لاس ته راوړي. په دې تبادله کې هیڅ شی نه ټاکي چې بله خوا څوک ده. یوازې دا ټاکي چې دواړه خواوې کولی شي یو شان کیلي محاسبه کړي او په یوه وړاندیز موافق دي. هغه ځواب ورکوونکی چې هیڅ وړاندیز خوښ نه شي، تبادله دلته ردوي، نو ځکه د نسخې یا الګوریتم ناسمونو د سرور د بندیدو په څیر ښکاري.

په دې نقطه جوړ شوی IKE SA د ورپسې ټولو مدیریتي تبادلو ساتنه کوي. دا د هغه کار دی، او دا ستاسو د بستو له ساتنې څخه بېل کار دی.

IKE_AUTH: هویت ثابت کړئ او بیا لومړنی CHILD SA جوړ کړئ

دوهمه تبادله هویت وړي. د سندونو سره، هره خوا د خپل شخصي کیلي سره لاسلیک کوي او هغه زنځیر وړاندې کوي چې بله خوا یې باید تایید کړي؛ د EAP سره، ځواب ورکوونکی د ټاکل شوې طریقې له لارې پیل کوونکی ننګوي. دلته په پای کې ناسم سرور نوم، پای ته رسیدلی سند یا رد شوی پټ نوم ښکاره کیږي.

معمولاً IKE_AUTH لومړنی CHILD SA هم خبرې کوي، نو د معلوماتو ساتنه په همدې تګ راتګ کې موافقه کیږي. پیل کوونکی د ترافیک غورځنګ وړاندیز کوي، ځواب ورکوونکی یې تنګوي یا ردوي، او د معلوماتو لارې کیلي له IKE SA څخه اخیستل کیږي. دې معنی چې یوه تبادله کولی شي په دوو ډیرو بېلو ځایونو کې ناکامه شي: هویت یا پالیسي. د عمومي لاس نیولو ناکامۍ پرځای خبرتیا یا تیروتنه ولولئ، ځکه د یوې درملنه سند دی او د بلې د فرعي شبکې ناسمونو.

دوه SA، دوه کارونه

د دوی جلا ساتل دوه چلندونه توضیح کوي چې د خطا په څیر ښکاري. تونل کولی شي جوړ ښکاره شي پداسې حال کې چې په شالید کې د کیلیو بیا جوړول ناکامیږي، او CHILD SA کولی شي بدل شي پرته له دې چې کلاینټ اړیکه له لاسه ورکړي.

په strongSwan کې، د IKEv2 د ترتیب حواله او swanctl --list-sas دواړه کچې ښیي، او ip xfrm state د ip xfrm policy سره یوځای ښیي چې کرنل واقعاً څه ولګول. د دې دوو لیدونو پرتله کول ترټولو چټکه لاره ده چې وګورئ خبرې پای ته رسیدلې که یوازې پای ته رسیدلې ښکارېدې. که ډیمون داسې CHILD SA ولیکي چې کرنل ورته حالت نه لري، نصب په خاموشۍ کې ناکام شو. که کرنل داسې حالت ولري چې ډیمون نه پوهیږي، تاسو د پخواني هڅې پاتې برخه ګورئ.

د تونل له پورته کیدو وروسته هم څه باید رښتیا وي

د ترافیک غورځنګ ټاکي چې کوم پته پوښل شوې ده. که کلاینټ یوه فرعي شبکه وړاندیز کړي او سرور بله تمه لري، CHILD SA نصب کیږي خو هیڅ ګټور نه وړي، او تیروتنه د خبرو اترو نه بلکه د لارښوونې ستونزه ښکاري. بیا سیمه ییز سټک باید همکاري وکړي: چیرې چې کوربه لارښوونه کوي هلته لیږد فعال، تونل ته اشاره کوونکې لارې، هغه فایرول قواعد چې د کپسول څخه ایستل شوې بستې اجازه ورکوي، او که شخصي نومونه شامل وي داخلي حل کوونکی. هر یو یې جلا ناکامیږي او هیڅ یو د IKE ډیمون په بیا پیل کولو سره نه سم کیږي.

د تشخیص پر مهال لاګ ښکاره وساتئ: لومړنۍ تبادله، بیا د هویت تایید، بیا د کاروونکي تصدیق چیرې چې پلي کیږي، بیا د CHILD نصب او په پای کې اپلیکیشن ترافیک. هغه پړاو چې دریږي هغه دی چې باید سم شي، او وروسته د لارښوونې ناکامي هیڅکله د دمخه تیرو شویو هویت څیړنو د کمزوري کولو سبب نه کیږي.