EAP که د کاروونکي سندونه؟ د IKEv2 تصدیق پرېکړه

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

مخکې له دې چې د دواړو شیانو له یوه سره لاس ووهئ، معلومه کړئ کومه ادعا ناکامه شوه. د ناکامۍ پړاو به تاسو ته ووایي، که په ترتیب یې ولولئ.

دوه اعتبارونه، دوه ادعاوې

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

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

EAP یو لوښی دی، طریقه نه

EAP یو چوکاټ دی: دروازه او کاروونکی د طریقې په اړه خبرې کوي، او طریقه پرېکړه کوي چې پټنوم، ټوکن، د تونل دننه تبادله که سند ښکیل دی، لکه چې د IKEv2 په اړه د strongSwan اسناد تشریح کوي. له همدې امله EAP-TLS د کاروونکي له اړخه EAP-MSCHAPv2 ته هیڅ نه ورته ښکاري، که څه هم دواړه په مینو کې د EAP په توګه ښکاري. هغه پروفایل چې یوازې EAP نوموي تاسو ته نه دي ویلي چې له کاروونکي به څه پوښتل کیږي.

طریقه او backend یوځای ولولئ. Backend د حساب بڼه، د بندیدو چلند او هغه څه ټاکي چې د پټنوم بیا تنظیم واقعیا یې بدلوي، او له دې څخه هیڅ په کاروونکي پروفایل کې نه ښکاري.

ګډ ځای پرځای کول عادي دي

د کاروونکي لپاره د سرور سند سره EAP هغه بڼه ده چې ډیری لرې لاسرسي دروازې ځای پرځای کوي، ځکه چې کاروونکي ته د تایید وړ پای ټکی او چلوونکي ته په مرکزي حساب ذخیره کې د هر کاروونکي هویت ورکوي. د کاروونکي سندونو سره ځای پرځای کول هم شته، معمولا هلته چې د وسیلې هویت له پټنوم څخه مهم وي. دواړه قانوني دي، او تېروتنه دا ده چې فکر وکړئ تېره اونۍ چې څه ولیدل هغه ستاسو مخې ته دی.

د کاروونکي په برخو کې د نومونو څخه اټکل کولو پرځای له چلوونکي څخه اسناد شوې طریقه او د حساب بڼه وپوښتئ.

د ناکامۍ له پړاو څخه پرېکړه

مشاهدې په ترتیب کې واچوئ. د هر کاروونکي غوښتنې مخکې د باور تېروتنه د سرور د سند ستونزه ده او هیڅ پټنوم به یې سم نه کړي. غوښتنه چې وروسته یې رد راشي د کاروونکي تصدیق ستونزه ده، چې EAP طریقه او backend پکې شکمن دي. بریالۍ تصدیق چې وروسته یې child-SA ناکامي راشي د دواړو څخه نه دی.

دوه نور توپیرونه مهم دي. هغه کاروونکی چې د سرور سند ردوي معمولا د نوم ناسم مطابقت یا ناپېژندل شوي واکمن راپور ورکوي، چې د باور ذخیرې پوښتنه ده. هغه دروازه چې کاروونکی ردوي ډیری وخت د EAP طریقه او د لامل کټګوري ثبتوي، چې د حساب یا تګلارې پوښتنه ده.

د دواړو ماډلونو چلول

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

دوی په خپلو یادښتونو کې جلا وساتئ. د سند پای د یوې نېټې په ورځ ناکامي رامنځته کوي، د حساب بندیدل د پټنوم له بدلون وروسته ناکامي رامنځته کوي، او د طریقې ناسم مطابقت یوازې په یوه پلیټ فارم کې ناکامي رامنځته کوي.

وروسته له دې چې هویت ومنل شو

تصدیق یوه دروازه ده. child امنیتي ټولنه، د ترافیک ټاکونکي، DNS او د غوښتنلیک خپل اجازې وروستي دروازې دي، او هر یو په خپلو شرایطو کې ناکام کیږي. منل شوی هویت چې چیرې هم ونه رسي د تصدیق ستونزه نه ده.

طریقه، کارول شوی حساب یا سند او هغه پړاو چې ناکام شو ولیکئ. هغه یادښت بلې پیښې ته د ازموینې پرځای د لټون بڼه ورکوي.