په یو IKEv2 ننوت کې دوه هویتونه: لومړی ماشین، بیا کاروونکی

د کاروونکي سند تصدیق کیږي، لومړی تبادله بشپړیږي، او بیا د اضافي تصدیق پړاو په اړه د یوې تېروتنې سره اړیکه ودریږي۔ په سندونو زنځیر کې هیڅ شی غلط نه دی او په شبکه کې هیڅ شی نه دی بدل شوی۔ جګړه د نښلېدونکي اړخ څخه دوهم ثبوت غوښتلو لپاره تنظیم شوې ده، او کاروونکی هغه هیڅکله نه لیږي۔ دا فیصله چې څوک څه او په کوم ترتیب ثابتوي ټول کار دی، او له هماغه پای ټکي څخه چې تاسو پرې ولاړ یاست د تګلارې لوستلو سره پیل کیږي۔ د دوو جلا ډولونو دوې ثبوتې په ټاکلي ترتیب کې اېښودل د ډیزاین فیصله ده، نه د ټیک کولو مربع۔

نښه: د بریالي لومړي ثبوت وروسته ناکامي

لومړی تبادله بشپړیږي او لاګ روغ ښکاري، تر هغه چې جګړه د EAP له لارې د کاروونکي هویت وغواړي۔ بیا لاس ورکول ودریږي یا د پروتوکول تېروتنه بیرته راځي چې اضافي پړاو نوموي۔ په بشپړ ډول معتبر د ماشین سند د داسې دلیل له امله رد کیږي چې د هغه له اعتبار سره هیڅ تړاو نه لري۔ تګلارې دوهم ثبوت غوښتی و، او د کاروونکي ځواب هیڅکله ونه رسېد۔

د هغې ناکامۍ دواړه توضیحات ستاسو د درېدو پر بنسټ سم دي۔ د کاروونکي له خوا دا داسې ښکاري لکه سرور چې معتبر سند ردوي، او د سرور له خوا لکه کاروونکی چې ننوت نشي بشپړولی۔ هماغه پېښه په یو لاګ کې د باور ستونزه او په بل کې د وړتیا ستونزه لوستل کیږي۔ کومه یوه ده دا یوازې تنظیم شوې تګلاره وایي۔

غځونکی څه زیاتوي او څه نه زیاتوي

IKEv2 په یوې غونډې کې له یوې ډېرې تصدیق تبادلې لپاره غځونکی لري۔ RFC 4739 د نورو ترتیبونو ترڅنګ هغه کاروونکی انځوروي چې د سند هویت ثابتوي او بیا د EAP له لارې یو کس تصدیقوي۔ سند د Experimental په حالت کې دی، یعنې هیڅ تطبیق تاسو ته دا ځانګړتیا ورکولو ته مکلف نه دی۔ تر هغه چې سیال یې په اړه خبرې ونه کړي د ملاتړ په اړه هیڅ مه فرض کوئ۔

دواړه خواوې باید غځونکی ملاتړ کړي او د تبادلې په جریان کې پرې سلا وکړي۔ د دوهم پړاو لپاره تنظیم شوې جګړه نشي کولی کاروونکی اړ کړي چې هغه ترسره کړي، او هغه کاروونکی چې ملاتړ یې کوي تر هغه چې سرور یې وغواړي نه یې کاروي۔ همدا نابرابري د دې سبب ده چې ناکامي معمولاً د وړتیا په اړه د روښانه بیان پر ځای د وخت پای یا پروتوکول تېروتنې په بڼه ښکاره شي۔ د یوې خوا تنظیمات لوستل تاسو ته د هغه څه نیمه وایي چې پېښ به شي۔

په هر پای ټکي یو ثبوت عادي بڼه ده، او دا هغه ډیزاین نه دی۔ جګړه خپل سند وړاندې کوي، کاروونکی د EAP له لارې ځواب ورکوي، او هرې خوا بل ته په سمه توګه یو ځل تصدیق کړی دی۔ هغه دوه ثبوتې له مخالفو سرونو څخه راځي، نو هیڅ یوه یې په جلا توګه د ماشین او هغه کس چې کاروي یې په اړه څه نه وایي۔

EAP-TLS درېیمه بڼه ده، او هغه هم دا نه ده۔ هلته د کاروونکي سند د EAP میتود دننه وړاندې کیږي، نو کاروونکی لا هم یوه IKE تصدیق بشپړوي۔ اعتبارنامې کیدای شي د څو پړاوونو حالت ته ورته ښکاره شي، په داسې حال کې چې پروتوکول د دوو پر ځای یو پړاو وړي۔ له همدې امله د EAP-TLS له نصب څخه کاپي شوی ډیزاین په هماغه ځای کې ناکام کیږي چې د دوهم ثبوت تمه کیږي۔

هماغه فایل په جګړه کې جلا لوستل کیږي

هماغه swanctl فایل د دې پر بنسټ چې چېرته ځي جلا لوستل کیږي، او همدا هغه برخه ده چې خلک ښویېږي۔ په لپ ټاپ کې جګړه سیاله ده، او په جګړه کې لپ ټاپ سیاله دی، نو local خوا د «زه څوک یم» او remote خوا د «چا ته اجازه ورکوم» په توګه ولیکئ۔ local بلاک تشریح کوي چې دا پای ټکی څنګه ځان تصدیقوي، او remote بلاک بیانوي چې له بل سره څه غواړي۔ د دوو فایلونو ترمنځ بلاک کاپي کول د یو توري بدلولو پرته د هغه مانا اړوي۔ د دواړو فایلونو پرتله کول نږدې هیڅ نه وایي، ځکه هماغه کلمې په هر یو کې مخالف مانا لري۔

د یوې برخې موقعیت د هغې ترتیب ټاکي، پرته له دې چې د پړاو شمېره یې ترې واوړي۔ نو ځکه اضافي local یا remote برخې بدیلونه نه، اضافي پړاوونه تشریح کوي، او په د swanctl.conf حواله کې روښانه د پړاو شمېره یوازې د هماغه ترتیب د پوهاوي لپاره ده۔ پرته له هغې د بلاک لېږدول چلند بدلوي۔ له همدې امله دوه تنظیمات چې په کاغذ معادل ښکاري کیدای شي په مخالف ترتیب عمل وکړي۔

همغه د ترتیب قاعده د یادولو وړ د ناکامۍ بڼه رامنځته کوي۔ دوهم remote بلاک بل منل شوی انتخاب نه دی؛ دا دوهمه غوښتنه ده، نو هغه تګلاره چې «یا/یا» لوستل کیږي د «او-بیا» په څېر چلند کوي۔ د جګړې تګلاره کیدای شي د ثبت شوي ماشین سند ومني او بیا د هماغه کاروونکي EAP تبادله په هماغه ترتیب وغواړي۔

پړاوونه له خپلواکو عواملو جلا کړئ

دوه پړاوونه په اتوماتيک ډول دوه خپلواک عوامل نه دي۔ د ثبوت تکرارول، یا په یوه زېرمه کې دوه اعتبارنامې ساتل، هغه ځواک نه ورکوي چې ډیزاین باید ورزیات کړی وی۔ خپلواکي د دې ځانګړتیا ده چې رازونه څنګه ساتل کیږي او څه یې له خطر سره مخامخ کوي، نه دا چې پروتوکول څو تبادلې کوي۔ هغه ډیزاین چې پړاوونه د عواملو په توګه شمېري خپل ځواک ډېر ښیي۔ دا توپیر تر ټولو ډېر هغه وخت مهم دی چې د انطباق پوښتنه پوښتنه کوي چې ننوت په رښتیا څو عوامل کاروي۔

د ماشین سند د خپل منل شوي کیلي مالکیت ثابتوي، او نور هیڅ نه۔ دا د سختو توکو تصدیق نه دی او د وسیلې روغتیا راپور هم نه دی، نو هغه تګلاره چې د حالت معلومات غواړي بل میکانیزم ته اړتیا لري۔ subject ساحه هم باوري د توکو نښه نه ده، ځکه subject هغه څوک ټاکي چې سند یې صادر یا ثبت کړی دی۔ که ډیزاین ته د دې ثبوت ته اړتیا وي چې ماشین روغ دی، نو هغه ثبوت باید له هغه برخې څخه راشي چې ماشین اندازه کوي۔

ولیکئ چې هر پړاو په رښتیا څه ثابتوي، مخکې له دې چې یې زیات کړئ۔ کله چې دوه پړاوونه یو شی دوه ځله ثابتوي، دوهم د ډاډ پر ځای ځنډ او د ملاتړ ټکټونه زیاتوي۔ هماغه یادښت هغه څه دی چې د دې بحث مخه نیسي چې آیا اضافي پړاو د خپل لګښت وړ دی۔

د جوړې قاعده ولیکئ او ردونه وآزمویئ

فیصله وکړئ چې کوم د ماشین هویتونه له کومو خلکو سره جوړې کیدای شي، او قاعده هلته ولیکئ چېرې چې پلي کول اوسي۔ په څنګ کې اېښودل شوې دوه معتبرې اعتبارنامې د جوړې په اړه هیڅ نه ثابتوي، ځکه جوړه د تصدیق پایله نه ده بلکې د اجازې فیصله ده۔ د ثبت ریکارډونه یا د تصدیق بیکاینډ باید هغه اړیکه پلي کړي چې سازمان یې غواړي۔

بیا هغه څه وآزمویئ چې باید ناکام شي: په نه منل شوي ماشین کې منل شوی کاروونکی، د ماشین اعتبارنامه لرونکی نه منل شوی کاروونکی، او هغه سیال چې اضافي پړاو نشي کولی۔ که درې واړه په چوپتیا سره یو شان لاسرسی ومومي، تګلاره د پلي کولو پر ځای اراده تشریح کوي۔ اعلان شوې تنظیمات د هغه څه سره پرتله کړئ چې ډیمون یې راپور کوي، ځکه هغه اړیکه چې هیڅکله سره سمه نه وه د تېرې شوې قاعدې په څېر ښکاري:

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

نه یوازې بریالی ننوت، بلکې خبرې شوې پړاوونه او له هغو رامنځته شوې اجازه هم وګورئ۔ او د لنډې لارې په توګه زړو IKEv1 XAuth تنظیماتو ته مه ورځئ: تر هغه چې اړیکه بریالۍ شي اړین پړاو حذف کول پر ځای پروتوکول، رولونه، ترتیب او د کاروونکي ریښتینی چلند سره سم کړئ۔ هغه پړاو حذفول چې ناکام کیږي هغه لار ده چې د دوو ثبوتونو ډیزاین په چوپتیا سره د یو ثبوت ډیزاین ته اوړي چې هیڅوک نه دی کتلی۔ حذفول په بدلون ریکارډ کې وساتئ۔