رفض تحديد الموقع في Firebox: حدد مرحلة دخول VPN أولًا

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

الفحص 1: سمِّ الخدمة القادمة

بالنسبة إلى Mobile VPN مع SSL وAccess Portal وBOVPN عبر TLS، فإن الدخول القادم هو سياسة WatchGuard SSLVPN. طبّق القيد المقصود هناك، على الخدمة المُهيأة فعليًا، بدلًا من استنتاجه من قاعدة وصول مستخدم تعمل لاحقًا.

يسلك IPsec مسارًا مختلفًا. تسمح سياسة IPSec المدمجة بحركة IPsec الخارجية إلى Firebox لخدمات الفرع وVPN المحمولة المعنية، وهي تتقدم على سياسة IPSec المُنشأة يدويًا. إذا كان عميلك IKEv2 فأنت في ذلك المسار الثاني، وسياسة SSLVPN غير ذات صلة.

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

الفحص 2: اقرأ الرفض، لا النظرية

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

يتبع تصنيف البلد المصدر الشبكي المرصود. يمكن لمستخدم متجول أو NAT في المنبع أو مسار معتمد مختلف أن يغيّر ما يراه Firebox، لذا تحقق من العنوان لا من وصف المستخدم لمكانه. اطلب العنوان العام الذي يراه العميل، وقارنه بالمصدر في سجل Firebox. وعند اختلافهما، فإن التصنيف يتبع مسارًا لم يذكره أحد.

الفحص 3: هل لا تزال السياسة المدمجة هي المالك؟

إذا بدت سياسة IPSec اليدوية مُتجاهَلة، فتحقق مما إذا كانت المدمجة ما تزال مُفعّلة. القاعدة اليدوية التي تحجبها قاعدة مدمجة ذات أولوية أعلى، والقاعدة اليدوية التي هي القبول الوحيد، هما تهيئتان مختلفتان بواجهة متشابهة.

قرر أي واحدة تريد أن تملك المسار. فإن كانت السياسة اليدوية، فيجب تعطيل المدمجة لتلك الحركة، ومن هنا يبدأ الفحص التالي.

الفحص 4: خطط للبديل قبل التعطيل

تعطيل سياسة IPSec المدمجة يزيل قبولها لخدمات VPN المتأثرة. ويشمل ذلك أنفاق الفروع التي قد لا تفكر فيها أثناء إصلاح اتصال مستخدم محمول واحد.

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

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

الفحص 5: افصل الهوية عن الموقع

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

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

الفحص 6: سجّله وتحقق من كلا المسارين

دوّن الخدمة، وسياسة الدخول، ونطاق الموقع المقصود، والاستثناءات، ومسؤول الاستعادة. ثم اختبر المسار المحمول ومسار موقع واحد على الأقل بعد التغيير، ليبقى القيد مرتبطًا بالخدمة التي صُمم لضبطها.

أخيرًا، أعد قراءة الرفض الذي بدأت به. إذا تحوّل من رفض موقع إلى فشل مصادقة أو تفويض، فقد حُلّت مشكلة الدخول وصارت مشكلة أخرى ظاهرة. إرشادات WatchGuard لرفض IKEv2 هي المرجع لترتيب المراحل الموصوف أعلاه.