جدار حماية Windows وحده كمفتاح إيقاف VPN: هل يصمد؟
قواعد نوع الواجهة قد تحجب المحوّلات الفيزيائية، لكن نفق طرف ثالث يظهر غالبًا كسلكي. تحقّق من التصنيف، ثم مسار نقطة النهاية، ثم DNS.
اسأل عمّا إذا كان جدار حماية Windows يستطيع وحده أداء دور مفتاح الإيقاف فتحصل على جوابين واثقين ومتناقضين. يقول أحدهما إن قاعدة نوع الواجهة تؤدي المهمة كلها؛ ويقول الآخر إنه لا يعمل دون كتابة نصوص برمجية. كلاهما يصف نصف الآلية نفسها. يستطيع الجدار التعبير عن الحجب، وأما هل تنتهي النتيجة فعلًا إلى إغلاق آمن فيعتمد على ثلاثة أمور: كيف يصنّف Windows محوّل النفق، وهل تبقى استثناءات نقطة النهاية صالحة، وهل تحليل الأسماء وIPv6 مغطّيان. أخطئ في أي واحد منها فإما يتسرب الجهاز أو يفقد كل اتصال.
ثلاثة شروط، بهذا الترتيب
الشرط الأول هو التصنيف، وهو يحدّد ما إذا كانت القاعدة التي تريدها قابلة للتعبير أصلًا. يمكن تقييد قواعد جدار حماية Windows حسب نوع الواجهة: سلكية أو لاسلكية أو وصول عن بعد. السياسة التي تحجب حركة الصادر على الأنواع الفيزيائية وتسمح بالنفق لا تعمل إلا إذا كان Windows يعترف بالنفق كوصول عن بعد.
الشرط الثاني هو استثناء نقطة النهاية. قبل وجود أي نفق، على العميل أن يصل إلى خادم VPN عبر المحوّل الفيزيائي، لذا فإن حجبًا شاملًا على ذلك المحوّل يمنع بالضبط الاتصال الذي كان سيجعل الحجب غير ضروري. يجب أن يسمّي الاستثناء الخادم ومنفذه، وأن تُوجَّه الحزمة عبر البوابة الفيزيائية بدلًا من نفق لم يُفتح بعد.
الثالث هو التغطية. مجموعة قواعد تحجب IPv4 وتنسى IPv6، أو تسمح للمُحلّل المحلي بتحليل نقطة النهاية وبالتالي تسمح بكل تحليل آخر، تفشل مفتوحة في النافذة نفسها التي وُجد مفتاح الإيقاف لتغطيتها. هذا ثغرة تصميم لا خلل في الجدار. وهي أيضًا الثغرة التي تنجو من كل اختبار على مكتب.
التصنيف هو البوابة الأولى
تحقّق مما يعتقده Windows عن المحوّلات قبل كتابة قاعدة واحدة. يظهر اتصال VPN الأصلي في Windows عادةً كوصول عن بعد. ويظهر عميل طرف ثالث ينشئ محوّله الافتراضي غالبًا كسلكي، ما يعني أن حجبًا مقيّدًا بالمحوّلات السلكية يحجب النفق أيضًا.
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory
Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultOutboundActionيخبرك الأمر الثالث عمّا إذا كان حجب الصادر الافتراضي ساريًا أصلًا، وهذا يغيّر شكل التصميم كله. إذا كان الافتراضي حجبًا، فأنت تكتب قواعد سماح بدلًا من استثناءات على أساس متسامح، وهذا موقف أسهل بكثير في التفكير.
إذا أبلغ محوّل نفقتك أنه سلكي، فالجدار وحده ليس الأداة الصحيحة لتصميم مغلق عند الفشل، ولا يغيّر ذلك أي مقدار من ضبط القواعد. هذه هي الحالة التي يكون فيها الرأي الثاني في كل خيط منتدى صحيحًا.
استثناء نقطة النهاية يحتاج مسارًا لا قاعدة فقط
افترض أن التصنيف يعمل. الاستثناء قطعتان، وهو يعيشان في أنظمة فرعية مختلفة. قاعدة الجدار تسمح بالحركة؛ ومسار المضيف يجعلها تخرج من الواجهة الصحيحة بينما النفق متوقف.
New-NetFirewallRule -DisplayName "VPN endpoint allow" -Direction Outbound -Action Allow \
-Protocol TCP -RemoteAddress 203.0.113.9 -RemotePort 443 -InterfaceType Wired,Wireless
New-NetRoute -DestinationPrefix 203.0.113.9/32 -InterfaceIndex 12 -NextHop 192.168.1.1
Get-NetRoute -DestinationPrefix 203.0.113.9/32بلا المسار، لا يفيد استثناء نقطة النهاية إلا ما دام مسار افتراضي يشير إلى البوابة الفيزيائية. وبمجرد أن يثبّت العميل مساره الافتراضي ثم يتوقف، لا تجد الحزم المسموح بها مكانًا معقولًا تذهب إليه ولا يمكن إعادة إنشاء الاتصال. يبدو ذلك الفشل كعميل معطّل وهو في الحقيقة مسار مفقود.
أبقِ الاستثناء ضيقًا بقدر ما يسمح العميل. عنوان واحد ومنفذ واحد قابلان للمراجعة؛ أما نطاق يغطي شبكة المزوّد كلها فليس كذلك. تلك القاعدة الأوسع تسمح أيضًا بأي شيء آخر مستضاف عند المزوّد نفسه، وهو عادة أكثر مما أردت.
DNS وIPv6 هما حيث يفشل مفتوحًا
تحليل الأسماء هو التسرب الكلاسيكي. إذا كانت نقطة النهاية اسم مضيف، فعلى العميل تحليله قبل وجود النفق، أي يجب السماح للمحوّل الفيزيائي بالوصول إلى مُحلّل. والصلاحية نفسها تسمح بخروج كل تحليل آخر بينما النفق متوقف، وتحليل واحد يكفي لكشف ما كنت على وشك زيارته.
IPv6 هو الثاني. القواعد المكتوبة لـ IPv4 لا تغطّي العائلة الأخرى، وكثير من العملاء يثبّتون مسارات IPv4 فقط. لذا يمكن لجهاز لديه اتصال IPv6 أصلي أن يواصل التحدث إلى الإنترنت بينما الجانب IPv4 محجوب بإحكام، ومفتاح الإيقاف يبلّغ بالنجاح طوال الوقت.
| Gap | What leaks | Control |
|---|---|---|
| Resolver permitted for endpoint lookup | Every name queried while down | Pin the endpoint as an address, or block non-tunnel DNS |
| Rules only for IPv4 | Full IPv6 connectivity | Add the same rules for the other family |
| Application bound to physical interface | Its own traffic | Firewall cannot fix this; change the binding |
الصف الثالث يستحق الفهم بدل الالتفاف عليه. جدار الحماية يقرّر بشأن الحزم، لا بشأن الواجهة التي طلب تطبيق استخدامها، وقد يكون تطبيق يربط نفسه صراحةً صعب الاحتواء. وهذا حجة لصالح مفتاح إيقاف من جهة العميل يعمل تحت التطبيق، لا لمزيد من القواعد.
اختبر بإيقاف العميل، لا بنزع الكابل
الاختبار الوحيد ذو المعنى هو الذي يحاكي الفشل الذي تحمي منه. أوقف الخدمة، أو اقتل العملية، أو عطّل المحوّل الذي أنشأه العميل، ثم حاول الوصول إلى الإنترنت وإلى اسم:
Stop-Service -Name "YourVpnService" -Force
Test-NetConnection -ComputerName 1.1.1.1 -Port 443
Resolve-DnsName example.com
Test-NetConnection -ComputerName 2606:4700:4700::1111 -Port 443يجب أن تفشل الثلاثة. إذا نجح الأول فالحجب غير سارٍ؛ وإذا نجح الثاني حيث فشل الأول فلديك تسرب DNS؛ وإذا نجح الثالث فإن IPv6 غير مغطّى. كل نتيجة تشير إلى ثغرة واحدة بالضبط من الثغرات أعلاه.
أعد الاختبار بعد سكون واستئناف، لأن ملف الجدار قد يتغيّر حين يقرّر Windows أن شبكة عامة أو خاصة، والقواعد المقيّدة بملف تتبعه. التصميم الذي يصمد على مكتب ويفشل في قطار هو تصميم اختُبر مرة واحدة.
إذا كانت بوابة التصنيف أو متطلّب DNS تجعل نهج الجدار وحده غير قابل للعمل، فالجواب الصادق هو مفتاح إيقاف من جهة العميل. وإذا كان النفق ينتهي عند موجّه بدلًا من ذلك، فعلى الموجّه أن يملك السياسة، لأن قاعدة واحدة هناك تغطّي كل جهاز خلفه ولا تعتمد على كيفية تسمية Windows للمحوّل.