Apache وAllowCONNECT ومنافذ وجهة HTTPS
ميّز بين المنفذ الذي يستخدمه العملاء للوصول إلى وكيل Apache ومنافذ الوجهة التي يسمح بها mod_proxy_connect داخل الأنفاق.
يستمع وكيل Apache لديك على المنفذ 3128. يصل عميل إليه بنجاح، لكن خدمة HTTPS على المنفذ 8443 تفشل. تغيير منفذ استماع الوكيل لا يُرجَّح أن يعالج هذا الفرق تحديدًا.
يتصل العميل أولًا بمستمع الوكيل. ثم يحدد طلب CONNECT الخاص به مضيف وجهة ومنفذًا منفصلين. يستطيع Apache قبول الاتصال الأول ورفض العملية الثانية.
اقرأ AllowCONNECT كسياسة وجهة
في Apache 2.4، يتولى mod_proxy_connect معالجة طلبات CONNECT الواردة. تتحكم توجيهات AllowCONNECT في منافذ الوجهة المتاحة لتلك الطلبات. القيمة الافتراضية الموثقة هي 443 و563.
AllowCONNECT 443 8443يختار هذا المثال منفذي الوجهة هذين. وهو يستبدل الاختيار الافتراضي؛ ولا يضيف 8443 مع الاحتفاظ صامتًا بكل منفذ افتراضي. استخدم التوجيه في إعداد الخادم أو المضيف الافتراضي المناسب.
أبقِ قواعد تفويض العملاء الخاصة بالوكيل في مكانها. منفذ وجهة مسموح لا يقول شيئًا عن العميل الذي يجوز له استخدام الخدمة، وليس بديلًا عن تقييد مضيف الوجهة عند الحاجة إليه.
مثال الوكيل العكسي يجيب عن سؤال مختلف
كثيرًا ما تعرض نتائج البحث عن Apache وHTTPS موقعًا عامًا يعيد التوجيه إلى خادم خلفي ثابت. هذا الإعداد ليس الطريقة التي يطلب بها المتصفح من وكيل أمامي فتح نفق CONNECT إلى موقع مختار. ونسخ توجيهات المسار الخاصة به قد يترك مشكلة الوكيل الأصلية دون مساس.
عند تشخيص فشل، سجّل المستمع الذي وصل إليه العميل، وسلطة CONNECT التي طلبها، ورد الوكيل. إذا نجح CONNECT وفشل TLS بعد ذلك، فقد أدّت إذن منفذ الوجهة دوره بالفعل. تابع مع فشل TLS بدلًا من توسيع AllowCONNECT مرارًا.