د ګیټوې سند سم دی: ولې IKEv2 PEAP ننوتل بیا هم ناکامېږي

ستاسو د VPN ګیټوې سند اعتبار لري، زنځیر اعتبار شوی، او IKEv2 کلاینټ بیا هم د سند د اعتبار مودې په اړه پیغام سره ننوتل ردوي۔ لومړی احساس دا دی چې د ګیټوې سند بیا صادر کړئ یا د EAP طریقه بدله کړئ، او دواړه معمولاً غلط دي۔ د ننوتلو هڅه دوې جلا سرور هویتونه لېږدوي: هغه ګیټوې سند چې IKE یې کاروي، او هغه سند چې PEAP پای ته رسولونکی یې وړاندې کوي۔ یو یې سم دی، او بل یې هغه لامل دی چې کلاینټ ودرېده۔

دوه هویتونه، یوه ننوتلو هڅه

د VPN پروفایل سند د IKE تبادلې پورې اړه لري: دا ثابتوي چې ګیټوې هغه لوری دی چې پروفایل یې نوموي، د ترتیب شوې IKE پالیسۍ لاندې۔ هغه سند چې دلته ناکامېږي بلې خبرې اترې پورې اړه لري، یعنې هغه TLS ناسته چې PEAP د کارونکي تصدیق کوونکي سره پرانیزي، چې ډېری وخت د ګیټوې په ځای د NPS په څېر RADIUS سرور وي۔ درېیمه څېړنه، یعنې د کارونکي اسناد، د همدې ناستې دننه ترسره کېږي۔ سم پټنوم نشي کولی پای ته رسېدلی سرور سند جوړ کړي، او سم ګیټوې سند نشي کولی د PEAP پای نقطې لپاره ضمانت وکړي۔

دا طبقې جوړښت څرګندوي چې ولې د سند تېروتنه هغه ځای کې ښکاري چې یوازینی ترتیب شوی سند د ګیټوې و۔ دا هم څرګندوي چې ولې د هغه سند بیا صادرول هېڅ نه بدلوي۔

د لاګ کرښه د پړاو سره پرتله ولولئ

هغه پیغام ومومئ چې لامل او نېټې نوموي۔ د اعتبار مودې شکایت د موضوع تېروتنې ترڅنګ یعنې سرور هغه سند رد کړ چې ورکړل شوی و، نه دا چې کارونکي ننوتل رد کړل۔ بیا پړاو ومومئ: strongSwan charon لاګ د EAP تبادلې پیل دمخه IKE_SA .* established ښیي، نو د هغې کرښې وروسته د سند تېروتنه د EAP هویت پورې اړه لري، خو د هغې دمخه تېروتنه ګیټوې ته اشاره کوي۔ د Windows کلاینټ د اړیکې پینل کې د پړاو متن همدا خبره کوي۔

له کوم سند سره د لاس وهلو دمخه د کلاینټ ساعت وګورئ۔ هغه وسیله چې څو ساعته غلط وي، د واقعاً پای ته رسېدلي سند په څېر هماغه د اعتبار تېروتنه تولیدوي۔ د ساعت سمول پنځه ثانیې سمون دی، او هغه سند بدلول چې کله هم ستونزه نه و، د خدمت وقفه ده۔

ومومئ کومه پای نقطه PEAP پای ته رسوي

د ګیټوې او RADIUS په ډیزاین کې ګیټوې EAP مخې ته لېږي او پای ته یې نه رسوي۔ د strongSwan eap-radius پلگ ان تبادله RADIUS سرور ته سپاري، چې د PEAP TLS ناسته او د هغې سند یې ملکیت دی۔ په دواړو لاګونو کې یوه ناکامه هڅه سره ونښلئ او تایید کړئ کوم بهیر په رښتیا د هغې ناستې لپاره سند وټاکه۔

د NPS لپاره سند باید د سیمه ییز کمپیوټر په زېرمه کې وي، د سرور تصدیق موخه ولري، د هغه نوم سره سمون ولري چې کلاینټان یې تمه لري، او د خدمت حساب لپاره لوستل کېدونکی وي۔ د NPS لپاره د Microsoft د سند غوښتنې همدغه شرطونه لیستوي۔ نور EAP سرورونه خپل ټاکلو قواعد لري، نو د NPS ځانګړنې د FreeRADIUS په ځای پرځای کولو کې یا برعکس مه کاپي کوئ۔ هغه قاعده چې په دواړو حالتونو کې پاتې کېږي دا ده چې PEAP پای ته رسولونکې پای نقطه هغه سند لري چې تاسو یې بدلولو ته نږدې یاست۔

سند هغه ځای بدل کړئ چې EAP پای ته رسېږي

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

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

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

څه مه کوئ

د تېروتنې د تېرېدو لپاره PEAP تصدیق مه بندوئ او نه هم کمزوری داخلي طریقه زوروره کوئ۔ دا پالیسي بدلوي او هغه د سرور تصدیق ځانګړتیا لرې کوي چې پای ته رسېدلی سند یې لومړی نیولی و۔ تاسو به یوه کارکوونکې څېړنه د یوې کارکوونکې اړیکې سره بدله کړئ، او بل پای ته رسېدلی سند به پرته له هېڅ اعلان راورسېږي۔

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