Squid မှတစ်ဆင့် Proxychains- ပေါ့တ် 80 တွင် CONNECT ကန့်သတ်ချက်များ
ဦးတည်ပေါ့တ် 80 ကို ငြင်းပယ်သောအခါ သာမန် HTTP ပရောက်စီ တောင်းဆိုချက်များနှင့် proxychains HTTP CONNECT ဥမင်များကို ခွဲခြားပါ။
ဘရောက်ဇာသည် Squid မှတစ်ဆင့် HTTP စာမျက်နှာကို ဖွင့်သည်။ ထိုတူညီသော ဦးတည်ချက်သည် proxychains အောက်တွင် မအောင်မြင်ပါ။ ယင်းသည် ပရိုဂရမ်နှစ်ခုအနက် တစ်ခုက မှားယွင်းသော ပရောက်စီ IP ကို ရွေးချယ်ခဲ့သည်ဟု မဆိုလိုပါ။
HTTP ကို နားလည်သော သာမန် client သည် ဝဘ်တောင်းဆိုချက်ကို HTTP ပရောက်စီ ပုံစံဖြင့် ရှေ့ပရောက်စီသို့ ပို့နိုင်သည်။ သို့သော် ယေဘုယျ socket အကာအုပ်သည် အပလီကေးရှင်း ဖွင့်လိုသော ချိတ်ဆက်မှုအတွက် ဘိုက်ဥမင် လိုအပ်သည်။ မိမိကွင်းဆက်ရှိ HTTP ပရောက်စီအတွက် proxychains သည် CONNECT ကို အသုံးပြုသည်။
ဆိုလိုသည်မှာ ပေါ့တ် 80 ရှိ ရိုးရှင်းသော စာသားဝက်ဘ်ဆိုက်သည် ပေါ့တ် 80 အတွက် CONNECT တောင်းဆိုချက် ထုတ်ပေးနိုင်သည်။ အတည်ပြုထားသော TLS ပေါ့တ်စာရင်းသို့သာ CONNECT ကို ခွင့်ပြုသော Squid မူဝါဒသည် ပေါ့တ် 80 သို့ သာမန် HTTP တောင်းဆိုချက်များ ခွင့်ပြုထားသော်လည်း ထိုဥမင်ကို ငြင်းပယ်နိုင်သည်။
ဟို့စ်အမည်များသာမက တောင်းဆိုချက်များကို နှိုင်းယှဉ်ပါ
proxychains-ng ၏ စာရွက်စာတမ်းသည် HTTP CONNECT ပံ့ပိုးမှုကို ဖော်ပြသည်။ Squid ၏ ဝင်ရောက်ခွင့်စည်းမျဉ်းများသည် နည်းလမ်းနှင့် ဦးတည်ပေါ့တ်ကို ခွဲခြားနိုင်သည်။ ယင်းတို့သည် တူညီသော ဝက်ဘ်ဆိုက်သို့ မတူညီသော တောင်းဆိုချက်လမ်းကြောင်းများ ဖြစ်သည်။
မပြောင်းလဲမီ ငြင်းပယ်မှုနှင့် ရည်ရွယ်ထားသော မူဝါဒကို ဖတ်ပါ။ CONNECT ဝင်ရောက်ခွင့်ကို ပေါ့တ်တိုင်းသို့ တိုးချဲ့ခြင်းသည် ကြီးမားသော ပြောင်းလဲမှု ဖြစ်သည်။ အကာအုပ် မကိုက်ညီမှုအတွက် မူလတုံ့ပြန်မှု မဖြစ်သင့်ပါ။
အပလီကေးရှင်းတွင် မူရင်း HTTP ပရောက်စီ ပံ့ပိုးမှု ရှိပါက ၎င်းကို အသုံးပြုခြင်းဖြင့် ရိုးရှင်းသော စာသား HTTP အတွက် မလိုအပ်သော ယေဘုယျဥမင်ကို ရှောင်နိုင်သည်။ အကယ်၍ ကုန်ကြမ်း TCP ဥမင် အမှန်တကယ် လိုအပ်ပါက ၎င်းကို ပံ့ပိုးပေးသော အတည်ပြုထားသော ပရောက်စီပရိုတိုကောနှင့် ပေါ့တ်မူဝါဒကို ရွေးပါ။
အောင်မြင်သော ဘရောက်ဇာတောင်းဆိုချက်သည် ပရောက်စီ၏ လက်လှမ်းမီမှုနှင့် ပံ့ပိုးထားသော တောင်းဆိုချက်မုဒ်တစ်ခုအကြောင်း အသုံးဝင်သော သက်သေဖြစ်သည်။ သို့သော် ဥမင်နည်းလမ်းတိုင်း၊ ဦးတည်ပေါ့တ် သို့မဟုတ် အပလီကေးရှင်းပရိုတိုကောတိုင်းကို ထိုပရောက်စီမှတစ်ဆင့် ခွင့်ပြုသည်ဟု သက်သေမပြပါ။