သီးသန့် proxy သည် သင့် application ကိုသာ လက်ခံနိုင်ပါသလား
App အမည်နှင့် User-Agent ကန့်သတ်ချက်များ၏ အတိုင်းအတာကို ရှင်းပြပြီး အထောက်အထားပိုင်ဆိုင်မှုနှင့် တိကျသော executable တစ်ခု၏ သက်သေကို ခွဲခြားသည်။
Forward proxy သည် အထောက်အထားများ တောင်းခံနိုင်၊ ရင်းမြစ် ကွန်ရက်များကို ကန့်သတ်နိုင်၊ ဦးတည်ရာ မူဝါဒကို ကျင့်သုံးနိုင်သည်။ သို့သော် ထိန်းချုပ်မှုများသည် ခေါ်ဆိုသူသည် တိကျသော executable တစ်ခုဖြစ်ကြောင်း မသက်သေပြနိုင်ပါ။
User-Agent သို့မဟုတ် စိတ်ကြိုက် header ကို client က ပေးပြီး ကူးယူနိုင်သည်။ ထို့ကြောင့် တောင်းဆိုချက်ထဲရှိ app အမည်သည် သီးသန့် proxy သို့ တစ်ခုတည်းသော တံခါးပေါက်အဖြစ် မသင့်လျော်ပါ။
သင်အမှန်တကယ် စစ်ဆေးနိုင်သည်ကို ဖော်ပြသော access ထိန်းချုပ်မှုများကို သုံးပါ- ခွင့်ပြုထားသော အကောင့်၊ ခွင့်ပြုထားသော ကွန်ရက်တည်နေရာနှင့် ရည်ရွယ်ထားသော ဦးတည်ရာများ။ Application ၏ ပုံမှန် လျှို့ဝှက်ချက် စီမံခန့်ခွဲမှု ဒီဇိုင်းဖြင့် client အထောက်အထားများကို ကာကွယ်ပြီး ပယ်ဖျက်ပါ။ ထို့နောက် ခွင့်ပြုထားသော နှင့် ငြင်းပယ်ထားသော တောင်းဆိုချက်များကို စစ်ဆေးပါ ရည်ရွယ်ထားသော access နယ်နိမိတ်နှင့် ယှဉ်၍။
ပိုမိုခိုင်မာသော client authentication သည်ပင် အတည်ပြုထားသော key သို့မဟုတ် အထောက်အထား ပိုင်ဆိုင်မှုကို တည်ဆောက်သည်။ အခြား မည်သည့် program မျှ ထို အထောက်အထားကို မသုံးနိုင်ဟု လုံးဝ အာမခံချက်အဖြစ် ဖော်ပြသင့်သည် မဟုတ်ပါ။
လိုအပ်ချက်သည် စီမံခန့်ခွဲထားသော စက်ပစ္စည်းများ သို့မဟုတ် application များ၏ ခိုင်မာမှုကို ကျင့်သုံးခြင်းဖြစ်ပါက ၎င်းကို အပိုစနစ်လိုအပ်ချက်အဖြစ် သတ်မှတ်ပါ။ ခေါ်ဆိုသူ ကိုယ်တိုင်ရွေးချယ် ပေးပို့သော စာလုံးတန်းကိုသာ မှတ်မိသော Squid header စည်းမျဉ်းဖြင့် ၎င်းကို ကတိမပေးပါနှင့်။