هل تشارك اتصال Windows؟ مسار VPN يتغير تحته

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

نجاح المضيف لا يثبت شيئًا

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

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

أي المحوّلات مشترك، وأيها يخدم العملاء

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

Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceIndex,LinkSpeed
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,IPAddress,PrefixLength
Get-NetIPInterface | Select-Object InterfaceAlias,Forwarding,ConnectionState
Get-NetConnectionProfile

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

التمرير والترجمة والتصفية

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

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

شغّل الفحوص على العميل، لا على المضيف

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

Resolve-DnsName intranet.example.net -Type A
Resolve-DnsName intranet.example.net -Type AAAA
Invoke-RestMethod https://api.ipify.org
Test-NetConnection intranet.example.net -Port 443 -InformationLevel Detailed

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

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