‏Always On VPN ليس وصولاً إلى الشبكة المحلية: قائمة تحقق للموارد

‏Always On هو دورة حياة اتصال: يتصل الملف الشخصي عند تسجيل الدخول أو قبله، ويعيد الاتصال دون أن يضغط المستخدم أي شيء. وهذا لا يعني أن كل وجهة خاصة وكل بروتوكول وكل مستخدم مسموح به. السؤال العملي هو أي الموارد يقدمها الملف المنشور فعلياً، وتلك الإجابة تحتاج إلى فحص لكل مورد بدلاً من النظر إلى شارة الاتصال.

الخطوة 1: اكتب المورد قبل اختباره

ابدأ بسجل قصير لكل تطبيق، مأخوذ من البيئة الحقيقية: الاسم، بادئة الوجهة، الخدمة والمنفذ، دور النفق، مجموعة الهوية، ومسار المحلِّل.

Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNS

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

الخطوة 2: حدد أي نفق يجب أن يحمله

‏Windows Always On VPN فيه نفق جهاز ونفق مستخدم، ويُضبطان كملفين منفصلين بشهادات ونطاقات منفصلة. نفق الجهاز يحمل عادة البنية التحتية اللازمة قبل تسجيل الدخول فقط، مثل الإدارة وخدمات النطاق؛ أما وصول الموظفين الواسع إلى التطبيقات فيخص نفق المستخدم.

مرشحات الحركة ميزة في نفق الجهاز، ولهذا يستخدمها مثال مايكروسوفت لحركة الإدارة. ونسخ ذلك المثال إلى ملف عام للوصول إلى الموارد يعطيك نفقاً يتصل لكنه يحمل المجموعة الخطأ. تحقق من الاتصال النشط بـ Get-VpnConnection واختبر عبر ذلك الاتصال.

الخطوة 3: تحقق من المسار الخاص بالعنوان الحقيقي

حل الاسم مرة واحدة، ثم افحص المسار: Find-NetRoute -RemoteIPAddress 10.20.5.10 يوضح الواجهة المختارة والخطوة التالية وعنوان المصدر. فإن كانت الواجهة هي المحول الفيزيائي، فالبادئة غير موجودة في مجموعة مسارات النفق، أو أن العميل استبعدها عبر الأنفاق المنفصلة. قارن بتعريف الملف بدلاً من إضافة مسار محلي أمامه.

قد يجعل route add المحلي الاختبار ينجح ثم يختفي عند تحديث السياسة التالي، لذلك تنتمي التغيير إلى الملف المُدار. افحص البادئة في ملفي المستخدم والجهاز، وافحص إعداد النفق المنفصل: النفق الكامل لا يحتاج مساراً لكل بادئة، والنفق المنفصل يحتاج مساراً لكل بادئة خاصة يحملها.

الخطوة 4: اختبر حل الأسماء الخاصة بشكل منفصل

الأسماء الخاصة مسار سياسة قائم بذاته. يمكن للملف أن يقدم قواعد NRPT وقائمة لاحقات DNS، وهي سارية ما دام النفق متصلاً. اقرأ بـ Get-DnsClientNrptPolicy ما تلقاه العميل فعلاً، ثم اختبر اسماً وعنواناً في الجلسة نفسها. فشل الأسماء مع نجاح العنوانات يشير إلى مسار المحلِّل، وفشل الاثنين يشير إلى المسار.

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

الخطوة 5: افحص المرشحات والهوية وبوابة التطبيق نفسه

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

غيّر الملف المُدار عبر مالكه، سواء كان Intune أو نشر ProfileXML أو سكربتاً لفريق العمليات، ثم أعد الاختبار بعد إعادة اتصال عادية وبعد إعادة تشغيل، لأن العطل المعتاد مسار محلي قديم أو ملف طُبق مرة واحدة. أبقِ إصدار الملف بجانب نتيجة الاختبار.