MikroTik ګیټوی ته رسېدل د IKEv2 ځای پرځای کولو یوازې نیمایي ټرانسپورټ حل کوي او نور هیڅ نه. بیا څلور جلا ادعاوې پرېکړه کوي چې تونل جوړېږي که نه: هغه پته چې ټیلیفون یې ګرځوي، هغه سرور هویت چې تمه یې لري، هغه هویت چې د ځان لپاره یې ادعا کوي، او هغه سندیز مواد چې دې ادعا ته ملاتړ ورکوي. هغوی په همدې ترتیب وګورئ، او په لومړنۍ هغه کې ودرېږئ چې د ګیټوی له وړاندې کولو سره سمون نه خوري. هر یو په بېل ځای کې سمول کېږي، له همدې کبله غلط سمون معمولاً نیمګړتیا لېږدوي نه دا چې سمه یې کړي.

SettingWhat it decidesWhat it has to agree with
Remote addresswhere IKE packets are senta reachable name or address for the gateway
Remote Identifierwhich server identity is expectedthe gateway certificate name and the peer identity RouterOS presents
Local Identifierwho the phone claims to bethe client certificate name and the RouterOS identity entry
Certificate payloadtrust plus proof of key possessionthe issuing chain and a usable client private key

د پروفایل ساحې په هغه ترتیب وګورئ چې تبادله یې کاروي

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

ځایي پېژندونکی د ټیلیفون خپله ادعا ده، او باید هغه نوم وي چې د ټیلیفون لخوا وړاندې شوي کليېنټ سند لپاره د RouterOS پېژندنې ننوتنه یې مني. که دواړه سره سمون ونه خوري، ګیټوی د سند له تصدیق وروسته اړیکه ردوي، او لاګ د نومونې نه، د اجازې ستونزه ښکاري.

پېژندونکي د ګیټوی له وړاندې کولو سره وګورئ

د سند تصدیق لپاره تنظیم شوې د RouterOS سیال ننوتنه خپل سند وړاندې کوي، او د هغې پېژندنه له همدې سند څخه اخیستل کېږي پرته له دې چې بل ډول یې تنظیم کړی وي. که د ټیلیفون لرې پېژندونکی د ګیټوی DNS نوم یاد کړي، د ګیټوی سند ته دا نوم په هغه ځای کې اړین دی چې ټیلیفون یې مني، معمولاً د موضوع په بدیل نوم کې. د بل عام نوم لپاره صادر شوی سند حتی د کلۍ او زنځیر بشپړتیا سره هم تصدیق نه شي.

مدیریت شوي Apple پروفایلونه کولای شي د پېژندونکي ساحو سربېره ارزول کېدونکې د سند-نوم محدودیت هم ولري. د تنظیماتو پرده چې څه ښیي له هغې څخه د تصدیق نوم اټکل کول پرېږدئ او پیلوډ وګورئ، ځکه دواړه یو تنظیم نه دي.

وګورئ چې د کليېنټ سند کلۍ دی، نه یوازې د باور لنګر

د CA سند واردات ټیلیفون ته هغه څه ورکوي چې پرې ګیټوی تصدیق کړي. دا ټیلیفون ته کليېنټ پېژندنه نه ورکوي، او د سند تصدیق ته د کليېنټ پاڼې سند او د هغې شخصي کلۍ د تصویب شوې ثبت لارې له لارې یوځای رسولو ته اړتیا ده. پرته له شخصي کلۍ جوړ شوی PKCS#12 هغه پروفایل ورکوي چې پاک لګېږي او هیڅ نه تصدیق کوي.

د کليېنټ پاڼې ته د RouterOS اړخ لخوا تمه شوې پېژندنه هم اړینه ده، یعنې موضوع یا د موضوع بدیل نوم باید له اړوندې پېژندنې ترتیب سره سمون ولري. له یوې CA څخه د کليېنټ او سرور سندونو صادرول زنځیر اسانه کوي او دوه پاڼې د یو بل بدلېدونکې نه جوړوي.

وګورئ چې د RouterOS تګلاره هغه نوم مني

په ګیټوی کې سیال ننوتنه د تبادلې حالت او د تصدیق طریقه ټاکي، او پېژندنې ننوتنه منل شوې لرې پېژندنه له سند او له وروستې تګلارې سره تړي. په RouterOS v7 کې دا جوړه د IPsec سیال او پېژندنې ننوتنو له لارې څرګندېږي، لکه auth-method=digital-signature لرونکی IKEv2 سیال. په خپل نصب شوي خپرونه کې د مینو ریښتینی مینځپانګه وګورئ، نه هغه لارښود چې زوړ ته لیکل شوی.

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

له هر څه سمولو دمخه وګورئ چې کوم پړاو ناکام شو

هڅه په دواړو سرونو ولولئ او له بدلون دمخه یې ډلبندي کړئ. د وړاندیز ناسمونی، ورک شوې لاسلیک کلۍ، نا باوري صادروونکی، غلط سیال پېژندونکی او رد شوې کليېنټ اجازه ټول له ټیلیفون څخه مړ تونل ښکاري، او هر یو بېل خاوند لري. پنځه تنظیمات یوځای بدلول تضمین کوي چې له پایلې څخه به هیڅ ونه زده کړئ.

وړاندې شوې پېژندنه، تمه شوې پېژندنه، د سند صادروونکی او لړیز نمبر او د اړوندې تګلارې نوم ثبت کړئ، او شخصي کلۍ او د پروفایل رازونه له دې ثبت څخه بهر وساتئ. کله چې تصدیق بریالی شو، یوه شخصي خدمت او د هغې ځواب وآزمویئ، ځکه د پتو وېش، ټاکونکي، DNS او د لاسرسي تګلاره باید د IKE تبادلې له پای وروسته هم کار وکړي.

اړوندې مقالې