عملاء VPN محظورون بسبب ملف تعريف جدار الحماية العام في Windows

نفقك قائم، والبوابة تستجيب لـ ping، ومع ذلك تنتهي مشاركة الملفات بمهلة. نادرًا ما تكون هذه التركيبة مشكلة توجيه: لقد وضع Windows الشبكة الفرعية لمحوّل VPN في ملف التعريف العام، ولم تُطبَّق أي قاعدة سماح كُتبت لملف الخاص أو النطاق. صادفت هذا على حواسيب محمولة تصل إلى المكتب بلا مشكلة وعلى خوادم RRAS تخدم كل العملاء الآخرين، والإصلاح قصير بمجرد تسمية ملف التعريف المعني. هذا هو ترتيب عملي، مع الفحص الذي يخبرك متى تتوقف قبل الخطوة التالية.

حدّد ملف التعريف الذي يصل عليه المرور فعلاً

لا يملك جدار حماية Windows وضعًا عالميًا واحدًا. كل واجهة متصلة تحمل فئة، وتُرشَّح الحزم الواردة حسب فئة الواجهة التي تصل عبرها، لذا فإن ملف تعريف محوّل VPN هو ما يحدد ما يمكن للعميل داخل النفق الوصول إليه، لا محوّل Wi-Fi أو Ethernet المجاور. اقرأ الحقيقتين قبل تغيير أي شيء:

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

في تثبيت OpenVPN أو WireGuard القياسي يظهر محوّل VPN كشبكة غير محددة ويقع في ملف التعريف العام، وهو الافتراضي لأي شبكة لا يستطيع Windows تصنيفها، إذ لم يستجب أي وحدة تحكم بالنطاق عبرها ولم يطابق أي ملف تعريف بوابة. اسم الواجهة لا يهم هنا، فاستدعاء المحوّل "VPN" أو "Corp" لا يغيّر شيئًا. يتطلب DomainAuthenticated جهازًا منضمًا إلى النطاق ، ويجب أن يصل فعلاً إلى وحدة تحكم بالنطاق عبر تلك الواجهة؛ النفق المنقسم الذي يحمل شبكة فرعية واحدة لا يحقّق ذلك.

إن كانت القاعدة التي تحتاجها مقيّدة أصلاً بنطاق VPN وتنطبق أصلاً على الفئة التي قرأتها للتو، فتوقف هنا: الترشيح ليس طبقتك، والمكان التالي للنظر هو إعداد الخدمة. يستغرق هذا الفحص عشر ثوانٍ ويوفر ساعة من تحرير القواعد. أسماء الفئات وما تغطيه كل واحدة موثّقة في مرجع Get-NetConnectionProfile.

أكّد أن المشكلة في الترشيح لا في التوجيه قبل تحرير القواعد

Ping اختبار ضعيف. قد تمرّ ICMP بينما يُسقَط منفذ الخدمة، وقد يستجيب المضيف من LAN بينما يرفض الطلب نفسه عبر النفق. اختبر المنفذ الذي يحتاجه العميل، من العميل:

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

إن فشل اختبار المنفذ، فافصل الطبقتين. عطل النفق أو المسار يظهر عادةً كعدم وصول أي رد من عنوان البوابة، بينما يُظهر الإسقاط من جدار الحماية بوابة تستجيب ومنفذ خدمة لا يستجيب. على خادم Windows ينشر النطاق عبر RRAS، شغّل الاختبار نفسه من عميل واقرأ ملف تعريف الخادم نفسه: قد تكون واجهة RAS ضمن فئة لا تذكر قواعدها الواردة نطاق العملاء قط، ولهذا يخدم الجهاز شبكته المحلية ويرفض كل عميل في النفق.

حين يبقى الناتج غير حاسم، سجّل عمليات الإسقاط لملف التعريف المعني واقرأها:

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

المدخلات التي تذكر عنوان العميل ومنفذه مع DROP قاطعة، وتخبرك أيضًا أي قاعدة كانت غائبة. سجل فارغ بينما لا يظهر SYN العميل قط يشير إلى ما قبل المضيف، لذا عُد إلى النفق أو قاعدة NAT أو مسار النطاق قبل لمس أي كائن آخر في جدار الحماية.

قيّد قاعدة واردة واحدة بنطاق العملاء

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

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

حين تكون الخدمة ملفًا ثنائيًا واحدًا، فضّل قاعدة مقيّدة بالبرنامج مع -Program بدلاً من قائمة منافذ؛ وهذا يضيّق الاستثناء على العملية وعلى نطاق المصدر معًا.

اختيار ملف التعريف هو حيث يقع الخطأ نفسه في الاتجاه المعاكس. -Profile Public يكفي حين يكون المحوّل عامًا ويبقى عامًا. -Profile Any يمكن تبريره حين يجب أن تعمل الخدمة كيفما صنّف Windows المحوّل، لكن ما دام النطاق البعيد محفوظًا. ما لا يمكن تبريره أبدًا هو -RemoteAddress Any على ملف التعريف العام: تلك القاعدة تتبع الحاسوب المحمول إلى كل شبكة مقهى وفندق ينضم إليها وتفتح المنفذ لكل من يشارك تلك الشبكة الفرعية.

دوّن النطاق بجانب القاعدة. -RemoteAddress 10.8.0.0/24 يتوقف بهدوء عن المطابقة يوم يُعاد ترقيم نطاق VPN، ويبدو العطل تمامًا كالخلل الأصلي، ولهذا يكلّف ظهيرة ثانية. سمّ القواعد بالخدمة ونطاق المصدر، وأبقها مع -Group، وأعد قراءتها كلما تغيّر تعريف النطاق. جرد القواعد الذي يمكنك تدقيقه على شاشة واحدة أفضل من قاعدة صحيحة لا يجدها أحد.

غيّر الفئة فقط حين تكون الفئة هي القرار

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

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

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

على جهاز مُدار، تحقّق أولاً مما إذا كانت مجموعة نهج أو خط أساس MDM يملك الإعداد. إن كان يملكه، فسيُلغى التغيير المحلي في التحديث التالي، و gpresult /h سيسمّي النهج الذي يملكه؛ أصلح هناك لا على الطرف.

تحقّق من الطرفين واترك أثرًا

تحقّق من التدفق الذي أبلغ عنه المستخدم، من العميل، بعد التغيير:

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

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

قبل أن تعلن الانتهاء:

• ملف التعريف المذكور في القاعدة هو ملف التعريف على الواجهة التي يصل عبرها المرور.
• النطاق البعيد هو نطاق VPN، وذلك النطاق يطابق ما يمنحه الخادم فعلاً.
• لا تستخدم أي قاعدة أضفتها -RemoteAddress Any على ملف التعريف العام.
• لم يُعطَّل أي شيء ليمرّ الاختبار، وكل تغيير فئة يسجّل من أقرّه.