کسی صارف کو VPN گروپ میں شامل کرنا بذات خود رسائی نہیں دیتا
گروپ کی رکنیت ایک شرط ہے، اجازت نہیں۔ دیکھیں گیٹ وے نے اصل میں کیا ملایا، قبولیت یا رد کا ریکارڈ پڑھیں اور دونوں نتائج آزمائیں۔
اکاؤنٹ درست گروپ میں ہے، لاگ ان کامیاب ہوا، پھر بھی کنکشن مسترد ہوتا ہے یا کسی مفید چیز تک نہیں پہنچتا۔ گروپ بڑھاتے جانا ٹکٹ کی طلب سے زیادہ حقوق دے دیتا ہے۔ رکنیت محض ایک ان پٹ ہے، فیصلہ نہیں: گیٹ وے حقائق کو ترتیب شدہ پالیسی سے ملاتا ہے اور پھر فیصلہ کرتا ہے۔ اگر کوئی دوسری شرط ناکام ہو تو گروپ صرف نمائش بدلتا ہے۔
گروپ کی رکنیت شرط ہے، اجازت نہیں
RADIUS میں گروپ اجازت کی خصوصیت کے طور پر آتا ہے اور سیشن بیان کرتا ہے، اجازت نہیں دیتا۔ سرور Access-Accept یا Access-Reject جواب دیتا ہے اور Filter-Id، Class یا RFC 2868 کے ٹنل خواص شامل کر سکتا ہے۔ کوئی چیز گروپ کو مکمل رسائی نہیں بناتی؛ یہ نقشہ پالیسی بنانے والا لکھتا ہے۔
اسی لیے ایک ہی گروپ نام دو نظاموں میں مختلف برتاؤ کرتا ہے۔ Microsoft NPS شرطوں، حدود اور ترتیبات سے پالیسیاں بناتا اور مقررہ ترتیب میں جانچتا ہے۔ OpenVPN Access Server کا اپنا ماڈل ہے، اور کمیونٹی سرور عموماً سب کچھ client-connect یا client-config-dir کے سپرد کرتا ہے۔
فیصلہ ملنے والے قاعدے کا ہوتا ہے، توقع کے گروپ کا نہیں
زیادہ تر انجن پہلی ملنے والی پالیسی یا سب سے مخصوص پر رک جاتے ہیں۔ اگر پالیسی 3 رد کرے اور پالیسی 7 اجازت دے تو سیشن اس قاعدے تک پہنچنے سے پہلے ناکام ہو سکتا ہے۔
گروپ کے ساتھ چلنے والی شرطیں دوسرا نصف ہیں: ڈیوائس کی حالت، تصدیق کا طریقہ، مکمل MFA، ماخذ نیٹ ورک، سرٹیفکیٹ کا موضوع یا وقت کی کھڑکی۔ ایک بھی پوری نہ ہو تو پالیسی نہیں ملتی اور طے شدہ رد لاگو ہوتا ہے۔
ڈائریکٹری کی تفصیلات بھی وہی فریب بناتی ہیں۔ Windows گروپ رکنیت پر ملنے والی پالیسی ٹوکن میں SID پڑھتی ہے، وہاں صرف سیکیورٹی گروپ درج ہوتے ہیں؛ تقسیمی گروپ کبھی نظر نہیں آتا۔
گروپ کو چھونے سے پہلے قبولیت یا رد کا ریکارڈ پڑھیں
پہلے ایک سوال: کیا درخواست اجازت کے مرحلے تک پہنچی؟ NPS میں 6272 دی گئی رسائی، 6273 رد اور 6274 وہ درخواست درج کرتا ہے جو پالیسی جانچ سے پہلے پھینک دی گئی۔ یہ تین نمبر مسئلے کو تین تحقیقات میں بانٹتے ہیں، صرف ایک گروپوں کے بارے میں ہے۔
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
جب ریکارڈ دستیاب نہ ہو تو سرور سے براہ راست پوچھیں اور جواب پڑھیں۔ Filter-Id اور ٹنل خواص کے بغیر جواب کا مطلب ہے کہ سرور سیشن کو معمولی سمجھتا ہے اور گیٹ وے اپنے قواعد لگاتا ہے۔
radtest alice 'password' 10.0.0.5 0 testing123واپس آئے خواص کا موازنہ گیٹ وے کی دستاویز کردہ خصوصیات سے کریں، گروپ نام کے اشارے سے نہیں۔ یہ پالیسی کے مسئلے کو نفاذ کے مسئلے سے الگ کرتا ہے۔
گروپ کی تبدیلی پچھلی تاریخ پر لاگو نہیں ہوتی
اجازت کے خواص ایک بار واپس آتے ہیں، سیشن کی تصدیق کے وقت۔ گیٹ وے انہیں سیشن پر رکھتا ہے اور ہر پیکٹ کے لیے ڈائریکٹری دوبارہ نہیں پڑھتا، اسی لیے قائم سیشن کسی کو گروپ سے نکالنے کے بعد بھی چلتا رہتا ہے۔
تبدیلی کے مؤثر ہونے کے لیے نیا اجازت کا فیصلہ درکار ہے، صرف نئی چابیاں نہیں۔ جہاں سرور RFC 5176 حمایت کرتا ہے، UDP 3799 پر Disconnect-Request یا CoA-Request دوبارہ جانچ پر مجبور کرتا ہے۔
شرط درست کریں، گروپ نہیں
جب معلوم ہو جائے کہ کون سی پالیسی چلی، مرمت عموماً چھوٹی ہوتی ہے: مطلوبہ اجازت کو ڈھانپنے والے رد کی ترتیب بدلیں، گمشدہ ڈیوائس یا MFA شرط شامل کریں، یا ایک وسیلے کے لیے تنگ قاعدہ لکھیں۔
مختصر چکر تبدیلی کو دیانت دار رکھتا ہے:
- اصل اکاؤنٹ سے رد دہرائیں اور کچھ بدلنے سے پہلے واقعہ ID لکھ لیں۔
- صرف ایک چیز بدلیں: پالیسی ترتیب، ایک شرط یا ایک گروپ، اور لکھیں کون سی۔
- نیا سیشن کھولیں، تصدیق کریں کہ اجازت ریکارڈ میں نظر آتی ہے اور وسیلہ واقعی کھلتا ہے۔
- ایسے صارف کی جانچ کریں جسے اب بھی رد ہونا چاہیے، تاکہ مرمت نے پالیسی کو نہ بڑھایا ہو۔
اگر اجازت درست ہے اور وسیلہ پھر بھی نہیں کھلتا، تو اجازت گزرتے ہی مسئلہ روٹنگ یا نام کے حل کی طرف منتقل ہو گیا ہے۔ دونوں خرابیوں کو الگ رکھیں۔