သင့် Apache ပရောက်စီသည် ပေါက် 3128 တွင် နားထောင်နေသည်။ ဖောက်သည်တစ်ဦး ထိုသို့ အောင်မြင်စွာ ရောက်သည်၊ သို့သော် ပေါက် 8443 ရှိ HTTPS ဝန်ဆောင်မှု မအောင်မြင်ပါ။ ပရောက်စီ၏ နားထောင်သည့်ပေါက်ကို ပြောင်းခြင်းသည် ထိုကွာခြားချက်ကို ဖြေရှင်းနိုင်ဖွယ် မရှိပါ။

ဖောက်သည်သည် ပထမဦးစွာ ပရောက်စီနားထောင်သူနှင့် ချိတ်ဆက်သည်။ ထို့နောက် ၎င်း၏ CONNECT တောင်းဆိုချက်က သီးခြား ဦးတည်လက်ခံနှင့် ပေါက်ကို အမည်ပေးသည်။ Apache သည် ပထမချိတ်ဆက်မှုကို လက်ခံပြီး ဒုတိယလုပ်ဆောင်ချက်ကို ငြင်းနိုင်သည်။

AllowCONNECT ကို ဦးတည်မူဝါဒအဖြစ် ဖတ်ပါ

Apache 2.4 အတွက် mod_proxy_connect သည် ဝင်လာသော CONNECT တောင်းဆိုချက်များကို ကိုင်တွယ်သည်။ ၎င်း၏ AllowCONNECT ညွှန်ကြားချက်က ထိုတောင်းဆိုချက်များအတွက် ရရှိနိုင်သော ဦးတည်ပေါက်များကို ထိန်းချုပ်သည်။ မှတ်တမ်းတင်ထားသော မူလတန်ဖိုးမှာ 443 နှင့် 563 ဖြစ်သည်။

AllowCONNECT 443 8443

ဤဥပမာသည် ထိုဦးတည်ပေါက် နှစ်ခုကို ရွေးချယ်သည်။ ၎င်းသည် မူလရွေးချယ်မှုကို အစားထိုးသည်၊ မူလပေါက်အားလုံးကို တိတ်တဆိတ် ထိန်းထားရင်း 8443 ကို ထပ်မံထည့်ခြင်း မဟုတ်ပါ။ သက်ဆိုင်ရာ ဆာဗာ သို့မဟုတ် ကွန်ရက်လက်ခံ ဖွဲ့စည်းမှုတွင် ညွှန်ကြားချက်ကို အသုံးပြုပါ။

ပရောက်စီ၏ ဖောက်သည်ခွင့်ပြုချက် စည်းမျဉ်းများကို ဆက်လက်ထားရှိပါ။ ခွင့်ပြုထားသော ဦးတည်ပေါက်သည် မည်သည့်ဖောက်သည်က ဝန်ဆောင်မှုကို အသုံးပြုနိုင်သည်ကို မဆိုပါ၊ လိုအပ်သည့်အခါ ဦးတည်လက်ခံ ကန့်သတ်ချက်၏ အစားထိုး မဟုတ်ပါ။

ပြောင်းပြန်ပရောက်စီ ဥပမာသည် အခြားမေးခွန်းကို ဖြေသည်

Apache နှင့် HTTPS အတွက် ရှာဖွေမှုရလဒ်များသည် ပုံသေ backend သို့ ပေးပို့သည့် အများပြည်သူ ဝဘ်ဆိုက်ကို မကြာခဏ ပြသသည်။ ထိုဖွဲ့စည်းမှုသည် ဘရောက်ဇာက ရွေးချယ်ထားသော ဝဘ်ဆိုက်သို့ CONNECT ဥမင် ဖွင့်ရန် ရှေ့ပရောက်စီကို တောင်းဆိုသည့် နည်းလမ်း မဟုတ်ပါ။ ၎င်း၏ လမ်းကြောင်းညွှန်ကြားချက်များကို ကူးယူခြင်းက မူလပရောက်စီ ပြဿနာကို မထိဘဲ ထားနိုင်သည်။

ချို့ယွင်းမှုကို စစ်ဆေးရာတွင် ဖောက်သည်ရောက်ခဲ့သော နားထောင်သူ၊ တောင်းဆိုခဲ့သော CONNECT အခွင့်အာဏာနှင့် ပရောက်စီ၏ ပြန်ကြားချက်ကို မှတ်တမ်းတင်ပါ။ CONNECT အောင်မြင်ပြီး နောက်ပိုင်း TLS မအောင်မြင်ပါက ဦးတည်ပေါက်ခွင့်ပြုချက်သည် ၎င်း၏အပိုင်းကို ပြီးစီးထားပြီ ဖြစ်သည်။ AllowCONNECT ကို ထပ်ခါတလဲလဲ ချဲ့ထွင်မည့်အစား TLS ချို့ယွင်းမှုဖြင့် ဆက်လုပ်ပါ။

ဆက်စပ်ဆောင်းပါးများ