لماذا يبقى محوّل VPN لديك على ملف تعريف جدار الحماية العام
تسجيل الدخول إلى نطاق لا يصنّف الشبكة كنطاق، كما أن «خاص» ليس بديلاً. اقرأ ملف تعريف القاعدة، ثم الجهاز الذي يفرضها.
النفق قائم، والحساب قد تمت مصادقته على النطاق، ومع ذلك ما زال Windows يصنّف الاتصال كعام. لذا لا تُطبَّق قاعدة جدار الحماية المكتوبة لملف تعريف النطاق، ويبقى المجلد المشترك غير قابل للوصول. والمحاولة المعتادة للإصلاح هي ضبط المحوّل على «خاص»، وهذا يغيّر القواعد التي تُطبَّق دون أن يغيّر أي شيء في المصادقة. وهناك سوء فهم واسع لكل من التسمية والإصلاح، والفصل بينهما يتطلب ثلاثة أوامر.
الحساب الذي اتصل ليس فئة الشبكة
يحدث قراران مختلفان أثناء اتصال VPN، ويسهل الخلط بينهما. البوابة تقرر ما إذا كان الحساب مسموحًا له بالاتصال. أما Windows فيقرر كيفية تصنيف الشبكة الناتجة، وهذا التصنيف هو ما يحدد قواعد جدار الحماية التي تُطبَّق على الواجهة.
نجاح المصادقة على النطاق عند البوابة دليل يخص الحساب. وهو ليس دليلًا على أن الطرف الآخر قد صادق الشبكة على وحدة تحكم نطاق، وهذا بالضبط ما تمثله فئة النطاق.
لهذا يمكن أن يكون الجهاز منضمًا إلى نطاق، ويتصل بحساب نطاق، ومع ذلك يظهر كعام. التصنيف قرار محلي بشأن الشبكة، وليس بيانًا عن بيانات الاعتماد التي فتحت النفق. وقد يكون الحساب صالحًا تمامًا بينما تبقى التسمية حيث بدأت.
ثلاث فئات، لا يمكنك تعيين واحدة منها
يعرض Windows ثلاث فئات، ولا يمكن لمسؤول تعيين سوى اثنتين منها. أما الثالثة فيقررها نظام التشغيل بعد أن يصادق الشبكة بنجاح على وحدة تحكم نطاق.
| Category | How it is assigned | What it affects |
|---|---|---|
| Public | Default for unidentified networks, or set manually | Rules scoped to the public profile |
| Private | Set manually, or by the user on a trusted network | Rules scoped to the private profile |
| DomainAuthenticated | Determined by Windows after domain authentication | Rules scoped to the domain profile |
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory,IPv4Connectivity
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory Private
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory DomainAuthenticatedيفشل الأمر الثالث، وهذا هو السلوك الموثق وليس مشكلة في الأذونات. يذكر مرجع الأمر نفسه أن فئة النطاق لا يمكن تعيينها بهذه الطريقة، لأن Windows يستنتجها من المصادقة على النطاق. ورؤية الخطأ تأكيد مفيد على أن الفئة نتيجة وليست إعدادًا.
اقرأ الأمر الأول على الطرف الذي يجري حجب حركته. فتصنيف واجهة البوابة نفسها لا يخبرك بشيء عن كيفية تصنيف كل محطة عمل لنفقها.
القواعد تتبع ملف التعريف الذي كُتبت من أجله
بمجرد أن تعرف الفئة، يفسر الوصول المفقود نفسه عادة. فكل قاعدة في جدار حماية Windows تحمل نطاق ملف تعريف، والقاعدة المحددة للنطاق لا تُطبَّق عندما تكون الواجهة عامة. وثلاثة أوامر تحول ذلك إلى إجابة بدلًا من نظرية، والثالث منها يلتقط الحالة التي لم يكن فيها ملف التعريف هو المشكلة أصلًا:
(Get-NetFirewallRule -DisplayName 'Allow File Share').Profile
Get-NetFirewallRule -DisplayName 'Allow File Share' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundActionالأمر الثاني هو الذي يحول تقريرًا غامضًا إلى إصلاح. فإذا كانت القاعدة محددة لنطاق عناوين بعيد لا يشمل مجموعة عناوين VPN، فلن يساعد تغيير ملف التعريف أيضًا.
تحقق من إجراء الدخول الافتراضي كذلك. ففي جهاز يُحجب فيه الدخول افتراضيًا، تُنتج قاعدة السماح الغائبة صمتًا بدلًا من رفض. وهذا يبدو من جانب العميل مطابقًا لفشل في التوجيه، ولهذا يبدأ كثير من هذه التذاكر بالافتراض الخاطئ.
حدد الجهاز الذي يفرض القاعدة
قبل تغيير أي فئة، أثبت أين يحدث الحجب. فالخادم الذي يستضيف المجلد المشترك قد يكون لديه جدار حمايته الخاص، وقواعده تُطبَّق على الحركة القادمة من مجموعة VPN بغض النظر عن كيفية تسمية العميل لمحوله. والرفض هناك غير مرئي لأي أمر محلي تشغله، ولا يبلّغ جانب العميل سوى بأن المورد غير متاح. اختبر قواعد الوجهة نفسها قبل أن تمس تصنيف العميل.
اختبر من العميل إلى المنفذ المحدد، ثم قارن باختبار من مضيف آخر على الشبكة الافتراضية نفسها. إذا فشل الاختباران، فالمشكلة عند الوجهة أو على المسار. وإذا فشل واحد فقط، فالفرق محلي في ذلك الجهاز، وتصبح فئة ملف التعريف سببًا محتملًا.
انتبه إلى الاتجاه أيضًا. فالقاعدة التي تسمح بدخول SMB لا تفعل شيئًا لعميل تحجب قاعدته الصادرة الحركة نفسها. ومن نافذة مستكشف الملفات يكون الفشلان غير قابلين للتمييز، لذا اختبر كل اتجاه على حدة قبل تحرير أي شيء.
ما العمل بدلًا من إعادة تسمية كل شيء
جعل شبكة غير معروفة «خاصة» لإرضاء قاعدة واسعة تغيير حقيقي ذو عواقب حقيقية. فملف التعريف الخاص يسمح عادة بمزيد من الاكتشاف ومزيد من حركة الدخول مقارنة بالملف العام.
إذا كان الهدف هو السماح لخدمة معينة بالوصول إلى عملاء VPN، فحدد القاعدة بحسب العنوان البعيد بدلًا من ملف التعريف. فهذا يعبر عن القصد بدقة، ويعمل بغض النظر عن التصنيف، ولا يعتمد على تخمين Windows الصحيح بشأن محوّل افتراضي. كما أنه يصمد أمام تحديث للعميل يعيد تصنيف الواجهة. اكتب مجموعة العناوين في القاعدة ليستطيع الشخص التالي قراءة القصد دون أن يسأل.
إذا كانت فئة النطاق متوقعة فعلًا ولا تظهر أبدًا، فتلك مسألة تحقيق منفصلة. تحقق من أن الجهاز منضم إلى نطاق، وأنه يستطيع الوصول إلى وحدة تحكم نطاق عبر النفق، وأن القناة الآمنة سليمة. وهذه الأوامر الثلاثة تجيب عن ذلك دون أي تعديل في السجل:
Get-CimInstance Win32_ComputerSystem | Select-Object PartOfDomain,Domain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.comتلك الأوامر الثلاثة تجيب عما إذا كان الطرف الآخر يستطيع مصادقة الشبكة أصلًا. فإذا لم يستطع الوصول إلى وحدة تحكم، فلن تُعيَّن فئة النطاق أبدًا مهما كان عدد مرات إعادة ضبط المحوّل. قاعدة جدار الحماية التي كنت تلاحقها لم تكن المشكلة الحقيقية قط، وكانت التسمية عرضًا لمسار معطل لا سببًا.