إضافة مستخدم إلى مجموعة VPN لا تمنح الوصول بحد ذاتها
عضوية المجموعة شرط واحد لا إذن. راقب ما طابقته البوابة فعلاً، واقرأ سجل القبول أو الرفض، واختبر النتيجتين.
أضفت الحساب إلى المجموعة الصحيحة، ونجح تسجيل الدخول، ومع ذلك يُرفض الاتصال أو يتصل ولا يصل إلى شيء مفيد. الرد المعتاد إضافة المستخدم إلى مجموعات أكثر حتى يزول العطل، وهكذا تمنح المؤسسات صلاحيات أوسع بكثير مما طلبته التذكرة. عضوية المجموعة مُدخل واحد في قرار التفويض وليست القرار نفسه: تجمع البوابة بضعة حقائق عن الجلسة، وتطابقها مع سياسة مرتبة، ثم تقرر ما يجوز لتلك الجلسة الوصول إليه. وإذا فشل شرط آخر فإن تعديل المجموعة لا يغيّر شيئًا سوى سطح تعرضك.
عضوية المجموعة شرط لا إذن
في RADIUS تصل المجموعة كخاصية تفويض، والخصائص تصف الجلسة بدل أن تمنحها. يرد الخادم بـ Access-Accept أو Access-Reject؛ وعند القبول قد يضيف Filter-Id أو Class أو خصائص النفق من RFC 2868، ويفسرها جهاز الشبكة في الطرف الآخر كما يقرر مورده. لا شيء في البروتوكول يحوّل مجموعة إلى وصول كامل؛ هذا التحويل يكتبه من أعدّ السياسة على البوابة أو خادم الوصول للشبكة، وقد يكون ضيقًا كاستضافة واحدة.
لهذا يتصرف اسم مجموعة متطابق بشكل مختلف على نظامين. يبني Microsoft NPS سياسات الشبكة من شروط وقيود وإعدادات ويقيّمها بترتيب محدد. ولـ OpenVPN Access Server نموذج مجموعات وقواعد وصول خاص به، بينما يفوّض خادم OpenVPN المجتمعي السؤال كله غالبًا إلى سكربت client-connect أو ملف client-config-dir. كلها تستهلك مجموعة ولا تشترك في منطق أسبقية الآخر، فمجموعة قواعد منسوخة بينها لا تثبت شيئًا عن التي تصححها.
القاعدة التي طابقت هي التي تقرر، لا المجموعة التي توقعتها
تتوقف معظم المحركات عند أول سياسة مطابقة أو عند الأكثر تحديدًا. إذا رفضت السياسة 3 وسمحت السياسة 7، فقد تفشل الجلسة دون أن تصل إلى القاعدة التي كانت ستمررها. الترتيب إعداد حقيقي في NPS وفي معظم منتجات التحكم بالوصول، وهو ينزاح عبر السنوات: يرفع أحدهم سياسة رفض إلى الأعلى لاحتواء حادث غير مرتبط، فتتوقف مجموعة كانت تعمل في الربع الماضي.
الشروط التي تسير مع المجموعة هي النصف الآخر. حالة الجهاز وطريقة المصادقة وإتمام MFA وشبكة المصدر وموضوع الشهادة أو نافذة زمنية يمكن أن تكون كلها في السياسة نفسها. وعندما لا يتحقق أحدها لا تطابق السياسة، فيسقط المحرك إلى الرفض الافتراضي. من مقعد المستخدم يبدو الأمر كأن المجموعة تُجاهَل؛ ومن مقعد المحرك لم تُستشر المجموعة أصلًا.
تفاصيل الدليل تنتج الوهم نفسه. السياسة التي تطابق عضوية مجموعة Windows تقرأ SIDs في رمز المستخدم، ولا تُعدَّد هناك إلا مجموعات الأمان، أما مجموعة التوزيع فلا تظهر أبدًا. والمجموعة الأساسية تُحمل في حقلها الخاص لا في القائمة المعددة، لذا قد تفشل بصمت سياسة مثبتة عليها. والمجموعات المعاد تسميتها و SIDs عبر النطاقات تضيف خطوات ترجمة تفشل بهدوء عندما تكون الثقة أحادية الاتجاه.
اقرأ سجل القبول أو الرفض قبل أن تلمس أي مجموعة
اسأل سؤالًا واحدًا أولًا: هل وصل الطلب إلى مرحلة التفويض أصلًا؟ في 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، فإن Disconnect-Request أو CoA-Request إلى UDP 3799 يجبر الجلسة على إعادة التقييم؛ وإلا فافصل العميل ودعه يتصل من جديد. إعادة التفاوض تجدد مفاتيح النفق وتترك نتيجة التفويض عادة دون تغيير، لذا معاملتها كتحديث صلاحيات تعطي نتائج متناقضة.
أصلح الشرط لا المجموعة
متى عرفت السياسة التي عملت كان الإصلاح عادة صغيرًا: أعد ترتيب رفض يحجب السماح المقصود، أو أضف شرط الجهاز أو MFA المفقود إلى السياسة التي أردت مطابقتها، أو اكتب قاعدة ضيقة للمورد الواحد بدل ترقية المستخدم إلى مجموعة تحمل عشرة غيره. توسيع العضوية لإغلاق تذكرة هو النسخة المكلفة من الإصلاح نفسه.
حلقة قصيرة تحفظ التغيير نزيهًا:
- أعد إنتاج الرفض بالحساب الأصلي واكتب رقم الحدث قبل تغيير أي شيء.
- غيّر كائنًا واحدًا، ترتيب سياسة أو شرطًا واحدًا أو مجموعة واحدة، وسجّل أيهما.
- افتح جلسة جديدة وتأكد من ظهور المنح في السجل ومن أن المورد يُفتح فعلاً.
- اختبر مستخدمًا يجب أن يبقى مرفوضًا، حتى لا يكون الإصلاح قد وسّع السياسة بالخطأ.
إذا كان المنح صحيحًا والمورد لا يُفتح فقد انتقلت المشكلة إلى التوجيه أو تحليل الأسماء لحظة نجاح التفويض. أبقِ الفشلين منفصلين تصبح التذكرة التالية دقائق لا بعد ظهر كامل.