ایا په OpenConnect کې --key-password ستاسو د VPN حساب پټ نوم دی؟

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

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

دوه رازونه، دوه بېلې دندې

رولونه د فایل لاسرسي او شبکې ته د ننوتلو اجازې په توګه ولولئ. د کیلي پټ نوم هغه PEM شخصي کیلي کوډ پرانیزي چې په --sslkey کې نومول شوې، ترڅو د TLS کلاینټ سند وړاندې کړل شي. دا کوډ پرانیستل په محلي ډول، د کلاینټ پروسې په داخل کې ترسره کیږي، او پټ نوم پخپله هېڅکله ګېټوې ته نه ځي. ګېټوې هغه سند او د کیلي سره جوړ شوی لاسلیک ویني. د OpenConnect لارښود --key-password د --certificate او --sslkey ترڅنګ ساتي، او په هغو جوړښتونو کې چې په TPM کې ساتل شوې کیلي کارولای شي، هماغه انتخاب پرځای د ذخیرې د ریښې کیلي پټ نوم لري۔

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

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

د کیلي پټ نوم واقعاً کله اړین دی

انتخاب یوازې هغه وخت معنا لري چې د پرانیستلو لپاره کوډ شوې کیلي وي. که تاسو د کاروونکي نوم او پټ نوم سره او د کلاینټ سند پرته وصل شئ، --key-password هیڅ شی نه لري چې پرې عمل وکړي، او د هغې شاملول هیڅ نه بدلوي. که تاسو د --certificate او --sslkey سره وصل شئ، نو د کیلي فایل خپل جوړښت فیصله کوي چې ایا پټ نوم به هېڅ وغوښتل شي۔

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

ګټور تشخیص دا دی چې وګورئ ناکامي کله پېښیږي. که کلاینټ د کوم شبکه یي تصدیق له پیل مخکې ودريږي، د کیلي فایل، د هغې جوړښت یا پټ نوم باندې شک وکړئ. که د TLS غونډه جوړه شي او بیا ګېټوې کاروونکی رد کړي، کیلي خپله دنده ترسره کړې او ستونزه د حساب په تبادله کې ده۔

دواړه رازونه د شیل له تاریخې بهر وساتئ

د کمانډ کرښې دلیلونه نور محلي کاروونکي د پروسې جدول له لارې لوستلای شي او ډېری وختونه د شیل تاریخې، سکریپټونو او ملاتړ اسنادو کې نیول کیږي. OpenConnect کولای شي د حساب پټ نوم له معیاري ننوتلو څخه د --passwd-on-stdin سره ولولي، او د کیلي پټ نوم کولای شي د دلیل پرځای له متقابلې پوښتنې یا ایجنټ څخه راشي. هیڅ میکانېزم راز پخپله خوندي نه کوي، مګر دواړه هغه له تر ټولو ښکاره ځایونو څخه لرې ساتي۔

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

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

مړ د ډیسکټاپ تڼۍ بله خرابي ده

هغه د ډیسکټاپ VPN ننوتنه چې څرخېدونکی نښه ښيي او بیا هیڅ نه کوي، معمولاً د تصدیق ستونزه نه ده. تڼۍ د شبکې مدیر، د پلورونکي اپلیټ یا هغه پلګین پورې اړه لري چې ستاسو په استازیتوب OpenConnect چلوي، او ورکه شوې برخه یا نه لوستل کېدونکی پروفایل کولای شي هماغه نښه جوړه کړي. ومومئ کومه پروسه تڼۍ پیلوي او د اعتبارنامو له لمس مخکې یې تېروتنه ولولئ۔

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

لنډه چک لیست قضیې بېلوي. د هر بستې له وتلو مخکې محلي ناکامي کیلي یا د کلاینټ نصب ته اشاره کوي. د TLS غونډې وروسته د ګېټوې رد حساب تبادلې ته اشاره کوي. هغه تڼۍ چې هېڅکله کلاینټ نه پیلوي د ډیسکټاپ یوځای کېدو ته اشاره کوي. درې بېلې خرابۍ، چې یوه یې هغه پټ نوم دی چې تاسو غلط بکس کې ږدلو ته نږدې وئ۔