Squid မှတစ်ဆင့် WSS သည် သာမန် WebSocket အဆင့်မြှင့်ခြင်းနှင့် မတူပါ
CONNECT အတွင်းရှိ စာဝှက်ထားသော WebSocket များကို forward proxy ရှိ သာမန် HTTP Upgrade ကိုင်တွယ်မှုနှင့် ခွဲခြားပါ။
Squid သည် HTTP Upgrade တောင်းခံမှုကို မြင်ပါသလား၊ သို့မဟုတ် စာဝှက်ထားသော အသွားအလာကို သယ်ဆောင်သော လိုဏ်ခေါင်းကိုသာ မြင်ပါသလား။ ၎င်းက ၎င်း၏ HTTP Upgrade ထိန်းချုပ်မှုများက ချို့ယွင်းချက်ကို ဖြေရှင်းခြင်းရှိမရှိ ဆုံးဖြတ်သည်။
| သာမန် ရှင်းလင်းသော proxy လမ်းကြောင်း | Squid ကြုံတွေ့ရသောအရာ |
|---|---|
wss:// | များသောအားဖြင့် CONNECT၊ ထို့နောက် WebSocket လက်ဆုပ်ခြင်းကို သယ်ဆောင်သော ဦးတည်ရာ TLS |
ws:// | proxy က လုပ်ဆောင်နိုင်သော သာမန် HTTP Upgrade တောင်းခံမှု |
Squid ၏ အဆင့်မြှင့်ထိန်းချုပ်မှုသည် ၎င်းလုပ်ဆောင်သော တောင်းခံမှုများနှင့် သက်ဆိုင်သည်။ သာမန် မထင်ရှားသော WSS လိုဏ်ခေါင်းအတွင်းရှိ စာဝှက်ထားသော HTTP ခေါင်းစီးများကို မဖော်ထုတ်ပါ။ TLS ကြားဖြတ်ခြင်း သို့မဟုတ် အခြားအထူး proxy ကိုင်တွယ်မှုသည် မြင်နိုင်စွမ်းကို ပြောင်းလဲပြီး ၎င်း၏ကိုယ်ပိုင် လိုက်လျောညီထွေမှု လိုအပ်ချက်များကို ယူဆောင်နိုင်သည်။
WSS အတွက် အစီအစဉ် ဘယ်နေရာတွင် ရပ်တန့်သည်ကို ရှာပါ- proxy နှင့် ချိတ်ဆက်မှု၊ လက်ခံထားသော CONNECT၊ စစ်ဆေးပြီးသော TLS၊ ထို့နောက် အပလီကေးရှင်း လက်ဆုပ်ခြင်း။ TLS မတိုင်မီ ငြင်းပယ်ခြင်းသည် ငြင်းပယ်ခံရသော သာမန် Upgrade တောင်းခံမှုနှင့် မတူသော ချို့ယွင်းချက်ဖြစ်သည်။
အဆင့်မြှင့်မူဝါဒ ပြောင်းလဲရန် လိုအပ်ပါက တပ်ဆင်ထားသော Squid ဗားရှင်းအတွက် ညွှန်ကြားချက်ကို အသုံးပြုပြီး လိုအပ်သော အပြုအမူကို အတိအကျ ခွင့်ပြုပါ။ အဆင့်မြှင့် ပရိုတိုကောအားလုံးကို ခွင့်ပြုခြင်းသည် မူဝါဒကို သက်ဆိုင်ရာ အပလီကေးရှင်းထက် ကျော်လွန် ချဲ့ထွင်သည်။
အောင်မြင်သော HTTPS စာမျက်နှာ တောင်းခံမှုသည် လမ်းကြောင်း၏ အစိတ်အပိုင်းတစ်ခုကိုသာ တည်ဆောက်သည်။ ရေရှည်တည်တံ့သော WebSocket အသွားအလာသည် တူညီသော host အမည်အတွက်ပင် အပလီကေးရှင်း လိုအပ်ချက်များ၊ ချိတ်ဆက်မှု သက်တမ်း သို့မဟုတ် ကြားခံ ကန့်သတ်ချက်များကြောင့် ကျရှုံးနိုင်သေးသည်။