شبكتا VPN تعملان معًا على Windows: أي ملف تعريف يحتفظ بالمسار الافتراضي؟

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

مُدخل واحد فقط يمكن أن يكون الافتراضي الأفضل

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

لا تستطيع أيقونات حالة العميل إظهار ذلك. فهي تبلّغ عن إنشاء نفق، لا عن البادئات التي ما زالت تُوجَّه إليه، لذا يرى المستخدم أيقونتين خضراوين ومهلة انتهاء في أحد التطبيقات. قراءة route print -4 أثناء العطل أكثر إفادة من أي سجل VPN.

تحليل الأسماء نزاع ثانٍ مستقل، ولن يحسمه إصلاح جدول التوجيه وحده.

ما يثبّته مربع الاختيار، وما يزيله

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

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

الإعدادات المختلطة مشروعة وشائعة: ملف تعريف مؤسسي يُبقي مربع الاختيار كنفق كامل، بينما يكون ملف مختبر مقسّمًا حتى لا يزيح الافتراضي المؤسسي.

اختر بحسب ما يجب أن يحمله كل نفق

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

إن وجب أن يكون أحد النفقين كاملًا، فهو يملك الافتراضي ويجب أن يكون الآخر مقسّمًا. وإن لم يحتج أي منهما إلى حركة إنترنت عامة، فأزِل العلامة من كليهما ودع المحوِّل الفيزيائي يحتفظ بالافتراضي. وإن تداخلت النطاقات، توقّف: لا يمكن أن يعني 172.22.0.0/16 جهازًا في الجانب المؤسسي وآخر في جانب المختبر، ولا يحل ذلك أي مربع اختيار.

سجِّل القرار بجانب أسماء الملفات. وإلا فسيعيد VPN ثالث يُضاف في الربع القادم التحقيق من البداية.

أضِف البادئات الناقصة واختبر النتيجة

لكل نفق مقسّم، أضِف النطاقات البعيدة صراحةً، باستخدام عنوان النظير الظاهر على ذلك المحوِّل بدلًا من عنوان الخادم العام:

> route add 172.22.0.0 mask 255.255.0.0 172.20.4.1
> route print -4
> Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric

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

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

> Get-DnsClientServerAddress -AddressFamily IPv4
> Resolve-DnsName files.corp.internal -Server 172.20.4.1

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

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