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 سروس دلیل اور وہ بیک اینڈ بیان کرتا ہے جو یہ سامنے رکھ سکتا ہے، اور جو ترتیب آپ بنانا چاہتے ہیں اس کی تصدیق کی جگہ وہی ہے۔