Privoxy- အသုံးပြု၍ HTTP ပရောက်စီ client ကို SOCKS ဥမင်သို့ ချိတ်ဆက်ခြင်း

SSH ရွေ့လျားဥမင်သည် PuTTY ၏ ရွေ့လျားပို့ဆောင်မှု အပါအဝင် SOCKS မျက်နှာပြင်ကို ပေးသည်။ HTTP ပရောက်စီကိုသာ လက်ခံသော application သည် ထို port ကို HTTP ဟု ခေါ်ရုံဖြင့် အသုံးပြု၍ မရပါ။

၎င်းတို့အကြား ဒေသတွင်း protocol တံတားတစ်ခု ရှိနိုင်သည်။ application သည် HTTP ပရောက်စီ တောင်းဆိုချက်များကို တံတားသို့ ပို့ပြီး တံတားက SOCKS ဝန်ဆောင်မှုမှတစ်ဆင့် ခရီးဆုံး ချိတ်ဆက်မှုများကို ဖွင့်သည်။

Privoxy သည် ဤအစီအစဉ်ကို ၎င်း၏ forwarding စည်းမျဉ်းများဖြင့် မှတ်တမ်းတင်ထားသည်။ ရှိပြီးသား ဒေသတွင်း SOCKS5 ဥမင်အတွက် configuration အပိုင်းမှာ ဤသို့ဖြစ်သည်။

forward-socks5 / 127.0.0.1:1080 .

application သည် Privoxy ၏ HTTP listener သို့ ချိတ်ဆက်သည်၊ port 1080 သို့ မဟုတ်ပါ။ ထို listener ကို ရည်ရွယ်ထားသော access policy အောက်တွင် ဒေသတွင်း ထားရှိပါ။ စည်းမျဉ်းအဆုံးရှိ အစက်တွင် မှတ်တမ်းတင်ထားသော အဓိပ္ပာယ် ရှိသည်။ ၎င်းသည် ပျောက်ဆုံးနေသော အင်တာနက် host အမည်အတွက် နေရာလွတ် မဟုတ်ပါ။

ဤသည် protocol ဘာသာပြန်ခြင်း ဖြစ်သည်

Privoxy ၏ forwarding မှတ်တမ်းသည် SOCKS forwarding syntax နှင့် host အမည် ကိုင်တွယ်မှုကို ရှင်းပြသည်။ သာမန် TCP port forwarding သည် ထို ဘာသာပြန်ချက်ကို မလုပ်ပါ။ client ၏ HTTP byte များကို မပြောင်းလဲဘဲ SOCKS listener သို့ ပို့ဆောင်ပေးသည်၊ ထို listener က SOCKS ညှိနှိုင်းမှုကို မျှော်လင့်နေဆဲ ဖြစ်သည်။

တံတားသည် သင်နားလည်ရမည့် configuration ၏ အစိတ်အပိုင်းလည်း ဖြစ်လာသည်။ Privoxy တွင် ၎င်း၏ အကြောင်းအရာ စစ်ထုတ်မှုနှင့် access ဆက်တင်များ ရှိနိုင်သည်။ ၎င်းကို ထည့်ခြင်းသည် မူရင်း application က SOCKS ကို မူရင်းအတိုင်း ပံ့ပိုးသည်နှင့် မတူပါ။

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

application သည် SOCKS ကို တိုက်ရိုက် အသုံးပြုနိုင်လျှင် အပိုအစိတ်အပိုင်းသည် မလိုအပ်နိုင်ပါ။ တံတားကို အမှန်တကယ် protocol မကိုက်ညီမှုကို ဖြေရှင်းရန် အသုံးပြုပြီး listener နှင့် အပေါ်ပိုင်းစီးကြောင်းကို ရှင်းလင်းစွာ ခွဲခြားပါ။