د IKEv2 تبادله کار کوي، بیا تصدیق ناکامېږي: چېرته وګورو

هغه کلاینټ چې د IKEv2 ځواب ترلاسه کوي، ثابته کړې چې ګیټوې رسیدونکی دی، دواړه خواوې کولای شي د یوې وړاندیز په اړه خبرې وکړي او لومړنۍ د کیلي تبادله بشپړه شوه. خو دا یې نه ده ثابته کړې چې څوک تصدیق شوی. بله تبادله هویتونه، سندونه یا EAP وړي، او معمولاً اړیکه هماغه ځای ودريږي. دا لوستل چې کومه ګڼنه ناکامه شوه، ټوله تشخیص دی، او یوازې د خطا پیغام دا نادراً وایي.

ګڼنه 1: مرحله ولولئ، نه پیغام

رد کول کولای شي له دریو ځایونو راشي: کلاینټ د سرور هویت ردوي، ګیټوې د کلاینټ ثبوت ردوي، او یوه بهرنۍ تصدیق خدمت حساب ردوي.

هر یو په بېل ماشین کې بېله لاګ کرښه جوړوي، او هر یو بېل حل لري. د کلاینټ له خوا د سرور سند ردول په کلاینټ کې د باور یا نومونې ستونزه ده؛ د ګیټوې له خوا د کلاینټ سند ردول په ګیټوې کې د باور ستونزه ده؛ د EAP ناکامي د حساب یا بیکنډ ستونزه ده. هغه پیغام چې تاسو یې ګورئ معمولاً د کلاینټ لنډیز دی د دې یوې په اړه، نو ځکه د ګیټوې لاګ د کلاینټ د لاګ په څېر مهم دی.

ګڼنه 2: کوم هویت وګڼل شو

کلاینټ کولای شي د سرور سند یا خپل تمه شوی هویت رد کړي مخکې له دې چې د کارن کوم اعتبار وړاندې شي، او د سرور فعال پته د دې ګڼنې بدیل نه دی. هغه پیژندونکی چې کلاینټ یې تمه لري باید د هغه سره سمون ولري چې ګیټوې وړاندې کوي, چې دا د شبکې نه بلکې د تنظیم حقیقت دی.

د strongSwan په اصطلاحاتو کې دا په کلاینټ کې rightid او په بل لوري کې د ګیټوې خپل هویت دی، او ناسمونې مخکې له دې چې EAP ورباندې خبرې وشي ناکامېږي.

ګیټوې جلا کولای شي د کلاینټ سند، د هغه د کیلي ثبوت یا د هغه د حساب تصدیق رد کړي، او دا درې یو د بل بدیل نه دي. د کارن پټنوم بیا تنظیمول د وسیلې سند نه نوي کوي، او د وسیلې سند بیا نصبول غلط د سرور هویت نه سمول کوي. د سند ناکامیو لپاره لومړی ساعت، بیا د باور زنځیر، بیا تمه شوی پیژندونکی وګورئ؛ هغه کلاینټ چې ساعت یې څو دقیقې توپیر لري د اعتبار ګڼنه کې ناکامېږي چې د باور ناکامۍ په څېر ښکاري. swanctl --list-certs په دواړو سرونو کې ښیي چې هر لوری واقعاً څه لري.

ګڼنه 3: که EAP ښکیل وي

کلاینټ او سرور باید د یوې ملاتړ شوې طریقې په اړه سلا شي، او بیکنډ باید ورکړل شوی هویت ومني.

د کارن نوم کېدای شي د ډومین ضمیمه یا د ځای پرځای کولو لخوا غوښتل شوی ځانګړی حساب بڼه ته اړتیا ولري، او بڼه د اټکل وړ نه بلکې مستنده ده. د چلونکي مستندې برخې ورکول د بېلابېلو بڼو هڅولو څخه ګړندي دي، او دوهمه ستونزه هم منع کوي: تکراري هڅې کولای شي حساب بند کړي، چې بیا اصلي مرحله د نويې ناکامۍ شاته پټوي. که طریقه د یوې لارښودې پر وړاندې EAP-MSCHAPv2 وي، ناکامي کېدای شي د VPN نه بلکې د لارښودې وي.

د هویت ګڼنې بندولو سره د هویت ستونزې مه ازموئ. دا د تشخیص وړ ناکامي په نه تشخیص وړ بدلوي او اړیکه له مخکې څخه کمزورې پرېږدي.

ګڼنه 4: له بریالۍ ننوتنې وروسته څه پیښېږي

کله چې IKE_AUTH بشپړ شي، د CHILD_SA خبرې اترې فیصله کوي چې کوم د ترافیک غوره کوونکي نصب شي، او هماغه ځای کې اړیکه کولای شي بریالۍ وي او بیا هم هېڅ نه تېروي.

نوې کارېدونکې ننوتنه ډېری وخت هغه غوره کوونکی یا لار ستونزه ښکاره کوي چې مخکې د تصدیق ناکامۍ شاته پټه وه. که ټنل پورته شي او یو اپلیکیشن بیا هم خپل منزل ته نه رسېږي، بیا د هویت پر ځای دې خبرو اترو شوو غوره کوونکو او لارو ته وګورئ. په هغه وخت کې د هویت تنظیمات بدلول غلطې مرحلې ته نښه نیسي او معمولاً یوه کارېدونکې ننوتنه ماتوي. swanctl --list-sas سره تایید کړئ، کوم چې ماشومان او د هغوی غوره کوونکي د IKE SA څخه جلا ښیي.

ګڼنه 5: ملاتړ ته څه ورکړو

پاکه شوې مهالیزه او دقیق ردول د بشپړ تشخیصي صادراتو څخه ډېر ارزښت لري، او صادرات کېدای شي خصوصي کیلي یا اعتبار ولري چې تاسو یې نه شئ شریکولای.

وخت د وخت زون سره، د کلاینټ او ګیټوې نسخې، طریقه، د پټنوم پر ځای وړاندې شوې هویت رشته، او هغه دقیقه مرحله چې رد کړه یې، ثبت کړئ. د strongSwan د IKEv2 تنظیماتو مستندات هغه د هویت او EAP تنظیمات تشریح کوي چې دا پایلې فیصله کوي، او دا هغه حواله ده چې باید د یوې برخې بدلولو مخکې ولولئ. بیا یو شی بدل کړئ او نوی اړیکه بیا ازموئ، ځکه چې کیش شوې ناسته به تاسو ته د زوړ تنظیم په اړه ووایي.