د OpenVPN ننوتلو کې د سټاټیک ننګونې کوډ چېرته ځي

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

د هغې غوښتنې څخه پیل وکړئ چې ستاسو کلاینټ واقعاً ښیي

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

هغه ساحې وشمېرئ چې تاسو ته واقعاً ورکړل شوې۔ د کارن نوم لپاره یوه ساحه او یوه پټه ساحه پرته له کومې ننګونې عادي پټنوم ننوتنه ده۔ د پټنوم وروسته د خپل لیبل سره ښکاره کېدونکې دویمه ساحه کلاینټ لخوا د ننګونې تعامل پلي کول دي۔

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

سرور باید دمخه څه ملاتړ وکړي

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

له آپریټر وپوښتئ چې کوم میکانزم ګڼل کوي۔ دا کېدای شي PAM سره خبرې کوونکی پلگ ان وي، د ټوکن خدمت په وړاندې ځواب تصدیق کوونکی سکریپټ هک، یا د مدیریت پر بنسټ ادغام چې پخپله د ډک شوي ارزښت تحلیل کوي۔ هر یو یې لږ توپیر لرونکې ننوتنه تمه کوي۔

دلته هم تمې باید تنظیم شي۔ دویمه غوښتنه د ننوتنې میکانزم ده، د دویم فکتور د پلي کېدو ثبوت نه، ځکه پلي کول د سرور په اړخ کې وي او یوازې د غلط کوډ ازموینې پر مهال ښکاره شي۔

هغه کوډ شوې ساحه چې د مدیریت انٹرفیس لیږي

کله چې مخکینی پای اړیکه د مدیریت انٹرفیس له لارې چلوي، پټنوم او د ننګونې ځواب د سپارلو دمخه په یو ارزښت کې ډک شي۔ د مدیریت انٹرفیس حواله بڼه بیانوي: یو مختګ، بیا د جلا Base64 برخو په توګه پټنوم او ځواب۔

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

همدا کوډ کول د ګډوډۍ تر ټولو عامه سرچینه هم ده، ځکه اوس درې بڼې شته چې ورته ښکاري او د یو بل پر ځای نه شي کارېدای۔ ساده اعتبارنامې فایل پټنوم لري۔ د پټنوم او کوډ لفظي یوځای کول بېل تار لري۔ د مدیریت کلاینټ ډک شوی ځواب دریم لري۔ یوازې د دې لپاره چې تېروتنه ورکه شوه، د ساحې بدلولو دمخه تایید کړئ چې ستاسو د ګڼلو لار کوم یو تمه کوي۔

سټاټیک د ډینامیک په وړاندې: بېل وخت

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

د یو ملاتړ بل نه درکوي۔ سټاټیکه غوښتنه ترتیب کوونکی پروفایل لارښود د سرور پیل کړې ننګونه نه پلي کوي، او ډینامیکې غوښتنې سمبالوونکی مخکینی پای بیا هم سټاټیکه نه ښیي۔ دا لوستل چې کوم اړخ غوښتنه پیل کړې، د هغوی توپیر لپاره تر ټولو ژر لار ده۔

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

بریا او ناکامي دواړه وازموئ، نه یوازې خبرې اترې

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

بیا له بیا اړیکې وروسته، له ناسم ثبت شوي حساب سره او د هغه کلاینټ له لارې چې ستاسو کاروونکي واقعاً چلوئ، اړیکه تکرار کړئ۔ غوښتنې ښکاره کېدل د کلاینټ چلند دي؛ د غلط کوډ ردېدل د سرور لخوا د یو څه پلي کول دي۔