အက်ပ်တွင် SOCKS ရွေးချယ်မှု မရှိသော်လည်း ရွေးချယ်ထားသော TCP လိပ်စာသို့ ချိတ်ဆက်နိုင်သည်။ ပုံသေပစ်မှတ်ရှိသော အဒက်တာသည် ခရီးဆုံးတစ်ခုအတွက် SOCKS စကားပြောဆိုမှုကို ပေးနိုင်သည်။ ၎င်းသည် အခြားသော အထွေထွေ ရှေ့ပိုင်း ပရောက်စီ ဖြစ်လာရန် မလိုအပ်ပါ။

SOCKS4A ပေးသော socat တည်ဆောက်မှုများအတွက် သရုပ်ပြ အစီအစဉ်မှာ ဤသို့ဖြစ်သည်-

socat TCP4-LISTEN:9443,bind=127.0.0.1,reuseaddr,fork \
  SOCKS4A:127.0.0.1:service.example.net:443,socksport=1080

SOCKS အဆုံးမှတ်သည် ဒေသခံ ပေါ့ 1080 ဖြစ်သည်။ အဒက်တာသည် ဒေသခံ ပေါ့ 9443 တွင် နားထောင်ပြီး ထို အဆုံးမှတ်ထံမှ service.example.net:443 ကို တောင်းဆိုသည်။ ဤအရာများသည် နမူနာ တန်ဖိုးများဖြစ်ပြီး ပြည့်စုံသော ဝန်ဆောင်မှု ဖြန့်ကျက်မှု မဟုတ်ပါ။

အဒက်တာတွင် ပုံသေ ပစ်မှတ် တစ်ခု ရှိသည်

လက်ခံသော TCP ချိတ်ဆက်မှုတိုင်းသည် တူညီသော ဝန်ဆောင်မှုကို တောင်းဆိုသည်။ 9443 သို့ ချိတ်ဆက်သော အက်ပ်သည် ၎င်း၏ ပုံမှန် ပရိုတိုကော ဘိုက်များကို ပေးသည်။ socat သည် SOCKS4A ညှိနှိုင်းမှုကို ပေးသည်။ 9443 သို့ HTTP CONNECT တောင်းဆိုချက် အသစ် ပို့ခြင်းသည် အခြား ခရီးဆုံးကို ရွေးမည် မဟုတ်ပါ—ထို ဘိုက်များကို ပုံသေ ဝန်ဆောင်မှုသို့ ဆက်ပို့မည်။

SOCKS4A သည် အဝေးမှ ဖြေရှင်းရန် SOCKS အဆုံးမှတ်သို့ လက်ခံဆောင် အမည်ကို ပေးသည်။ ၎င်းသည် ဖောက်သည်က ရွေးချယ်သော လိပ်စာကို အသုံးပြုသည့် SOCKS4 ပုံစံနှင့် ကွာခြားသည်။ ရွေးချယ်ထားသော အပေါ်ပိုင်း စီးကြောင်း—SOCKS4 ပရောက်စီ စာရင်းမှ အများသူငှာ ကိုယ်စားလှယ်လောင်း အပါအဝင်—သည် SOCKS4A လက်ခံဆောင် အမည် ကိုင်တွယ်မှုနှင့် လိုအပ်သော စစ်မှန်ကြောင်း အတည်ပြုမှုကို ပံ့ပိုးရမည်။ ဤနမူနာသည် SOCKS5 စကားဝှက် လော့ဂ်အင် နည်းလမ်း မဟုတ်ပါ။

ဒေသခံအဖြစ် ချိတ်ဆက်ပြီး စစ်မှန်သော ဝန်ဆောင်မှုကို ဖော်ထုတ်ပါ

HTTPS URL ကို https://127.0.0.1:9443/ သို့ ပြောင်းခြင်းသည် ဖောက်သည်က TLS နှင့် HTTP အတွက် အသုံးပြုနိုင်သော လက်ခံဆောင် အမည်ကို ပြောင်းသည်။ service.example.net အတွက် လက်မှတ်သည် loopback အတွက် တရားဝင် လက်မှတ် ဖြစ်လာမည် မဟုတ်ပါ။

ဖောက်သည်က သီးခြား ချိတ်ဆက်မှု လမ်းကြောင်း ပံ့ပိုးသည့်နေရာတွင် မူရင်း URL အထောက်အထားကို ထိန်းသိမ်းပါ။ Curl သည် ထို ကွာခြားချက်ကို ပြသနိုင်သည်-

curl --noproxy '*' \
  --connect-to service.example.net:443:127.0.0.1:9443 \
  https://service.example.net/

ဆော့ကက်သည် ဒေသခံ အဒက်တာသို့ သွားပြီး TLS စစ်ဆေးမှုနှင့် HTTP ခရီးဆုံးသည် service.example.net အဖြစ် ဆက်ရှိနေသည်။ အခြား အက်ပ်များသည် ၎င်းတို့၏ ကိုယ်ပိုင် ညီမျှသော ပံ့ပိုးထားသည့် ထိန်းချုပ်မှု လိုအပ်သည်။ ဖောက်သည်တိုင်း ၎င်းကို မပေးပါ။

loopback ချည်နှောင်မှုသည် ကွန်ရက် ထိတွေ့မှုကို ကန့်သတ်သော်လည်း အခြား အရည်အချင်းပြည့်သော ဒေသခံ လုပ်ငန်းစဉ်များသည် ၎င်းသို့ ရောက်ရှိနိုင်သေးသည်။ ဝန်ဆောင်မှု သက်တမ်းနှင့် အသုံးပြုသူများကို သင့်လျော်စွာ ထားပါ။ loopback URL ကြောင့် ဖြစ်ပေါ်သော အထောက်အထား အမှားကို ဖိနှိပ်မည့်အစား TLS စစ်ဆေးမှုကို ထိန်းသိမ်းပါ။

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