AllowCONNECT של Apache ופורטי יעד של 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 שוב ושוב.