OpenVPN PAM: د login استدلال یوه خدمت دی، نه کارن

په سرور کې کارن اضافه شو، پټنوم سم ټایپ شو، خو اړیکه بیا هم د AUTH_FAILED سره پای ته رسېږي۔ معمولاً د پلگ ان کرښه لامل روښانه کوي: د پلگ ان لارې وروسته کلمه د PAM خدمت نوم دی، او هغه څه چې ټاکي کومه ماډیول ټولګه دې پوښتنې ته ځواب ووایي۔ دا کارن نوم نه دی، او نه د هغه پټنوم فایل ته اشاره ده چې OpenVPN پخپله لولي۔

دوهمه کلمه څه غوره کوي

د تنظیماتو کرښه یوه پلگ ان لار او یو استدلال اخلي:

plugin /usr/lib/openvpn/plugins/openvpn-plugin-auth-pam.so openvpn

هغه استدلال د خدمت نوم په توګه PAM کتابتون ته ورکول کېږي، نو ځکه په /etc/pam.d/openvpn کې سټک چلیږي۔ هلته login ولیکئ او پر ځای به یې د متقابلې ننوتنې تګلاره پلي شي، د هغو ماډیولونو سره چې هغه تګلاره ستاسو په وېش کې رانغاړي۔

د نصب شوي بستې ورکړل شوې پلگ ان لار وکاروئ، نه له بل کوربه کاپي شوې لار۔ د فایل نوم او لړلیک د وېشونو ترمنځ توپیر لري، او غلطه لار د تصدیق پر مهال نه، بلکې په پیل کې د پلگ ان د بارولو د تېروتنې سره ناکامه کېږي۔

سټک په رښتیا حسابونه له کومه ځایه لولي

PAM یو لېږدوونکی دی۔ د خدمت فایل ماډیولونه په ترتیب سره لیستوي، او لومړی هغه چې ځواب ویلای شي پایله ټاکي۔ هغه سټک چې pam_unix غواړي ځایي حسابونه لولي؛ هغه سټک چې LDAP یا RADIUS ماډیول غواړي اعتبارونه بشپړ بل ځای ته لېږي۔

هغه فایل ولولئ چې د خدمت نوم ورته حل کېږي، پشمول هر هغه څه چې رانغاړي:

cat /etc/pam.d/openvpn
grep -H pam_ /etc/pam.d/openvpn /etc/pam.d/common-auth

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

یوه هڅه، دوه لاګونه

یوه ناکامه اړیکه له دواړو خواوو سره وتړئ او وګورئ۔ د OpenVPN لاګ د پلگ ان پایله او د کليانټ رد ښيي؛ د سیستم د تصدیق لاګ ښيي کوم ماډیول وچلو او څه یې پرېکړه وکړه۔ دواړه په یوه وخت کړکۍ کې لوستل هغه څه دي چې ورک شوی د خدمت فایل د بیکنډ د وخت له تېرېدو جلا کوي۔ که د تصدیق په لاګ کې تشه وي، مانا دا ده چې سټک ته هېڅ ونه رسېدل۔

journalctl -u openvpn-server@server --since "-2 min"
journalctl -t sshd -t sudo --since "-2 min"

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

pamtester openvpn alice authenticate

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

ځانګړې خدمت د login له سمونې غوره دی

VPN ته خپل د خدمت فایل ورکړئ کله چې غوښتنې یې له متقابلې ننوتنې توپیر ولري، چې معمولاً لري۔ د login یا common-auth سمول د هر هغه پروګرام تګلاره بدلوي چې دوی رانغاړي، او بل څوک چې له دې سره بې تړاوه د ننوتنې ستونزه ډیبګ کوي ستاسو بدلون به میراث وړي۔

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

کليانټ څه لېږي، او څه نه لېږي

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

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

منل دوه اړخیز دي: ټاکل شوی حساب بریالی کېږي، او هغه حساب چې باید رد شي لا هم ناکامېږي۔ د auth-pam پلگ ان README د خدمت استدلال او هغه بیکنډونه تشریح کوي چې کولای شي مخې ته یې کړي، او هغه ځای چې ستاسو د جوړولو ترتیب باید تایید شي همدا دی۔