OpenVPN auth-user-pass: فایل، stdin که غوښتنه؟ څنګه انتخاب کړو

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

درې شرایط چې دا ټاکي

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

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

• انسان د کنسول مخې ته، هیڅ اتوماتیک کول نشته: متقابله غوښتنه۔
• پرته له څارنې پیل، راز کولی شي ذخیره شي: د 0600 حالت سره د اعتبارنامې فایل۔
• پرته له څارنې پیل، راز نشي ذخیره کیدلی: د پروسې بدلون یا fd چې د راز استازی ورته لیکي۔
• بله پروسه د کلاینټ مالک ده: د مدیریت انٹرفیس۔

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

هر د ننوتلو لاره په حقیقت کې څه کوي

--auth-user-pass یوازې د کنسول پر مخ کارن نوم او پاسورډ غواړي۔ کله چې د فایل نوم ورکړل شي، کلاینټ لومړنۍ کرښه د کارن نوم او دوهمه کرښه د پاسورډ په توګه اخلي؛ هیڅ شی د نقل قول، تبصرې یا کیلي-ارزښت ترکیب ملاتړ نه کوي۔ دا ټول بڼه ده، نو هر څوک چې د INI فایل په تمه یې سمون کوي هغه ماتوي۔ د <auth-user-pass> انلاین بلاک په پروفایل کې هماغه دوې کرښې ساتي، چې پروفایل پخپله راز جوړوي او د خصوصي کیلي سره په یوه ډول د سمون ټولګي کې یې ږدي۔

نورې دوې لارې جریان او سوکټ دي۔ OpenVPN یوازې د لوستلو وړ فایل ډیسکریپټر ته اړتیا لري، نو دا به د پروسې بدلون، د پایپ ملاتړ شوې /dev/fd ننوتنه یا هغه فایل نوم چې واقعاً FIFO دی ومني۔ د مدیریت انٹرفیس په طبیعت کې توپیر لري: کلاینټ د دې پر ځای چې ارزښتونه پخپله ولولي، له څارونکې پروسې څخه غواړي۔ دا توپیر د بیا نښلولو پر مهال مهم دی: د اعتبارنامې فایل، هغه FIFO چې د راز مرستندوی کولی شي بیا ورته ولیکي، او د مدیریت انٹرفیس کولی شي پرته له انسان بیا چمتو کړي؛ د پروسې بدلون نشي کولی، ځکه چې ډیسکریپټر په لومړي لوستلو کې مصرف کیږي۔

فایل باید په دقیق ډول دوې کرښې وي

دوه د ناکامۍ حالتونه ډېری مات شوي د اعتبارنامې فایلونه پوښي۔ د Windows سمونگر CRLF پایونه پریږدي، د کارېج بیرته راستنیدنه د پاسورډ برخه کیږي، او سرور هغه ارزښت ردوي چې په سکرین سم ښکاري۔ تشه دوهمه کرښه - هغه ځای کې تشه کرښه چې پاسورډ باید وي - کلاینټ په تش پاسورډ سره پریږدي، چې سرور یې ردوي که څه هم په سکرین کې ارزښت سم ښکاري۔ د پاسورډ وروسته اضافي نوې کرښه بې زیانه ده۔ فایل د shell څخه ولیکئ نه د سمونگر څخه، او بایټونه وګورئ:

install -m 600 /dev/null /etc/openvpn/client.creds
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client.creds
od -c /etc/openvpn/client.creds | head -3

لاره د منځپانګې په څیر مهمه ده۔ نسبي لاره د پروسې د کاري لیست پر بنسټ حل کیږي، کوم چې د یوې خدمت لپاره په ندرت سره هغه لیست وي چې تاسو پکې ازموینه کړې۔ مطلق لاره وکاروئ، فایل د هغه حساب ملکیت کړئ چې کلاینټ چلوي، او 0600 حالت وساتئ تر څو ګروپ او نور یې ونه لولي۔ د OpenVPN 2.6 لارښود د لارښوونې منل شوې بڼې لیستوي؛ مخکې له دې چې دریمه جوړه کړئ هغه وګورئ۔

سرور تورن کولو دمخه فایل وازموئ۔ د openvpn --config client.ovpn --auth-user-pass /etc/openvpn/client.creds --verb 4 چلول چاپوي چې فایل پرانیستل شو که نه او وروسته چې اعتبارنامه ومنل شوه که نه، کوم چې تاسو ته وایي بل څه پوړ بدل کړئ۔

جریانونه، stdin او هغه تېروتنې چې دوی یې تولیدوي

پاسورډ پایپ ته ورکول لومړنی شی دی چې ډېری خلک یې هڅه کوي او تر ټولو ډېر حیرانتیاوې لري۔ د پروسې بدلون کار کوي ځکه چې کلاینټ یوازې د لوستلو وړ ډیسکریپټر ته اړتیا لري: openvpn --config client.ovpn --verb 3 --auth-user-pass <(printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS")۔ /dev/stdin لیږل یوازې هغه وخت کار کوي چې stdin د کلاینټ د پوښتنې په شېبه کې لا پرانیستی او د لوستلو وړ وي، کوم چې په هغه پایپ کې سم نه دی چې لا دمخه یې مصرف کړی دی۔

ERROR: could not read Auth username from stdin دوه جلا لاملونه لري۔ په ځینو 2.3.x کلاینټونو کې پیغام د stdin د سمون نیمګړتیا څخه راغی چې وروستیو 2.3 خپرونو سمه کړه، نو دومره زوړ کلاینټ یوازې د لوړولو له لارې ښه کیږي۔ په اوسني کلاینټ کې هماغه عبارت معنا لري چې کلاینټ د کنسول ننوتنه غوښتې وه او stdin ټرمینل نه و - په دقیق ډول هغه حالت چې په systemd واحد، cron دنده یا پرته له -t پیل شوي کانټینر کې وي۔

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

د مدیریت انٹرفیس کله چې غوښتنه بله پروسه لري

هغه کنټرولر چې لا دمخه د تونل څارنه کوي کولی شي د هغې پوښتنو ته هم ځواب ووايي۔ کلاینټ د --management 127.0.0.1 7505 سره پیل کړئ، د حالت کرښې ولولئ، او >PASSWORD:Need 'Auth' username/password ته پام وکړئ۔ کنټرولر په جلا کمانډ کرښو کې د username "Auth" alice او بیا د password "Auth" ... سره ځواب وایي۔ 'Auth' ټوکن د غوښتنې پیژندونکی تکراروي او باید سره سمون ولري، که نه ځواب له پامه غورځول کیږي او کلاینټ انتظار کوي۔

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

ناکامۍ چې د اعتبارنامې د ستونزې په څیر ښکاري

هغه TLS لاس ورکول چې هیڅکله بشپړ نه شي، یا VERIFY ERROR: depth=0, error=certificate signature failure، د باور ستونزه ده او مخکې له دې چې کوم کارن نوم لوستل شي پیښیږي۔ د UDP اوریدونکي ته متوجه proto tcp کلاینټ په هماغه ځای کې ناکام کیږي: بسته ګانې هیڅکله د تصدیق مرحلې ته نه رسیږي، نو هر پاسورډ د تړاو له امله غلط ښکاري۔ د اعتبارنامې لیږلو دمخه د سند تصدیق فعال وساتئ؛ یوه اشنا غوښتنه د دې په اړه هیڅ نه وایي چې پاسورډ څوک ترلاسه کوي۔ د اعتبارنامې لمس کولو دمخه د سند زنځیر، عمومي نوم او ترانسپورت وګورئ۔

په هغه سکریپټ کې shell تېروتنې چې پروفایل جوړوي بله جعلي نښه ده۔ په [ ! -f "$file" ] دننه ورکه شوې تشه command not found تولیدوي، سکریپټ ژر بندیږي، پروفایل هیڅکله بیا نه جوړیږي، او کلاینټ د مخکیني سره پیل کیږي۔ هغه تېروتنه د shell ده، نه د تصدیق، او هر څومره چې پاسورډ بیا ولیکئ هغه نه پاکیږي۔

په دې جریان کې هره غوښتنه دا اعتبارنامه نه ده۔ د خصوصي کیلي پاسفریز، د HTTP پراکسي ننوتنه او د خدمت پاسورډ په بېلو مرحلو کې غوښتل شوي درې بېل رازونه دي، او د کیلي پاسفریز معمولاً auth-user-pass نه بلکې کلاینټ یا استازی سمبالوي۔ که غوښتنه مخکې له دې چې TLS ناسته جوړه شي ښکاره شي، تاسو غلطې پوښتنې ته ځواب ورکوئ او هیڅ حساب بیا تنظیمول به مرسته ونه کړي۔ کله چې غلطه غوښتنه لرې شوه، پاتې څیړنې له تر ټولو لومړني پوړ څخه پیل کیږي:

• لومړنۍ پروتوکول تېروتنه ولولئ، نه وروستې اعتبارنامې کرښه: TLS، بیا تصدیق، بیا push۔
• تایید کړئ چې فایل دوې کرښې دی، کارېج بیرته راستنیدنې نلري، او د مطلق لارې له مخې یاد شوی دی۔
• تایید کړئ چې پروفایل او کمانډ کرښه د لارښوونې په اړه اختلاف نلري۔
• "اعتبارنامه ومنل شوه" له "ترافیک بهیږي" وروسته جلا کړئ - لارښوونه او DNS وروستی پوړ دی۔

کله چې کلاینټ push مرحلې ته ورسیږي، د اعتبارنامې کتلو ته ودریږئ او هغه لارې او DNS سرورونه لوستل پیل کړئ چې سرور لیږلي دي۔ هغه بله ستونزه ده، او د هغه پاسورډ سره چې همدا اوس سم کړی هیڅ تړاو نلري۔