ဘရောက်ဇာပရောက်စီက WebRTC ကိုလည်း လွှမ်းခြုံသလား။
ပုံမှန်ဝက်ဘ် IP စစ်ဆေးမှုနှင့် WebRTC ချိတ်ဆက်မှုတို့သည် လမ်းကြောင်းမတူနိုင်ပါ။ ဘရောက်ဇာ၏ အချိန်နှင့်တစ်ပြေးညီ ဆက်သွယ်မှုကို သီးခြားစစ်ပါ။
ဘရောက်ဇာ၏ HTTP ပရောက်စီဆက်တင်က WebRTC ကို အလိုအလျောက် မလွှမ်းခြုံပါ။ ပုံမှန် IP စစ်ဆေးသည့်စာမျက်နှာက ဝက်ဘ်တောင်းဆိုချက်ကို တိုင်းတာသည်။ ဖုန်းခေါ်မှုက ချိတ်ဆက်ရန်နှင့် လိပ်စာရှာရန် သီးခြားလမ်းကြောင်းများ သုံးနိုင်သည်။
SOCKS5 ကလည်း ထိုကွာခြားချက်ကို မဖယ်ရှားပါ။ Chromium တွင်ပါသော SOCKS5 URL ပရောက်စီအကောင်အထည်ဖော်မှုက TCP ကိုသာ ပံ့ပိုးပြီး ယေဘုယျ UDP association မဟုတ်ပါ။ ပရိုတိုကော၏ စွမ်းဆောင်ရည်က ဤဘရောက်ဇာအင်တာဖေ့စ်ထက် ကျယ်ပြန့်သည်။
ဘရောက်ဇာများတွင် WebRTC အတွက် သီးခြားကွန်ရက်ထိန်းချုပ်မှုများရှိသည်။ Chrome က ကိုယ်ရေးလုံခြုံမှုဆိုင်ရာ တိုးချဲ့ကိရိယာ API မှတစ်ဆင့် disable_non_proxied_udp အပါအဝင် IP ကိုင်တွယ်ရေးမူဝါဒ ပေးသည်။ Mozilla ကလည်း WebRTC ကွန်ရက်ကိုယ်ရေးလုံခြုံမှုဆက်တင်များကို မှတ်တမ်းတင်ထားသည်။ ဤ Chrome တန်ဖိုးသည် API မူဝါဒဖြစ်ပြီး နေရာတိုင်းသုံးအမှန်ခြစ်ကွက် သို့မဟုတ် လိပ်စာတိုင်းဖုံးကွယ်ပေးမည့် အာမခံမဟုတ်ပါ။
ပထမဦးစွာ ပုံမှန်ဝက်ဘ်အထွက်ကို စစ်ပြီးနောက် တကယ်သုံးသည့်အစည်းအဝေးအက်ပ်တွင် WebRTC လုပ်ဆောင်ပုံကို ရလဒ်အကွက်များ၏အဓိပ္ပာယ်ကို နားလည်သောစစ်ဆေးကိရိယာဖြင့် ကြည့်ပါ။ ဒေသတွင်းလိပ်စာ၊ လက်ဆင့်ကမ်းလိပ်စာနှင့် အပြင်မှမြင်ရသည့် အများသုံးလိပ်စာတို့က ချိတ်ဆက်မှု၏ မတူသောအစိတ်အပိုင်းများကို ဖော်ပြသည်။ ဘရောက်ဇာနှင့် စမ်းသပ်မှုအခြေအနေကို မှတ်ပါ။ မူဝါဒ၊ တိုးချဲ့ကိရိယာ၊ ကိုယ်ရေးလုံခြုံမှုလုပ်ဆောင်ပုံနှင့် ရနိုင်သောလမ်းကြောင်းများက ရလဒ်ကို သက်ရောက်စေသည်။ ထို့ကြောင့် “အမြဲပေါက်ကြားသည်” ဆိုခြင်းဖြစ်စေ၊ အောင်မြင်သောဝက်ဘ် IP စစ်ဆေးမှုဖြစ်စေ လုံလောက်သည့်ကောက်ချက်မဟုတ်ပါ။
WebRTC လမ်းကြောင်းကို ကန့်သတ်လျှင် လိုအပ်သောခေါ်ဆိုမှုများကို ပြန်စမ်းပါ။ လိပ်စာပေါ်ထွက်မှု လျှော့ချခြင်းက ခေါ်ဆိုမှုမချိတ်နိုင်အောင်လည်း ဖြစ်စေနိုင်သည်။ ထိုအလဲအလှယ်သည် HTTP ပရောက်စီချိတ်ဆက်မှတ် အွန်လိုင်းရှိမရှိနှင့် သီးခြားဖြစ်သည်။