طلبات التطبيقات تفشل خلف VPN مؤسسي بينما يعمل المتصفح

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

انظر إلى الطلب الذي يرسله التطبيق فعلاً

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

env | grep -i proxy            # Linux/macOS
netsh winhttp show proxy       # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080

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

ورث التطبيق وكيلاً لم يضبطه أحد

معظم حزم HTTP تقرأ إعدادات الوكيل من نظام التشغيل افتراضياً. وكثيراً ما يثبّت عميل VPN مؤسسي وكيلاً ضمن ملف وصوله، فتخرج الطلبات عبر وكيل لم يذكره المطوّر في الشيفرة قط. في .NET يسحب المعالج الافتراضي الإعدادات من IE/WinHTTP؛ وفي Java يُقرأ -Dhttp.proxyHost؛ ولا يدعم Node الوكيل مدمجاً حتى تضيفه مكتبة. والفشل نادراً ما يكون رفضاً نظيفاً، ولهذا يبدأ الناس بالنظر إلى الخادم.

الاختبار يكلّف طلباً واحداً: عطّل الوكيل صراحةً في معالج واحد وقارن.

var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);

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

المنفذ الذي اخترته ليس المنفذ الذي تسمح به السياسة

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

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

TCP الخام الذي يعيد المسار تعيينه

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

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

اتصالات لا تُغلق إلا مع الحمولات الكبيرة

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

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

كيف تفرّق بين الأربعة في جولة واحدة

ثلاث ملاحظات تحسم معظم الحالات. هل يحدث الفشل فوراً أم فقط مع جسم كبير؟ هل ينجح الطلب نفسه مع تعطيل الوكيل؟ هل تتغير النتيجة عند تبديل المنفذ أو الناقل؟ اكتب الأجوبة قبل التغيير التالي، لأن VPN مؤسسي مع وكيل موروث مع إعداد افتراضي للتطبيق يعطيك ثلاثة أسباب محتملة دفعة واحدة.

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