سياسة المجموعة في NPS ليست فرضًا لموارد VPN

مجموعتان، ملفّا وصول، بوابة VPN واحدة، وكلتا المجموعتين تنتهيان إلى الوصول إلى الخوادم نفسها. السبب المعتاد ليس سياسة معطوبة بل نصفًا ثانيًا مفقودًا من التصميم: فـ NPS يقرر من يجوز له إنشاء جلسة، وشيء آخر يجب أن يقرر ما يجوز لتلك الجلسة الوصول إليه. وعندما يوجد النصف الأول وحده، ينجح التصريح لكل من يصادق. السياسة تؤدي عملها، والتصميم لا يزال ناقصًا.

سياسة شبكة مطابِقة للمجموعة دليل على القبول. وليست دليلًا على الحزم، والفجوة بين هذين القولين هي حيث يحدث معظم هذا العمل.

اعثر على السياسة التي قبِلت الجلسة فعلًا

يقيّم NPS سياسات الشبكة المرتّبة، وتفوز أول قاعدة ممكّنة تتطابق شروطها. ويمكن أن تشمل الشروط عضوية مجموعة المستخدم أو الحاسوب، ونوع الاتصال، والوقت، وحالة الجهاز. لذا فإن سياسة واسعة موضوعة في وقت أبكر في القائمة تقبل اتصالًا قبل أن تُنظر أصلًا في قاعدة أضيق في موضع لاحق. الترتيب ليس تفصيلًا في الواجهة؛ إنه السياسة.

اقرأ القائمة بالترتيب وحدّد القاعدة التي طابقت، ثم سجّل أي الإعدادات أعادت. اسم المجموعة في المحرر ليس النتيجة؛ النتيجة هي التصريح الذي تلقّاه الخادم. أبقِ تصريح المستخدم وتصريح الجهاز منفصلين حيث يستخدم النشر كليهما، لأن حسابًا يجوز له فتح نفق ليس تلقائيًا حسابًا ينبغي أن يصل إلى كل خدمة داخلية.

ردّ RADIUS تعليمة وليس مرشّحًا

تحمل سمة Filter-Id اسم قائمة مرشّحات. وهي لا تنقل مجموعة محمولة من قواعد ترشيح الحزم يفهمها كل مستقبِل، وإرسال اسم لم تعرّفه البوابة قط لا يفرض شيئًا على الإطلاق. والتحذير نفسه ينطبق على سمات VLAN: فإسناد جلسة نفق إلى VLAN ليس بحد ذاته قاعدة وصول موجّهة لذلك المستخدم.

هنا يصمت تصميم يبدو مكتملًا على جانب NPS ويفعل لا شيء. تحقّق من وثائق مورّد البوابة أي سمات التصريح مدعومة وما يفعله المستقبِل بكل واحدة، بدلًا من افتراض أن اسم سمة قياسي يعني سلوكًا قياسيًا.

ضع الفرض حيث تمرّ حركة المرور

بوابة تعالج حزم المستخدم يمكنها تطبيق مرشّح لكل جلسة، أو ربط مجموعة بسياسة بوابة، أو منح الجلسة عنوانًا من تجمّع معزول يعالجه جدار الحماية بشكل مختلف. أي من هذه يمكن أن يعمل، وكل منها يفشل بطرق مختلفة. حدّد الآلية التي تدعمها بوابتك قبل كتابة السياسة التي تسمّيها. ثم اكتب ما يحدث للجلسة عند غياب تلك الآلية، لأن الصمت هو الوضع الافتراضي.

صِف الإذن المقصود في أربعة أجزاء: هوية المصدر أو المجموعة، والوجهة، والبروتوكول، والمنفذ. أضف الاعتماديات التي يحتاجها المستخدم فعلًا، مثل DNS أو خدمة مصادقة، وإلا فسيكسر التقييد مسارات تسجيل الدخول التي لم يفكر أحد في اختبارها. اكتب القاعدة مقابل الواجهة التي ترشّح فعلًا، لا مقابل الواجهة المفتوحة صدفة في المحرر.

ضَع في الحسبان الترجمة أيضًا. إذا رأى جدار حماية لاحق عنوان مصدر واحدًا مترجمًا لكل مستخدمي النفق، فلن يستطيع تمييز الأفراد من ذلك العنوان وحده، والقاعدة المكتوبة كما لو كان قادرًا ستكون عديمة الفائدة أو واسعة أكثر من اللازم.

ملفات تعريف العميل تعيش على الجانب غير الموثوق

يمكن لملف تعريف VPN مُدار أن يدفع مسارات، أو قواعد نفق منقسم، أو مرشّحات تطبيقات، وهي تشكّل سلوك جهاز حسن التصرف. وهي ليست حماية للخدمة، لأن العميل هو الطرف الذي تحاول تقييده. وإزالة مسار في ملف تعريف ليست تصريحًا أيضًا، لأن العميل قد يكون لديه طريق آخر إلى الوجهة نفسها.

تعامل مع إعدادات العميل كوسيلة راحة وإعدادات البوابة كضبط. وعندما يختلف الاثنان، تكون البوابة محقة لأنها هي التي ترى الحزم.

اقبل بحسابين، ثم تتبّع بالترتيب

أنشئ حسابين عاديين للاختبار بصلاحيات مقصودة مختلفة، وأنشئ جلسات جديدة، وافحص سياسة البوابة الفعّالة لكل منهما. ثم اختبر عملية مسموحة غير مؤذية وموردًا مرفوضًا تحديدًا. فشل ping يثبت القليل جدًا بمفرده، لأن ICMP قد يكون مرشّحًا بينما خدمة TCP خلفه تجيب بسعادة.

عندما يحصل الحسابان معًا على وصول واسع، تتبّع بترتيب ثابت: أي سياسة طابقت، وأي تصريح حمله الرد، وما فعلت البوابة به. إن إضافة سمات NPS أكثر قبل التأكد من أن المستقبِل ينفّذها هي الطريقة التي تتحول بها مشكلة تصريح صغيرة إلى نافذة تغيير بلا نتيجة.