د IKEv2 تصدیق نامې SAN: ولې د هویت څیړنه ناکامه کیږي

ستاسو تصدیق نامه د باوري CA سره تړلې ده، نیټې سمې دي، او سیال بیا هم د هویت تېروتنې سره 1 پړاو بشپړولو څخه انکار کوي۔ د رسیدو وړتیا او معتبر لاسلیک یوازې هغه څه نیمه دي چې د IKEv2 کلاینټ یې ګوري۔ بله نیمه دا ده چې ایا هغه هویت چې تمه یې لري په تصدیق نامه کې په سمه برخه کې ښکاري، او دا تمه پروفایل ټاکي، نه د تصدیق نامې د فایل نوم۔

نښه تل ورته بڼه لري

د اړیکې پروفایل له هوسټ نوم څخه IP پتې ته بدلیږي، یا له هغې تصدیق نامې چې DNS نوم یې درلود، هغې ته چې یوازې پتې لري نوي کیږي، اوتونل خبرې اترې بندوي۔ د شبکې په لار کې هیڅ نه بدل شو۔ کلاینټ سیال ته رسیږي، تصدیق نامه ترلاسه کوي، او د سیال هویت ردوي ځکه چې هغه پیژندونکی چې ورته ویل شوي و چې تمه یې ولري په هغه برخه کې نه دی ښودل شوی چې هغه یې مني۔ نوي کول معمول لامل دی، ځکه چې بدله تصدیق نامه ډیری وخت له بل کښل شوي بڼې څخه راځي چې هغه یې بدلوي۔

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

د پیژندونکي ډول سره سمون کړئ، نه یوازې ارزښت

dNSName SAN او iPAddress SAN بیلابیلې برخې دي چې بیلابیل سمون قواعد لري، نو هغه تصدیق نامه چې 203.0.113.10 د DNS تار په توګه لري هغه کلاینټ نه قناعت کوي چې د IP هویت تمه لري۔ عصري تصدیق کوونکي تر ډیره عمومي نوم له پامه غورځوي، نو د تصدیق نامې په تفصیلاتو کې دوستانه لیبل هیڅ نه ثابتوي چې څه به سمون وکړي۔ که د ستونزې حل په جریان کې هوسټ نوم پتې سره بدل شوی وي، تر څیړنې پورې فرض کړئ چې تمه شوی هویت هم ورسره حرکت کړی۔ په پروفایل کې تار د SAN په تار سره توري په توري پرتله کړئ، ځکه چې په پای کې یوه نقطه یا اضافي تشه کافي ده۔

وایلډکارډونه یوازې د DNS اسانتیا دي او خپل سمون قواعد تعقیبوي، دا یو بل دلیل دی چې د IP پر بنسټ پروفایل باید هیڅکله پرې تکیه ونه کړي۔

ومومئ چې هر کلاینټ تمه چېرته ساتي

په strongSwan کې، هغه ارزښت چې د تصدیق نامې سره پرتله کیږي د سیال د هویت تنظیماتو څخه راځي: rightid په کلاسیک ترتیب کې، یا id په swanctl کې د لیرې اړیکې برخې id څخه۔ د Apple IKEv2 متقابل عمل په اړه د هغې اسناد دلته ګټور دي ځکه چې هغه د هویت کنوانسیونونه تشریح کوي چې د پروفایل لخوا پرمخ وړل شوی کلاینټ یې کاروي، او هغه کنوانسیونونه د ناسمونو یوه طبقه تشریح کوي چې په تار کې ناڅاپي ښکاري۔

د Apple ترتیب پروفایلونه د لیرې پیژندونکي برخه لري، او هلته ارزښت هغه څه دي چې کلاینټ یې ګوري، نه د اړیکې تنظیماتو کې د سرور پته۔ Windows او وسیلې کلاینټونه هر یو خپله برخه او خپل ډیفالټ لري، او ډیفالټ ډیری وخت ستاسو ټایپ شوې پتې تعقیبوي۔ چېرې چې دوه برخې سره اختلاف ولري، هغه چې کلاینټ واقعیا لولي هغه ګټي، او دا په ندرت هغه وي چې تاسو ترمیم کړی۔

پروفایل یا تصدیق نامه په قصد اصلاح کړئ

د هر څه بدلولو دمخه د تصویب شوو وسایلو سره د سیال تصدیق نامه وګورئ او د SAN ننوتنې د هغوی د ډولونو سره لیست کړئ۔ هغه څیړنه خصوصي کیلي او اپلوډ ته اړتیا نه لري، او پوښتنه په ثانیو کې حل کوي۔ که څوک چې د یو DNS هویت اراده لري، تصدیق نامه باید هغه د dNSName ننوتنې په توګه ولري، او که څوک چې د پتې اراده لري، تصدیق نامه د هماغې پتې لپاره iPAddress ننوتنې ته اړتیا لري۔

کله چې تصدیق نامه غلطه وي، له آپریټر څخه د ځانګړي تمه شوي پیژندونکي سره سمه شوې وغواړئ۔ کله چې پروفایل غلط وي، پروفایل اصلاح کړئ او تصدیق نامه پریږدئ۔ د هویت تصدیق بندول تېروتنه ورکوي او هغه څیړنه هم لرې کوي چې تونل ستاسو د ارادې سیال سره خبرې کوي۔

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

د نوي کولو غوښتنې ته څلور حقیقتونه ورکړئ

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