Apache AllowCONNECT va HTTPS maqsad portlari
Mijozlar Apache proksisiga ulanish uchun ishlatadigan portni mod_proxy_connect tunnellar ichida ruxsat beradigan maqsad portlaridan ajratib oling.
Apache proksingiz 3128 portni tinglaydi. Mijoz unga muvaffaqiyatli ulanadi, ammo 8443 portidagi HTTPS xizmati ishlamaydi. Proksining tinglash portini o'zgartirish bu farqni hal qilishi dargumon.
Mijoz avval proksi tinglovchisiga ulanadi. Uning CONNECT so'rovi keyin alohida maqsad xost va portni ko'rsatadi. Apache birinchi ulanishni qabul qilib, ikkinchi amalni rad etishi mumkin.
AllowCONNECT ni maqsad siyosati sifatida o'qing
Apache 2.4 uchun mod_proxy_connect kiruvchi CONNECT so'rovlarini boshqaradi. Uning AllowCONNECT direktivasi bu so'rovlar uchun mavjud maqsad portlarini boshqaradi. Hujjatlashtirilgan standart qiymat 443 va 563.
AllowCONNECT 443 8443
Bu misol o'sha ikki maqsad portini tanlaydi. U standart tanlovni almashtiradi; barcha standart portlarni jimgina saqlab, 8443 ni qo'shmaydi. Direktivani tegishli server yoki virtual xost konfiguratsiyasida ishlating.
Proksining mijoz avtorizatsiyasi qoidalarini joyida saqlang. Ruxsat etilgan maqsad porti qaysi mijoz xizmatdan foydalanishi mumkinligi haqida hech narsa demaydi va kerak bo'lganda maqsad xost cheklovi o'rnini bosmaydi.
Teskari proksi misoli boshqa savolga javob beradi
Apache va HTTPS bo'yicha qidiruv natijalari ko'pincha ommaviy veb-saytning qat'iy backendga yo'naltirilishini ko'rsatadi. Bu konfiguratsiya brauzerning oldingi proksidan tanlangan saytga CONNECT tunnel ochishini so'rash usuli emas. Uning marshrutlash direktivalarini ko'chirish asl proksi muammosini o'zgarmas qoldirishi mumkin.
Nosozlikni tekshirganda mijoz yetib borgan tinglovchini, so'ralgan CONNECT vakolatini va proksi javobini yozib oling. Agar CONNECT muvaffaqiyatli bo'lib, keyin TLS ishlamasa, maqsad port ruxsati o'z qismini bajargan. TLS nosozligi bilan davom eting, AllowCONNECT ni qayta-qayta kengaytirish o'rniga.