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

الخطوة الأولى: أثبت أن الطابعة ما زالت متاحة على الشبكة المحلية

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

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

الخطوة الثانية: اعرف المسار الذي يختاره Windows فعليًا

لا تقرأ الجدول من أعلاه إلى أسفله وتخمّن. اسأل Windows أي إدخال يختاره للعنوان الدقيق الذي يهمك، واحصل على فهرس الواجهة في الوقت نفسه.

Find-NetRoute -RemoteIPAddress 192.168.1.50
route print -4
tracert -d 192.168.1.50

يطبع Find-NetRoute المسار الفائز وواجهته، وهما الحقيقتان التي يعتمد عليهما بقية هذا العمل. يعرض route print -4 الإدخالات المحيطة، بما فيها نصفا المسار الافتراضي اللذان يثبتهما عملاء النفق الكامل: 0.0.0.0/1 و 128.0.0.0/1، ويغطيان معًا فضاء IPv4 كله دون أن يستبدلا 0.0.0.0/0 أبدًا. المسار /1 أطول من /0، لكن 192.168.1.0/24 الخاص بك أطول منهما، ولهذا يكون غياب مسار الشبكة المحلية أهم من ادعاء النفق نفسه.

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

الخطوة الثالثة: أضف أضيق مسار يسمّي البوابة والواجهة

الإصلاح هو إدخال واحد يوجّه عنوان الطابعة إلى الموجه المحلي على الواجهة المحلية. نفّذه في موجه أوامر مرفوع واستبدل القيم التي قرأتها للتو.

route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 if 12 -p

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

فضّل مسار مضيف للجهاز الواحد على مسار للشبكة 192.168.1.0/24 كاملة. مسار الشبكة الفرعية أوسع مما تحتاجه المهمة، ويتعارض في اللحظة التي يستخدم فيها الجانب المؤسسي البادئة نفسها: تصبح للبادئة الواحدة ملكان، وأي إدخال يفوز هو ما يحدد الشبكة التي يمكنك الوصول إليها فعلًا.

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

الخطوة الرابعة: اجعل الاستثناء ينجو من الاتصال التالي

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

راقب IPv6 على حدة. العميل الذي يطالب بالافتراضي IPv4 فقط قد يترك مسار IPv6 الافتراضي على المهايئ الفعلي، فتبقى طابعة يمكن الوصول إليها عبر IPv6 تعمل بينما يفشل IPv4، أو العكس. اختبر بـ ping -4 و ping -6 قبل أن تقرر أن جدول التوجيه بريء.

ماذا يكلفك المسار المختصر المحلي

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

إذا استجابت الطابعة بعد التغيير، فأعد الفحوصات الأربعة بعد إعادة اتصالك التالية بدلًا من افتراض أن الإصلاح صمد. وإذا لم تستجب، فالتقط خرج Find-NetRoute قبل الاتصال وبعده؛ الفرق يخبرك هل حذف العميل الإدخال أم أعاد ترتيبه فقط.

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