يتصل الحاسوب المحمول بشبكة VPN المكتبية ويتبعه كل شيء، بما في ذلك صفحة ويب لطابعة وشبكة داخلية واحدة لا تستجيب إلا على الشبكة المحلية. يصلح مسار يدوي ذلك لمدة ساعة، ثم ينقطع الاتصال، ويعود، ويختفي الاستثناء. لا شيء خطأ في النفق: يحتفظ Windows بجدول توجيه واحد، ويعيد محول VPN كتابة حصته من ذلك الجدول عند كل اتصال. ما يبقى هو كل ما يعيش خارج مدخلات المحول نفسه.

أي مدخل يستولي عليه النفق

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

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

route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.30

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

مسار المضيف يفوز بالتحديدية

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

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

في كل ما يلي، افترض اتصالاً يُسمى Office، وبوابة محلية 10.0.0.1 على الواجهة 7، ووجهة عند 198.51.100.30. هذه عناصر نائبة وليست إعدادات افتراضية، والأوامر أعلاه تنتج القيم التي يستخدمها جهازك فعليًا. احتفظ بملاحظة الاستبدال هذه مع التغيير كي لا ينسخ القارئ التالي الأرقام.

اجعل المسار يعيش أطول من إعادة الاتصال التالية

لا يقدم Windows أي تعليمة استثناء على اتصال VPN، لذا يجب أن يعيش الاستثناء على الواجهة الفعلية حيث لن يعيد المحول كتابته. الأمر الذي يبدو كأنه الحل يفعل العكس: Add-VpnConnectionRoute ينقل بادئة إلى داخل النفق، وهذا هو الحالة المعاكسة حيث ينبغي لملف تعريف منقسم أن يحمل وجهة واحدة ويترك الباقي محليًا. اللجوء إليه هنا يضمن أن حركة المرور التي أردت إبقاءها بالخارج تدخل.

النموذج اليدوي أمر واحد. ضعفه هو تغيّر الشبكة لا إعادة الاتصال.

route -p add 198.51.100.30 mask 255.255.255.255 10.0.0.1 metric 1 if 7

يبقى ذلك بعد إعادة التشغيل بفضل -p ويرسل عنوانًا واحدًا خارج الواجهة 7 بينما يحمل النفق كل شيء آخر. انقل الحاسوب إلى شبكة أخرى وسيصبح كل من البوابة والفهرس قديمًا، فيفشل المدخل بصمت. سجّل من يملكه ومتى يجب إزالته.

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

rasdial Office
route add 198.51.100.30 mask 255.255.255.255 10.0.0.1 metric 1 if 7

أي شيء يرفع النفق هو المكان الصحيح للسطر الثاني، وrasdial لا يعود إلا بعد تأسيس الاتصال، لذا يهبط المسار خلف مدخلات المحول نفسه. شغّله مرة أخرى بعد الاستئناف، لأن التعليق قد يسقط المسار ويترك النفق مفتوحًا. إذا كانت المهمة هي العكس، دفع بادئة واحدة إلى النفق مع بقاء الباقي محليًا، فإن Add-VpnConnectionRoute هو الأداة الصحيحة.

التوجيه لا يستطيع اختيار عملية

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

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

ضعفه تشغيلي لا تقني. يجب أن يبدأ البرنامج دائمًا عبر الغلاف، وإذا غاب الربط بعد الاستئناف فإنه يأخذ بصمت أي مسار يعرضه الجدول. هذا مقبول لمتصفح تفتحه عمدًا وغير مقبول لأي شيء يجب ألا يغادر النفق أبدًا.

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

تأكد من أن الاستثناء نجا من إعادة الاتصال

اختبر التغيير بالطريقة التي سيفشل بها: افصل، وأعد الاتصال، وافتح تطبيقًا جديدًا، ثم اطلب عنوانًا واحدًا يجب أن يبقى محليًا وآخر يجب أن يستخدم النفق. قارن كليهما مع Find-NetRoute في الحالة المتصلة.

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

مقالات ذات صلة