لماذا لا يعني الخطأ 403 من موقع VPN فشل الوكيل
الخطأ 403 من الأصل، ورفض CONNECT، وتحدي 407 يحدّد حدودًا مختلفة. قارن أولًا مسار خروج الوكيل بعنوان VPN في المتصفح.
يفصل المستخدمون VPN، ويصطدمون بالخطأ 403 على موقع داخلي، ثم يبلّغون بأن الوكيل معطّل. ثلاثة أمور منفصلة يمكن أن تنتج تلك الصفحة: أن يرفض الأصل الطلب، أو يرفض الوكيل الأمامي فتح النفق، أو يطلب الوكيل بيانات اعتماده الخاصة. كل واحد منها جواب صحيح عن سؤال مختلف، وتسطيحها في صفحة فشل عامة واحدة يدمّر الدليل الوحيد الذي لديك. صنّف الرفض حسب المكوّن الذي أصدره، ثم قارن مسار الشبكة الذي يستخدمه كل مكوّن فعليًا.
سمِّ المكوّن الذي أنتج الخطأ 403
رمز حالة HTTP يخص الطرف الذي أرسله. عندما يعيد الأصل 403، فقد حلّل الطلب وقرّر أن المتصل قد لا يملك المورد، وهذا جواب تفويض لا مشكلة نقل. وعندما يجيب وكيل أمامي بـ 403 على CONNECT، فقد رفض بناء النفق أصلًا، ولم يُتصل بأي شيء في المنبع. وعندما يجيب بـ 407، فهو يريد بيانات اعتماده الخاصة، ولا علاقة لها بتسجيل دخول التطبيق.
| What you observe | What it means |
|---|---|
| Origin replies 403 | The origin understood the request and denied it |
| Proxy refuses CONNECT with 403 | The proxy declined to open that tunnel |
| Proxy replies 407 | Proxy authentication is required first |
| Gateway replies 502 or 504 | Upstream failure or timeout, not a permission decision |
يحدّد RFC 9110 هذه الأدوار، بما فيها التحدي الخاص بالوكيل. اقرأ حالة الاستجابة نفسها وأي ترويسة Proxy-Authenticate قبل قراءة الجسم، لأن صفحة خطأ HTML الودودة تخفي عادةً أي مكوّن كتبها.
ما يخفيه نفق CONNECT عن مرحّل البايتات
بعد أن يعيد الوكيل 200 على CONNECT، يصبح يمرّر البايتات ويحتفظ المتصفح بجلسة TLS خاصة به مع الأصل. لذلك لا يستطيع وكيل يمرّر البايتات قراءة الخطأ 403 المشفّر داخل تلك الجلسة، ولا يصبح مؤلف الرفض أبدًا. أما الرفض قبل فتح النفق فهو حدث مختلف تمامًا، يُنتج في طبقة أدنى.
الوكيل العكسي الذي ينهي TLS في موضع مختلف: فهو يملك حدود TLS، ويحلّل HTTP، ويمكنه شرعًا إعادة كتابة الاستجابات أو اعتراضها. تلك القدرة خيار إعداد، وليست خاصية للوكالة عمومًا، ولا تجيز تجاوز سياسة وصول التطبيق. قراءة الاستجابة قدرة؛ أما تقرير ما يجوز للمتصل رؤيته فيبقى مهمة الأصل.
النتيجة العملية أن عليك معرفة أي من الأشكال الثلاثة تشغّله قبل تفسير 403. إضافة قواعد تفتيش HTTP إلى وكيل تدفق لا تمنحه رؤية، وتوقّع أن يفسّر مرحّل بايتات رفضًا صادرًا عن الأصل سيرسلك إلى السجل الخطأ.
قارن مسار خروج الوكيل بعنوان النفق في المتصفح
المتصفح المتصل بـ VPN لا ينقل تلقائيًا خادم وكيل منفصل إلى ذلك النفق. يرى الأصل عنوان خروج الوكيل، وإذا كان الوكيل ما زال يخرج عبر المسار الافتراضي المحلي، فسيرى الموقع المحمي عنوانًا لم يُضبط أبدًا للثقة به. عنوان VPN الداخلي على الحاسوب المحمول غير مرئي لذلك الأصل. وهذا هو السبب الأكثر شيوعًا لأن نفقًا يعمل ما زال يعطي 403 من موقع يتصرف بشكل صحيح مع كل الآخرين.
اختبر المسارين منفصلين حتى لا يختلط العنوانان.
curl -sS -o /dev/null -w 'status=%{http_code}\n' --noproxy '*' https://198.51.100.20/private
curl -sS -o /dev/null -w 'status=%{http_code}\n' -x http://203.0.113.10:3128 https://198.51.100.20/privateالطلب الأول يبيّن ما يجيب به الأصل عن عنوانك، والثاني يبيّن ما يجيب به عن عنوان الوكيل. تطابق زوج من 403 يشير إلى قواعد تفويض الأصل؛ و200 يتبعه 403 يشير إلى مسار الوكيل. اسأل مالك الأصل أي عناوين مصدر تقبلها مجموعة القواعد فعلًا بدل افتراض أن تجمع VPN مشمول.
اختبر كل حد بطلب يعزله
اعزل طبقة الوكيل بأن تطلب منها شيئًا لا تستطيع رفضه لأسباب تطبيقية. طلب CONNECT إلى مضيف مسموح للوكيل بالوصول إليه، مع تجاهل المخرجات، يخبرك ما إذا كان قبول النفق يعمل أصلًا.
curl -sSv -o /dev/null -x http://203.0.113.10:3128 https://198.51.100.20/ 2>&1 | grep -E 'CONNECT|HTTP/1.1|Proxy-Authenticate'
إذا طبع ذلك 200 لطلب CONNECT ثم مصافحة TLS، فقبول الوكيل سليم والخطأ 403 اللاحق جاء من الأصل. وإذا طبع 407، فزوّد بيانات اعتماد الوكيل عبر --proxy-user وأعد المحاولة قبل استخلاص أي نتيجة عن الموقع. وإذا طبع 403 على سطر CONNECT، فقائمة السماح الخاصة بالوكيل هي الحد الذي يجب فحصه، والتطبيق غير معني.
أبقِ بيانات الاعتماد خارج سجل الصدفة وخارج النصوص المنسوخة. كلمة مرور الوكيل المكتوبة في سطر أوامر مرئية لمستخدمين محليين آخرين، وأثر CONNECT ملتقط مع بيانات اعتماد أسوأ من عدم وجود أثر.
أبقِ الحكم مقروءًا بدل إعادة كتابة الصفحة
بعد أن تعرف أي مكوّن رفض، احفظ ذلك الجواب. الوكيل العكسي الذي يعيد تسمية 403 صادر عن الأصل كأنه مهلة 504، أو يستبدله بصفحة نجاح، يخفي قرار تفويض خلف حكاية توفر ويرسل المستجيب التالي إلى الفريق الخطأ. صفحات الخطأ المخصصة جيدة عندما تحافظ على الحالة وتضيف سياقًا.
التخزين المؤقت يستحق العناية نفسها. يحكم RFC 9111 كيفية إعادة استخدام الذاكرات المشتركة للاستجابات، والرفض المنتج لمتصل واحد يجب ألا يُسلّم لآخر كأنه إذن. إذا خُزّنت استجابات الرفض أصلًا، فأبقها خاصة ومحدودة النطاق، ولا تضف قاعدة حداثة عامة لمجرد تقليل حركة المنبع.
اختم بحكم مكتوب يسمّي المكوّن، والحالة التي أنتجها، وعنوان المصدر الذي رآه الأصل. سجّل الطلب الدقيق، وإعدادات الوكيل السارية، والوقت، حتى يمكن مطابقة التقرير التالي بالأدلة نفسها بدل إعادة اشتقاقه من الذاكرة. ذلك السجل يجيب عن التقرير التالي في ثوانٍ ويمنع تشخيص الخطأ 403 نفسه مرة أخرى كعطل VPN.