အဖွဲ့တစ်ဖွဲ့သည် bypass စာလုံးတစ်ကြောင်းကို မျှဝေ environment ဖိုင်ထဲ ထည့်သည်။ curl က တိုက်ရိုက်သွားသည်၊ အခြား application က proxy ကို သုံးသည်၊ ကွန်တိန်နာက ထပ်မံကွဲပြားစွာ ပြုမူသည်။ မျှဝေဖိုင်က စာလုံးများကို ဖြန့်ဝေခဲ့သည်။ မျှဝေ parser တစ်ခုကို မဖြန့်ဝေခဲ့ပါ။

တည်တံ့သော အရာမှာ မူဝါဒဖြစ်သည်။ မည်သည့် ဦးတည်ရာများ တိုက်ရိုက်ဖြစ်သင့်သည်၊ မည်သည့် အခြေအနေများအောက်တွင်။ ယင်းကို program တစ်ခုချင်း လိုအပ်သော စာလုံးကြောင်းနှင့် ခွဲထားပါ။

မျှော်လင့်ထားသော လမ်းကြောင်းများကို အရင်ရေးပါ

လွယ်ကူသော အောင်မြင်မှုများသာမက နယ်စပ်ကိစ္စများ အပါအဝင် ကိုယ်စားပြု လိပ်စာများကို သုံးပါ။

ဦးတည်ရာ ပုံစံမူဝါဒပိုင်ရှင်အတွက် မေးခွန်း
မိခင် domain၎င်းကို bypass လုပ်သင့်သလား၊ သို့မဟုတ် ၎င်း၏ ကလေးများကိုသာလား။
Subdomain တစ်ခု၎င်းသည် တူညီသော လမ်းကြောင်းကို အမွေဆက်ခံသလား။
တိုက်ရိုက် private IPထို လိပ်စာသည် ဤ client မှ တိုက်ရိုက် ရောက်နိုင်သလား။
hostname အောက်ရှိ တူညီသော ဝန်ဆောင်မှုအမည်အခြေခံနှင့် လိပ်စာအခြေခံ တောင်းဆိုမှုများ ကိုက်ညီသင့်သလား။
အခြား ဝန်ဆောင်မှု portခြွင်းချက်သည် host ကို လွှမ်းခြုံသလား၊ listener တစ်ခုကိုလား။

ထို့နောက် အသုံးပြုသူများကို ဖော်ထုတ်ပါ။ image ဆွဲသော daemon၊ ကွန်တိန်နာအတွင်းရှိ program၊ ဘာသာစကား HTTP library နှင့် အပြန်အလှန် browser တို့သည် သီးခြား entry များ ဖြစ်နိုင်သည်။ Docker client proxy ပြင်ဆင်မှုသည် ကွန်တိန်နာ၏ environment တန်ဖိုးများကို ဖြည့်နိုင်ပြီး အတွင်းရှိ client တိုင်း တူညီသော ကိုက်ညီမှုစည်းမျဉ်းများကို အကောင်အထည်ဖော်ရန် မလိုအပ်ပါ။

မျက်စိမှိတ် ကူးယူခြင်းမဟုတ်ဘဲ ဘာသာပြန်ပါ

စစ်မှန်သော ကွာခြားမှု၏ မှတ်တမ်းတင်ထားသော ဥပမာတစ်ခုမှာ မိခင် domain နယ်စည်းဖြစ်သည်။ curl ၏ domain ခြွင်းချက်သည် အမည်ပေးထားသော domain နှင့် ကိုက်ညီသော ကလေးများကို လွှမ်းခြုံသည်။ .NET ၏ environment မူဝါဒသည် အလွတ်အမည်နှင့် ရှေ့ဆုံးအစက်ပါ subdomain ပုံစံကို ခွဲခြားသည်။ „အမြဲ ရှေ့ဆုံးအစက် ထည့်ပါ“ ဟူသော စကြဝဠာစည်းမျဉ်းသည် မူဝါဒနှစ်ခုလုံးကို ယုံကြည်စိတ်ချစွာ ဖော်ပြနိုင်မည် မဟုတ်ပါ။

IP အပိုင်းအခြား ပံ့ပိုးမှုသည်လည်း အသုံးပြုသူနှင့် ၎င်း၏ ဗားရှင်းအပေါ် မူတည်သည်။ standalone curl အသစ်ရှိသော စက်တစ်ခုသည် ပိုဟောင်းသော libcurl နှင့် ချိတ်ထားသော application သို့မဟုတ် လုံးဝအခြား library သုံးသော client ကို ဆက်လက်လည်ပတ်နိုင်သည်။ လည်ပတ်မှုစနစ် ထုတ်ဝေမှုသည် ပြည့်စုံသော client စာရင်း မဟုတ်ပါ။

client တစ်ခုချင်းအတွက် ၎င်း ပံ့ပိုးသော ပြင်ဆင်မှု interface နှင့် ရည်ရွယ်ထားသော လမ်းကြောင်းများ၏ အသေးငယ်ဆုံး ဖော်ပြချက်ကို မှတ်တမ်းတင်ပါ။ တိုတောင်းပြီး ရှင်းလင်းသော host စာရင်းသည် အဓိပ္ပာယ်ကို မည်သူမျှ မရှင်းပြနိုင်သော လိမ္မာသော ပုံစံထက် ပိုကောင်းနိုင်သည်။

ပြင်ဆင်မှု အထောက်အထားကို ချိတ်ဆက်မှု အထောက်အထားနှင့် ခွဲထားပါ

ခွဲခြမ်းစိတ်ဖြာထားသော setting သို့မဟုတ် လမ်းကြောင်းဆုံးဖြတ်ချက် API သည် program ရွေးချယ်ခဲ့သည်ကို ပြသနိုင်သည်။ တောင်းဆိုမှု ရလဒ်က ထို လမ်းကြောင်း အသုံးပြုနိုင်ခဲ့သလားကို ပြသည်။ .NET တွင်၊ HttpClient.DefaultProxy.IsBypassed သည် default proxy ကို အသုံးပြုနေသော မူဝါဒဖြစ်သည့်အခါ ထို ပြင်ဆင်မှုဘက်မှ စစ်ဆေးမှုကို ပေးသည်။ တောင်းဆိုမှု အချိန်ကုန်သွားခြင်းကြောင့်သာ မရောက်နိုင်သော တိုက်ရိုက်ဝန်ဆောင်မှုကို bypass parser ကျရှုံးမှုအဖြစ် မစစ်ဆေးပါနှင့်။

client သို့မဟုတ် base image ကို အပ်ဒိတ်လုပ်သည့်အခါ နယ်စပ် ဦးတည်ရာများကို ထိန်းသိမ်းထားပါ။ ၎င်းတို့သည် ဖိုင်ထဲတွင် အလားတူပုံရသော domain entry နှစ်ခု ရှိနေရသည့် အကြောင်းကို အဖွဲ့တစ်ခုလုံး ပြန်လည်ရှာဖွေရန် မလိုဘဲ အနာဂတ် သဟဇာတပြောင်းလဲမှုများကို မြင်သာစေသည်။

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