SSH ဖြင့် ပို့ဆောင်ထားသော ပေါက်သည် အမြဲတမ်း SOCKS proxy မဟုတ်ပါ
အပလီကေးရှင်းတစ်ခုကို ပြင်ဆင်ခြင်းမပြုမီ SSH ၏ ပုံသေဒေသခံ ပို့ဆောင်မှုနှင့် ရွေ့လျားနေသော SOCKS နားထောင်သူကို ခွဲခြားပါ။
သင်သည် SSH ဥမင်တစ်ခု ဖန်တီးပြီး 127.0.0.1 နှင့် ၎င်း၏ပေါက်ကို browser ၏ proxy ဆက်တင်များထဲသို့ ထည့်လိုက်သော်လည်း ဘာမှ မတင်ပေါ်ပါ။ နားထောင်သူက ကောင်းမွန်စွာ အလုပ်လုပ်နေနိုင်သည်။ ၎င်းသည် မှားယွင်းသော အသွားအလာအမျိုးအစားကို စောင့်နေခြင်းသာ ဖြစ်နိုင်သည်။
| ပို့ဆောင်မှု | ဒေသခံအပလီကေးရှင်း ဘာပို့သနည်း | ဆုံးမှတ် ရွေးချယ်မှု |
|---|---|---|
-L | ပစ်မှတ်ဝန်ဆောင်မှု၏ သာမာန် ပရိုတိုကော | SSH အမိန့်တွင် ပုံသေသတ်မှတ်ထား |
-D | SOCKS ညှိနှိုင်းမှု၊ ထို့နောက် အပလီကေးရှင်း အသွားအလာ | SOCKS client မှ တောင်းဆို |
ဝဘ်ဆာဗာတစ်ခုတည်းအတွက် ဤသည် ပုံသေ ပို့ဆောင်မှုဖြစ်သည်−
ssh -N -L 127.0.0.1:9080:web.example.com:80 [email protected]http://127.0.0.1:9080/ ကို ဝဘ်ဆိုက်အဖြစ် သွားကြည့်ပါ။ ပေါက် 9080 ကို SOCKS ဟု တံဆိပ်မကပ်ပါနှင့်− ၎င်းသည် အမိန့်တွင် အမည်ဖော်ပြထားသော ဝဘ်ဆာဗာတစ်ခုတည်းသို့ byte များ ပို့ဆောင်သည်။ အခြား host အမည်အောက်တွင် ဆိုက်ဖွင့်ခြင်းသည် ၎င်း၏ virtual hosting၊ ပြန်ညွှန်းမှုများ သို့မဟုတ် cookie များကိုလည်း ထိခိုက်နိုင်သည်။
SOCKS နားထောင်သူ အတွက် ပုံသဏ္ဌာန် ပြောင်းလဲသည်−
ssh -N -D 127.0.0.1:1080 [email protected]အပလီကေးရှင်းကို 127.0.0.1:1080 တွင် SOCKS အသုံးပြုရန် ပြင်ဆင်ပါ။ ထိုလိပ်စာကို browser ၏ လိပ်စာဘားတွင် တိုက်ရိုက်ထည့်ခြင်းသည် ဝဘ်တောင်းဆိုမှုကို SOCKS နားထောင်သူထံ ပို့သည်၊ ၎င်းသည် နောက်ထပ် ပရိုတိုကော မကိုက်ညီမှုဖြစ်သည်။
OpenSSH လက်စွဲ သည် ပုံစံနှစ်မျိုးလုံးကို မှတ်တမ်းတင်ထားသည်။ အသုံးဝင်သော ခြွင်းချက်တစ်ခု ရှိသည်− ရှိပြီးသား HTTP proxy တစ်ခုကို -L ဖြင့် ပို့ဆောင်ခြင်းသည် HTTP proxy ပရိုတိုကောဖြင့် ပြောဆိုသော ဒေသခံပေါက်တစ်ခုကို ဖန်တီးသည်၊ အကြောင်းမှာ ၎င်း၏ ပုံသေဆုံးမှတ်သည် သူ့ကိုယ်တိုင် HTTP proxy ဖြစ်သောကြောင့် ဖြစ်သည်။ ပုံသေပို့ဆောင်မှုတွင် ဘာပါဝင်သည်ကို အဝေးဘက်စွန်းရှိ ဝန်ဆောင်မှုက ဆုံးဖြတ်သည်။ ရှိပြီးသား proxy တစ်ခုကို SSH မှတစ်ဆင့် ပို့ဆောင်ခြင်း သည် ထို proxy ၏ ပရိုတိုကောနှင့် အကောင့်ကို ထိန်းသိမ်းထားသည်။