د OpenVPN خدمت د شخصي کلي کليمې غوښتنې پر مهال درېږي: څنګه یې سم کړو
خدمت ټرمینل نه لري، نو کوډ شوې کلي ته askpass او لوستل کېدونکې دوتنه غواړي. د کلي پټنوم د سرور له ننوتلو جلا کړئ او unit وګورئ.
OpenVPN په سیمهایز ماشین کې د شخصي کلي پټنوم غواړي، نو یوه کار کوونکې ننوتلو دوتنه هېڅکله ځواب نه ورکوي. په خدمت کې د ټایپ کولو ټرمینل نه وي، او پیل یا ځړېږي یا د ژورنال هغه یادښت سره ناکامېږي چې دلیل نه، بلکې ننوتنه نوموي. دلته دوه پټې خبرې دي او هر یو ته د unit له بیا پیل مخکې خپله لوستل کېدونکې سرچینه غواړي. لاندې تګلاره هغوی جلا کوي، بیا هغه پېژندنه ګوري چې واقعاً هره دوتنه پرانیزي.
دوه غوښتنې جلا کړئ
د کلي پټنوم سیمهایز شخصي کلي کوډ پرانیزي؛ د حساب معلومات د سرور سره ناسته تصدیقوي. هغوی له بېلابېلو ځایونو راځي، په بېلابېلو شیبو ناکامېږي او بېلابېل پیغامونه ورکوي. د هغوی ګډول خلک د پټنوم بیا تنظیم لټولو ته لېږي، حال دا چې حساب هېڅ نه و ښکېل. د هر انتخاب له بدلولو مخکې د غوښتنې متن ولولئ، ځکه چې کومه پټه خبره ورکه ده د دې یوازینی باوري نښه الفاظ دي.
په Community OpenVPN 2.x کې askpass هغه دوتنه نوموي چې د کلي پټنوم په لومړي کرښه کې لري، او auth-user-pass هغه دوتنه نوموي چې په یوه کرښه کې کارن نوم او په بله کرښه کې پټنوم لري. هېڅ یوه دوتنه بل انتخاب نه شي پوره کولی. د ډیسکټاپ اپلیکیشن یا NetworkManager پروفایل کېدای شي دواړه په خپل پټ ذخیره کې وساتي، چې د کمانډ کرښې کلینټ هېڅکله نه لولي، نو د هر لارې له لیکلو مخکې یادښت وکړئ چې کوم کلینټ تنظیموئ.
دواړه انتخابونه لوستل کېدونکو دوتنو ته وګرځوئ
هغه پروفایل چې دواړه ننوتنې غواړي په پای کې درې دوتنې حوالې لري: کوډ شوې کلي، هغه پټنوم چې خلاصوي یې او د ننوتلو جوړه. هغوی پرته له دې چې CA او پېژندنې ګوتې ووهئ ورزیات کړئ، ځکه هغوی ټاکي چې سرور څوک دی او د دې ستونزې برخه نه دي. که ځای پر ځای کول د حساب معلومات هېڅ نه کاروي، auth-user-pass ورزیاتول هغه ننوتنه جوړوي چې هېڅوک نه شي برابرولی.
key /etc/openvpn/client/office.key
askpass /etc/openvpn/client/office-key.pass
auth-user-pass /etc/openvpn/client/office-login.authبېدلیل انتخابونه له لارې لرونکو انتخابونو څخه بېل چلند کوي، او په خدمت کې دا توپیر مهم دی. بېدلیل askpass لا هم کنسول لولي، او یوه auth-user-pass دوتنه چې یوازې کارن نوم لري لا هم د پټنوم غوښتنه په تمه پرېږدي. کله چې کلینټ ډیمون شي له ټرمینل څخه ننوتنه هېڅ نه شي غوښتلی، نو په دې ډول تنظیم شوی خدمت نه پاڅي.
مطلقې لارې د کاري فولډر پوښتنه لره کوي خو لاسرسی نه ورکوي. بیا مالکیت، حالت او تېرېدل راځي، او درېواړه د هغه حساب پر وړاندې ګڼل کېږي چې پروسه ترې تېره ده.
د پروفایل مخکې د unit ترتیب ولولئ
دا unit، نه هغه دوتنه چې ترمیموله، ټاکي چې کوم ترتیب مثال باروي. د هغې کمانډ کرښه او هر drop-in ولولئ، بیا د کاري فولډر له لارې هغه پروفایل ته ورشئ چې واقعاً کارېږي. په بله .ovpn دوتنه کې ورزیات شوې پټنوم حواله د دې مثال لپاره هېڅ نه بدلوي.
درې یوازې لوستلو کمانډونه د دې ډېرو ته ځواب ورکوي. لومړی unit او هر drop-in چاپوي، دویم پېژندنه او هغه sandbox ترتیبات چې پروسه تړي، او درېیم دا چې وروستي پیل واقعاً له څه شکایت کاوه. په کوربه کې موجود د مثال نوم وکاروئ:
systemctl cat [email protected]
systemctl show [email protected] -p User -p Group -p WorkingDirectory -p ProtectHome
journalctl -u [email protected] -bProtectHome او د پروفایل خپلو user، group او chroot انتخابونو ته پام وکړئ. د کور فولډر لاندې دوتنه کېدای شي په خپل shell کې لوستل کېدونکې وي او کله چې کور فولډرونه پټ شي په خدمت کې ناڅرګنده شي. هغه حساب چې systemd پرې پیل کوي تل هغه حساب نه وي چې په پای کې کلي پرانیزي.
ثابت کړئ چې د چلېدو پېژندنه دواړه دوتنې پرانیستلی شي
یوازې حالت لوستل بس نه دي، ځکه په لاره کې هره فولډر باید د همدې پېژندنې لپاره تېرېدونکې وي. لاره برخه په برخه ووهئ، بیا هغه حساب چې پروسه کاروي پرې د پرانیستلو ازموینه وکړئ. د root په مالکیت او 600 حالت لرونکې دوتنه یوازې هغه مهال کار کوي چې پروسه لا root وي، او د ډېرو پروفایلونو د لاسرسی راټیټولو وروسته دا سم نه وي. دوه کمانډونه تېرېدل او پرانیستل دواړه پوښي:
namei -l /etc/openvpn/client/office-key.pass
sudo -u openvpn test -r /etc/openvpn/client/office-key.pass && echo readableلومړی کمانډ د هرې برخې حالت چاپوي او هلته ناکامېږي چې حساب نه شي تېرېدلی؛ دویم یوازیني مهم پوښتنې ته ځواب ورکوي، یعنې آیا د چلېدو پېژندنه دوتنه د لوستلو لپاره پرانیستلی شي. هېڅ یو یې د دوتنې منځپانګه نه چاپوي، او کله چې دوتنه پټنوم لري همدا اصلي خبره ده. د ننوتلو دوتنې لپاره هم ازموینه تکرار کړئ، ځکه دواړه ډېری وخت په بېلابېلو مالکیتونو ساتل کېږي.
که پروسه chroot یا محدود namespace کاروي، هماغه ازموینه د هغې صحنې له داخله وچلوئ، که نه ځواب غلط فایل سیستم بیانوي. د پټ کور فولډر لاندې ساتل شوی پټنوم د هغې ازموینې معمول بېلګه ده چې د unit څخه بهر بریالۍ او دننه ناکامېږي.
لومړی پیل وګورئ، بیا بیاځلی نښلول
مثال یو ځل پیل کړئ او لومړی ناکامي ولولئ نه وروستې. ورکه ننوتلو دوتنه، ناکامه کلي کوډ پرانیستنه او له سرور څخه AUTH_FAILED درې بېلې پېښې دي چې درې بېلې سمونې لري. د اجازې خبرداری سمول د دې په اړه هېڅ نه ثابتوي چې کلي خلاص شو که نه.
د ژورنال کرښه وایي چې له درېیو کومه حالت لرئ. سمون د دې له مخې راځي چې کومه ننوتنه ناکامه شوه:
| What the journal shows | Which input failed | Where to look |
|---|---|---|
| A path that cannot be opened | The file the profile names | Askpass or login path, and the unit's working directory |
| A key decryption error | The key passphrase | First line of the askpass file, and read access for the runtime identity |
AUTH_FAILED from the server | The account credentials | Login file contents, and whether the account is still valid |
بیا هغه ژوندلیک ازموئ چې واقعاً ورته اړتیا لرئ: په بوټ کې پیل او هر ملاتړ شوی بیاځلی نښلول، نه یوازې ستاسو له shell څخه لاسي پیل. د auth-nocache سره ننوتنې له لومړي کارولو وروسته غورځول کېږي، نو وروستنی بیاځلی نښلول لا هم لوستل کېدونکې سرچینه غواړي. هغه کلي زنځیر چې د ډیسکټاپ ننوتلو پر مهال خلاصېږي د هغه خدمت لپاره نشته چې له چا ننوتلو مخکې پیل شوی وي، او دا هغه معمول دلیل دی چې لاسي ازموینه بریالۍ او بیا پیل ناکامېږي. که لومړی پیل بریالی شو او وروستی بیاځلی نښلول ناکام شو، د اجازو له بیا بدلولو مخکې د بیاځلي نښلولو پېښې لپاره ژورنال ولولئ.
پټنوم د کلي ترڅنګ ساتل هغه څه کموي چې کوډ کول درکوي، نو هغه دوتنه او بیک اپونه یې محدود کړئ. د کلي پټنوم لره کول د ورکې ننوتنې سمون نه، بلکې جلا د اعتبار وړ پریکړه وګڼئ. هغه ځای پر ځای کول چې پر انساني تصویب یا متقابل MFA تکیه لري خپل ملاتړ شوی استازی یا مدیریت یوځایوالی غواړي؛ دایمي ساتل شوی یوځلي کوډ برابر بدیل نه دی.