Ncat ၏ HTTP ပရောက်စီမုဒ်နှင့် ပုံသေ TCP ရီလေး

client → local TCP relay → existing forward proxy → destination

ဤဖွဲ့စည်းမှုတွင် ရီလေးသည် ပုံသေ အထက်စီးကြောင်း တစ်ခုရှိသည်။ ကလိုင်း၏ တောင်းဆိုချက်ကို မပြောင်းလဲဘဲ ရှိပြီးသား ရှေ့ပရောက်စီထံ ပို့ပေးသည်။ ထိုပရောက်စီသည် ပကတိ URL သို့မဟုတ် CONNECT ပစ်မှတ်ကို ဖတ်ပြီး မူဝါဒကို ကျင့်သုံးကာ ခရီးဆုံး ချိတ်ဆက်မှုကို ဖွင့်သည်။

ရီလေးကို ဝဘ်ဆိုက်သို့ တိုက်ရိုက် ချိန်ရွယ်ခြင်းသည် စာချုပ်ကို ပြောင်းလဲသည်။ ရှေ့ပရောက်စီသည် ခရီးဆုံးများကို ရွေးချယ်ပြီး HTTP ဘောင်ခတ်မှုနှင့် ချိတ်ဆက်မှု အပြုအမူကို ကိုင်တွယ်ရမည်။ ပထမလိုင်းမှ ဟိုစ့်အမည်ကို ထုတ်ယူရုံဖြင့် မလုံလောက်ပါ။

Nmap ၏ Ncat သည် HTTP ကို နားလည်သော နားထောင်မုဒ်ကို သီးခြား ပေးသည်။

ncat --listen 127.0.0.1 3128 --proxy-type http

ဤ loopback နမူနာသည် Ncat ၏ ပရောက်စီ အကောင်အထည်ဖော်မှုကို အသုံးပြုသည်၊ nc တိုင်းတွင် ရှိသော လက္ခဏာ မဟုတ်ပါ။ ၎င်း၏ နားထောင်ဘက် ပရောက်စီသည် HTTP နည်းလမ်းများနှင့် CONNECT ကို ကိုင်တွယ်သည်။ ၎င်း၏ ကလိုင်းဘက် SOCKS ရွေးချယ်စရာများသည် နားထောင်မုဒ်တွင် SOCKS ဆာဗာကို မထူထောင်ပါ။ အမြဲတမ်း မျှဝေသော ဝန်ဆောင်မှုအတွက် ရည်ရွယ်ချက်ရှိသော ချိတ်ဆက်မှု စီမံခန့်ခွဲမှု၊ ဝင်ရောက်ခွင့် ထိန်းချုပ်မှုနှင့် မှတ်တမ်းတင်မှုလည်း လိုအပ်သည်။

စောင့်ကြည့်ရန် ကုဒ်ဝှက်မှု နယ်နိမိတ်ကို ရှာပါ။ ရိုးရိုး HTTP ပရောက်စီ ချိတ်ဆက်မှုပေါ်ရှိ ရီလေးသည် ပရောက်စီ တောင်းဆိုချက်များနှင့် ပြန်ကြားချက်များကို မြင်နိုင်သည်။ CONNECT ပြီးနောက် ခရီးဆုံး၏ HTTPS သည် TLS ဘိုက်များဖြစ်ပြီး ဖတ်နိုင်သော စာမျက်နှာ အကြောင်းအရာ မဟုတ်ပါ။ ပရောက်စီအထိ TLS သည် ထိုလင့်ခ်ရှိ ကနဦး ပရောက်စီ ဖလှယ်မှုကိုပင် ဖုံးကွယ်သည်။ အနက်ဖွင့်ထားသော အရောင်းအဝယ်များအတွက် ကလိုင်းနှင့် ပရောက်စီ ရောဂါစစ်ဆေးမှုကို သုံးပါ၊ အထောက်အထားများ သို့မဟုတ် ထိခိုက်လွယ်သော URL များ ပါဝင်နိုင်သည့် မှတ်တမ်းများကို ကာကွယ်ပါ။