أداة تصحيح الأخطاء تفقد الرؤية عند اتصال شبكة VPN الخاصة بالشركة

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

يحتفظ Windows بوسيط لكل اتصال

في خيارات الإنترنت طبقتان تبدوان متطابقتين في مربع الحوار. إعدادات الشبكة المحلية تنطبق على الاتصال المحلي العادي، أما إدخال الاتصال الهاتفي أو الشبكة الافتراضية فيحتفظ بنسخته الخاصة تحت HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections، مخزّنة كقيمة ثنائية. كتابة قيم التسجيل العامة المعتادة لا تحدّث تلك النسخة.

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

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

ملف PAC المُدار قد يعيد تشغيل نفسه

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

افحص، وإن كنت مخوّلًا، أوقف هذين المفتاحين للخدمة التي تحمل حركة المرور:

networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy

استخدم اسم الخدمة الحقيقي بدلًا من التخمين. الحاسوب المحمول الذي يضم شبكة لاسلكية ومهايئ إيثرنت عبر USB معًا لديه اثنتان، وواحدة فقط هي التي تحمل حركتك. يطبع scutil --proxy القيم للخدمة الأساسية الحالية. قارن ذلك الناتج بما عدّلته قبل أن تستنتج أن ملف التعريف قد فاز.

وجّه الأداة إلى المصدر الحقيقي

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

هذه هي الخطوة التي تُبقيك في التصحيح بدل إعادة الإعداد.

ادفع الوسيط إلى داخل النفق

يمكن لعميل قائم على OpenVPN أن يقبل خيارات وسيط تنطبق بعد قيام النفق، وهذا مناسب عندما يملك العميل المسارات:

dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888

لن تستخدمه إلا العملاء التي تحترم هذا الخيار، وهو يثبّت منفذ الاستماع الخاص بك داخل ملف تعريف. اعتبره تسهيلًا مختبريًا لا معيار نشر، لأن دفع ملف التعريف التالي سيزيله.

بعض العملاء لا يقرأون وسيط النظام أبدًا

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

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

اقرأ الإعداد، لا المفتاح

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

كل حالة هنا مشكلة أسبقية في الإعداد. ولا واحدة منها نفق يكسر أداتك.