د PAM پالیسۍ سره د OpenVPN ننوتنې یوې ډلې ته محدودې کړئ

هر حساب دې په نورمال ډول ننوتلی شي، خو یوازې یوه ډله دې VPN وکاروي۔ PAM کولای شي دا توپیر پرته له دویمې پټنوم زېرمې بیان کړي، او د OpenVPN پلگ ان کولای شي هغې خدمت ته واستول شي چې یوازې هغه کتنې لري چې تاسو یې غواړئ۔ هنر دا دی چې هغه خدمت جوړ کړئ پرته له دې چې په ناڅاپي ډول د سیستم په کچه سټیک په میراث واخلئ۔

دلته سفر د پلگ ان د خدمت له نوم څخه پیلېږي، پالیسي جوړوي او بیا درې مهمې پایلې آزمويي: غړی، د باوري پټنوم سره بهرنی کس او خراب اعتبار۔

ولې جلا PAM خدمت

auth-pam پلگ ان د خپل دلیل په توګه د خدمت نوم اخلي۔ هغه نوم /etc/pam.d لاندې یوه فایل غوره کوي، او په هغه فایل کې سټیک هغه څه دي چې د VPN ننوتلو پر مهال چلیږي۔ که تاسو هغه نوم ورکړئ چې د سیستم په کچه ننوتل یې کاروي، تاسو په هغه سټیک کې هر پرېکړه په میراث واخلئ، په شمول هغه چې وروسته د بې اړیکې دلیلونو له مخې اضافه شوي۔

پرځای یې ځانګړی خدمت جوړ کړئ۔ له یو فعال سټیک څخه پیل وکړئ چې دمخه د مطلوب backend په وړاندې تصدیق کوي، لکه یو ځایي پټنوم فایل، SSSD یا د لارښود خدمت، بیا د وړتیا قاعده اضافه کړئ۔ دوه کرښې په خالي فایل کې کاپي کول عامه تېروتنه ده: د پټنوم پای، د حساب قفل او نورې کتنې ممکن په هغه سټیک کې وي چې تاسو کاپي نه کړی۔

د خدمت جلا کول د زیان حد هم محدودوي۔ یوازې VPN لپاره قاعده په شریک سټیک کې کولای شي هرچا ته SSH یا کنسول لاسرسی رد کړي، چې د لاسرسي بدلون په خنډ بدلوي۔

د ډلې قاعده لیکل

د وړتیا کتنه د حساب مرحلې ته اړه لري، وروسته له دې چې اعتبار تصدیق شي۔ د account required pam_succeed_if.so user ingroup vpnusers په څېر قاعده یوازې هغه وخت د پروسس د دوام اجازه ورکوي چې تصدیق شوی کاروونکی د هغې ډلې غړی وي۔

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

د عادت له مخې use_uid مه اضافه کوئ۔ پرته له دې ماډل تصدیق شوي کاروونکی ارزوي؛ له دې سره ماډل هغه حساب ارزوي چې د OpenVPN پروسه ترې چلیږي، چې معمولاً root یا د خدمت حساب دی او نو هغه کس نه دی چې ننوځي۔

د ډلې غړیتوب د سیستم د هویت حل څخه راځي، نه له هغه نوم څخه چې تاسو پېژنئ۔ د لارښود کاروونکو لپاره، تایید کړئ چې هماغه backend د هغه کاروونکي د ډلې پوښتنو ته ځواب وایي، ځکه چې د پېژندل شوي نوم سره ځایي ډله د هماغه نوم د لارښود ډلې څخه بېله شی ده۔

د ترتیب او هویت تله

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

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

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

د غړو، بهرنیو او غلطو پټنومونو آزموینه

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

د پیرودونکي لپاره لیدل کېدونکې تېروتنه او د سرور لاګ یوځای وګورئ، ځکه چې دواړه ناکامۍ نښلوونکي کس ته ورته ښکاري۔ دا توپیر د ملاتړ لپاره مهم دی: د سم پټنوم سره بهرنی کس ته د ډلې بدلون ته اړتیا ده، پداسې حال کې چې غلط پټنوم د اعتبار بیا تنظیم غواړي۔

د PAM د سمون پر مهال دویمه ناسته پرانیستې وساتئ، او له بدلون وروسته نورمال SSH ننوتل هم تایید کړئ۔ د ځانګړي خدمت هدف دا دی چې سیستمي ننوتل باید بې اغېزې پاتې شي، او د دې پوهېدو یوازینۍ لاره ازموینه ده۔

که یو څه مات شي، پخوانی د خدمت فایل له یوې کاپي څخه بحال کړئ۔ غوښتل شوې قاعده بیانول اسانه دي: غړیتوب حساب د VPN لاسرسي لپاره وړ کوي، او نورې هرې اړینې کتنې لا هم پلي کېږي۔