mitmproxy وDevTools وGradle: ثلاث طبقات خلف VPN
لا يدخل loopback النفق أبداً. صنّف العَرَض إلى مستمع أو مخزن ثقة أو مرشّح حزم، وأصلح الطبقة التي فشلت فعلاً.
يتصل VPN، و ثلاثة أدوات لا علاقة بينها تفشل بثلاث طرق مختلفة في الظهيرة نفسها. يتوقف mitmproxy عن رؤية الطلبات، ويرفض Chrome المصحّح، ويرمي Gradle BindException أثناء ربط مقبس محلي. الشك المشترك هو أن النفق يحجب localhost. لا يمكنه ذلك: 127.0.0.1 يُعالَج داخل النواة ولا يصل أبداً إلى محوّل، فضلاً عن بوابة.
ثلاث طبقات، وثلاثة أعطال مختلفة
ما تغيّر مع العميل ليس المسار إلى loopback. إنه وسيط محلي ومخزن ثقة على الجهاز ومرشّح حزم، وكل واحد منها يكسر جزءاً مختلفاً من سير عمل المطوّر. تصنيف العَرَض في الصف الصحيح هو معظم التشخيص:
| Symptom | Layer | First check |
|---|---|---|
| Proxy sees no traffic | Local proxy or listener | ss -lntp, or netstat -ano on Windows |
| TLS error in one tool only | Trust store | Which CA bundle does that runtime read? |
| Local bind or connect refused | Packet filter or port owner | Who holds the port, and what rule drops it? |
يكاد كل تقرير من هذا النوع يبدأ من الصف الأخير ويعمل صعوداً، وهذا معكوس. النفق هو الطبقة الوحيدة التي يستحيل إثباتاً أن ترى حركة loopback، لذا يستحق أقل شك. ابدأ بما ربطته العملية، ثم اسأل أي الشهادات تثق بها، وبعد ذلك فقط انظر إلى السياسة على الجهاز.
ابدأ بالمستمع، لا بالنفق
عندما يتوقف وسيط على 127.0.0.1:8080 عن تلقّي الحركة، حدث أحد ثلاثة أمور: لم يبدأ أبداً، أو ربط منفذاً آخر، أو أسقط المرشّح اتصال loopback. سرد المقابس المستمعة يجيب عن ذلك بأمر واحد، ويُظهر أيضاً أي عملية تملك المنفذ عندما تختلف أداتان حول من كان أولاً.
عنوان محلي في بحث مسار يؤكد الشيء نفسه من الاتجاه الآخر. ip route get تجاه وجهة loopback يُبلّغ عن جهاز loopback، لا النفق أبداً، وهي جملة مفيدة تُبقيها جاهزة عندما يقترح أحدهم تغييراً في التوجيه كإصلاح.
طبقة الوسيط: البيئة ليست إعداداً
كثير من عملاء الشركات يشغّلون وسيط HTTP ويتوقعون أن تستخدمه التطبيقات. ضبط HTTPS_PROXY في صدَفة يُصلح أدوات سطر الأوامر التي تحترمه، ولا يفعل شيئاً لأداة تقرأ ملف إعداداتها الخاص. Gradle وSelenium وgRPC كلها تراجع إعداداتها الخاصة، ووسيط مُصدَّر في طرفية واحدة غير مرئي لخدمة خلفية يبدأها IDE.
أدوات الحاويات هي المكان المعتاد الذي يصبح فيه هذا مرئياً. loopback الحاوية خاص بها، لذا 127.0.0.1 داخل الحاوية لا يعني أبداً وسيط المضيف؛ يلزم عنوان المضيف أو إعداد شبكة المضيف. الإصلاح الذي ينجح في الصدَفة ويفشل في البناء هو عادة هذا الصف، لا النفق.
طبقة الثقة: الأداة تقرأ مخزناً آخر
الاعتراض هو التغيير الثاني، وهو ينتج أكثر الأخطاء تضليلاً. يقدم العميل شهادته الخاصة للاتصالات المفحوصة، لذا ينجح متصفح يثق بالجذر المؤسسي بينما تفشل أداة بمخزن CA مضمّن. طلبات Python عبر certifi هي الحالة الكلاسيكية: قد يكون مخزن نظام التشغيل صحيحاً ويظل الطلب فاشلاً، لأن بيئة التشغيل تلك لا تقرأه أبداً. نص الخطأ نادراً ما يذكر الاعتراض، ولهذا يُشخَّص هذا الصف خطأً كنقطة نهاية معطوبة.
قارن ما تقدمه نقطة النهاية فعلاً بما تحققت منه الأداة. openssl s_client يُظهر السلسلة التي أرسلها الخادم؛ ومخرجات التحقق الخاصة بالأداة تُظهر ما قررته. عندما يختلفان، REQUESTS_CA_BUNDLE أو SSL_CERT_FILE هو الرافعة لبيئة التشغيل تلك، والجذر المؤسسي ينتمي إلى المخزن الذي تقرأه تلك البيئة، لا إلى موضع عام لا تحترمه إلا بعض الأدوات.
تغيير إصدار يُصلح خطأ SSL هو دليل على سياسة الثقة والتشفير، لا على VPN. تخفيض Python الذي جعل عميل SOAP يعمل غيّر مخزن CA المضمّن وإعدادات TLS الافتراضية؛ مسار الشبكة لم يتحرك.
طبقة المرشّح: يمكنها إسقاط loopback أيضاً
التغيير الثالث هو مرشّح حزم، وبعض المنتجات تثبّت قواعد تُسقط الحركة التي لا تدخل النفق. يمكن أن يشمل ذلك المستمعين المحليين. يحوّل ذلك مقبساً عاملاً إلى اتصال مرفوض أو منتهي المهلة، ويبدو الخطأ الناتج كخطأ في التطبيق لا كسياسة على الجهاز.
ملكية المنفذ هي النصف الآخر من هذه الطبقة. إن BindException يعني أن المقبس تعذّر فتحه، وهو فشل مختلف عن رفض الاتصال. تحقق مما إذا كانت عملية أخرى تملك المنفذ بالفعل قبل لوم المرشّح، ثم ابحث عن قاعدة تُسقط الحركة المحلية وأضف أضيق سماح يدعمه المنتج. أداتان تتنافسان على منفذ التصحيح نفسه تنتجان الرسالة نفسها تماماً كحجب سياسة، وواحدة فقط منهما يُصلحها تغيير جدار الحماية.
منفذ التصحيح في Chrome يفشل في العائلة نفسها. يبدأ المتصفح، ولا يستطيع المشغّل الوصول إلى نقطة نهاية DevTools، وتذكر الرسالة DevTools لا الشبكة. أعلام التشغيل الإضافية ومدير مشغّل زائد يغيّران أي عملية تملك المنفذ، ولهذا يبدو إزالتها أحياناً كإصلاح لـ VPN.
أصلح الطبقة التي فشلت
أصلح الطبقة التي فشلت، لا النفق. المستمع loopback غير القابل للوصول يحتاج إلى تصحيح مستمعه أو منفذه. الشهادة غير الموثوقة تحتاج إلى تثبيت الجذر المؤسسي حيث تنظر بيئة التشغيل تلك بالتحديد، مع إبقاء الاستثناء ضيقاً. المرشّح الذي يُسقط الحركة المحلية يحتاج إلى قاعدة سماح محددة لا إلى تعطيل المرشّح، لأن التعطيل يعيد أيضاً فتح كل شيء آخر كان يحميه.
إعادة الاتصال بـ VPN لا تختبر أيّاً من هذه الطبقات. إنها تعيد فقط تشغيل التغيير الذي كسرها، ولهذا تعود الأعطال الثلاثة نفسها بعد كل إعادة اتصال وتختفي بعد كل إعادة تشغيل تترك العميل غير نشط.