Proxy អាចគ្របដណ្ដប់ចរាចរណ៍ HTTP ខណៈ WebRTC ផ្លាស់ប្ដូរ candidate address តាម STUN/ICE លើ UDP។ អត្ថបទនេះពន្យល់ថា ពេលណា local និង private-network address អាចត្រូវបានបង្ហាញ និងរបៀបធ្វើឱ្យ network exit និងបរិស្ថាន browser ស្របគ្នា។
អ្នកបានកំណត់ proxy រួច ហើយទំព័រត្រួតពិនិត្យ IP បង្ហាញតំបន់ និងក្រុមហ៊ុនផ្គត់ផ្គង់អ៊ីនធឺណិតត្រឹមត្រូវតាមការរំពឹង។ អត្តសញ្ញាណបណ្ដាញហាក់ដូចជាត្រូវបានរៀបចំរួចរាល់។ ប៉ុន្តែពេលបើកទំព័រតេស្តការលេចធ្លាយ ផ្នែក WebRTC ប្រែជាពណ៌ក្រហម ហើយអាចបង្ហាញអាសយដ្ឋាននៃការតភ្ជាប់អ៊ីនធឺណិតពិតរបស់អ្នក។
មិនចាំបាច់ប្រញាប់ប្ដូរ proxy ទេ។ ក្នុងករណីភាគច្រើន បញ្ហាមិនមែនស្ថិតនៅគុណភាព proxy ប៉ុន្តែស្ថិតនៅចរាចរណ៍ដែលវាមិនអាចគ្រប់គ្រងបាន។
Proxy គ្រប់គ្រង HTTP ខណៈ WebRTC ប្រើផ្លូវផ្សេង
Proxy ដំណើរការនៅស្រទាប់បណ្ដាញ។ មិនថាវាជា browser extension ឬ system-level tunnel ទេ វាដំណើរការ HTTP/HTTPS request ហើយបញ្ជូនចរាចរណ៍នោះចេញតាម proxy exit។
WebRTC ខុសពីនេះ។ វាជាមុខងារទំនាក់ទំនង real-time ដែលមានស្រាប់ក្នុង browser។ ដើម្បីឱ្យការហៅសំឡេង/វីដេអូ និងការផ្ទេរ P2P រកផ្លូវសមស្រប browser អាចផ្ញើ STUN query ទៅ server ខាងក្រៅដោយសកម្ម — មានន័យប្រហែលថា «ពីខាងអ្នក ឃើញអាសយដ្ឋានរបស់ខ្ញុំជាអ្វី?» — ហើយបន្ទាប់មករៀបចំលទ្ធផលជា ICE candidate ផ្ញើឱ្យ webpage។ Query ទាំងនេះប្រើ UDP ដែលជាផ្លូវឯករាជ្យពី HTTP tunnel។
ដូច្នេះកើតមានភាពមិនស្របគ្នា៖ web request ចេញតាម proxy ប៉ុន្តែ browser ក៏អាចរាយការណ៍ local address នៅពេលតែមួយ។ ការសន្មតថា គ្រាន់តែកំណត់ proxy រួច គឺអត្តសញ្ញាណបណ្ដាញទាំងមូលស្អាតដោយស្វ័យប្រវត្តិ គឺជាចំណុចចាប់ផ្ដើមដែលជួបញឹកញាប់បំផុតនៃបញ្ហានេះ។
មិនមែនមានតែ public IP ប៉ុណ្ណោះដែលអាចត្រូវបានបង្ហាញ
ICE candidate ជាទូទៅមានអាសយដ្ឋានពីរប្រភេទ។ ប្រភេទទីមួយគឺ public address ដែលជាច្រកចេញរបស់ក្រុមហ៊ុនអ៊ីនធឺណិតពិតរបស់អ្នក។ ប្រភេទទីពីរគឺ local address ដូចជា private address ដែលចាប់ផ្ដើមដោយ 192.168 ហើយពេលខ្លះក៏អាចមានអាសយដ្ឋានរបស់ virtual network adapter ផងដែរ។
Private-network address មួយតែឯងមិនបញ្ជាក់អ្វីច្រើនទេ ព្រោះកុំព្យូទ័រជិតគ្រប់គ្រឿងសុទ្ធតែមាន។ ប៉ុន្តែវាអាចមានស្ថិរភាពគ្រប់គ្រាន់ ដល់ថ្នាក់ candidate address របស់គណនីជាច្រើនដែលត្រួតគ្នាម្តងហើយម្តងទៀត អាចផ្ដល់ signal បន្ថែមឱ្យ platform ដើម្បីភ្ជាប់គណនីទាំងនោះទៅឧបករណ៍តែមួយ។ Public address គឺផ្ទាល់ជាងនេះ ព្រោះវាចង្អុលទៅក្រុមហ៊ុនផ្គត់ផ្គង់ពិត និងតំបន់ភូមិសាស្ត្រប្រហាក់ប្រហែល។ កម្រិតលម្អិតអាស្រ័យលើការអនុវត្តរបស់ platform ប៉ុន្តែគោលការណ៍ច្បាស់ណាស់៖ អាសយដ្ឋានកាន់តែពិត ការភ្ជាប់កាន់តែងាយ។
ពេលណា website អាចអានអាសយដ្ឋាននេះពិតប្រាកដ?
មិនមែន website ទាំងអស់សុទ្ធតែព្យាយាមអានទេ។ ការផ្លាស់ប្ដូរអាសយដ្ឋានតម្រូវឱ្យ page បង្កើត RTCPeerConnection object ដោយសកម្ម ដែលទំព័រមាតិកាធម្មតាជាទូទៅមិនត្រូវការ។
ករណីដែលជួបច្រើនរួមមាន site ដែលត្រូវការ real-time communication ដូចជា video meeting, online customer support និងទំព័រ live streaming មួយចំនួន; site ដែលពឹងខ្លាំងលើ advertising ឬ anti-fraud; និង platform ដែលមានប្រព័ន្ធ risk control ពេញលេញជាង។ ការអាននេះកើតឡើងនៅផ្នែកដែលមើលមិនឃើញក្នុង interface ហើយបន្ទាប់ពីទិន្នន័យត្រូវបានប្រមូល អ្នកជាទូទៅមិនទទួលបានសេចក្ដីជូនដំណឹងថាវាត្រូវបានប្រើយ៉ាងដូចម្តេចទេ។
ក៏មានស្ថានភាពមួយដែលមិនពាក់ព័ន្ធនឹង website ផ្ទាល់ដែរ។ ក្នុងចន្លោះខ្លីពេល proxy ភ្ជាប់ឡើងវិញ ឬប្ដូរ node, STUN request របស់ browser អាចចេញតាម local network។ ចន្លោះពេលខ្លីណាស់ ប៉ុន្តែគ្រប់គ្រាន់សម្រាប់កត់ត្រាបានមួយដង។
ស្ថានភាពបរាជ័យទូទៅបីប្រភេទ
Proxy ប្រភេទ browser extension ជាទូទៅគ្រប់គ្រងតែ HTTP/HTTPS request ប៉ុណ្ណោះ។ UDP នៅក្រៅវិសាលភាពរបស់វា ហើយការជ្រើស “global” ក្នុង interface ក៏មិនប្ដូរចំណុចនេះដែរ។
System-level global proxy មើលទៅពេញលេញជាង ព្រោះវាគ្របដណ្ដប់ចរាចរណ៍ទាំងមូលរបស់ឧបករណ៍។ ប៉ុន្តែការប្រមូល candidate address អាច bind ដោយផ្ទាល់ទៅ local network interface និងរំលង system routing table បាន ដូច្នេះ tunnel នៅតែអាចមានចន្លោះនៅដំណាក់កាលនេះ។
បញ្ហាទីបីមិនមែនជាបញ្ហាបច្ចេកទេសតែប៉ុណ្ណោះទេ ប៉ុន្តែទាក់ទងនឹងការផ្លាស់ប្ដូរនៃ risk control ផងដែរ។ ប្រព័ន្ធ risk control កំពុងប្រើ WebRTC address កាន់តែច្រើនជាសញ្ញាមួយក្នុងចំណោមសញ្ញាជាច្រើនសម្រាប់ភ្ជាប់គណនី។ ទិន្នន័យដែលពីមុនមិនត្រូវបានវាស់ ឬត្រូវបានមើលរំលង ឥឡូវអាចត្រូវបានបញ្ចូលក្នុងការសម្រេចចិត្ត។
គោលដៅគឺឱ្យច្រកចេញស្របគ្នា មិនមែនគ្រាន់តែបិទ switch មួយទេ
មានវិធីទូទៅមួយចំនួន។ ប្រសិនបើ workflow មិនត្រូវការ real-time communication សោះ ការបិទ WebRTC គឺសាមញ្ញបំផុត ប៉ុន្តែ feature ដូចជា video call និង online customer support ក៏នឹងមិនអាចប្រើបានដែរ។
ប្រសិនបើត្រូវរក្សា feature ទាំងនេះ វិធីដែលគេប្រើញឹកញាប់គឺធ្វើឱ្យ address ដែល WebRTC layer ត្រឡប់មក ស្របនឹង proxy exit។ វិធីរឹងមាំជាងនេះគឺបញ្ជូន STUN request តាម proxy channel ផងដែរ ដើម្បីឱ្យ interface មិនបង្ហាញ local address។ ប្រសិនបើត្រូវការ P2P ឬ video call នោះ UDP traffic ទាំងមូលត្រូវឆ្លងកាត់ proxy មិនមែនតែ HTTP layer ប៉ុណ្ណោះទេ។
កំហុសដែលជួបញឹកញាប់គឺគិតថា បិទ WebRTC មួយគត់គ្រប់គ្រាន់ដើម្បីធ្វើឱ្យ environment ទាំងមូលស្អាត។ អ្វីដែលសំខាន់គឺ network exit, DNS resolution, IP ownership និង ASN, time zone និងភាសា ព្រមទាំង device characteristics ត្រូវស្របគ្នាទាំងមូល។ ភាពមិនស្របគ្នាណាមួយអាចបង្កើត signal មិនប្រក្រតី; WebRTC គ្រាន់តែជាធាតុមួយដែលងាយមើលរំលងបំផុត។
ការផ្ទៀងផ្ទាត់គឺសាមញ្ញ។ តេស្តម្តងក្រោយប្ដូរ node ហើយតេស្តម្ដងទៀតមុនប្រើ environment ជាធម្មតា៖ បើក leak test ហើយពិនិត្យថា WebRTC section បង្ហាញ proxy exit, local address ឬ public address ពិត។ IP lookup ធម្មតាមិនបង្ហាញព័ត៌មាននេះទេ។
Browser-engine-level environment isolation អាចកំណត់ WebRTC address policy ដាច់ដោយឡែកសម្រាប់ environment នីមួយៗ ហើយភ្ជាប់វាជាមួយ network exit របស់ environment នោះ។ PurpleMark ផ្ដល់សមត្ថភាពប្រភេទនេះ។ ប្រសិនបើ environment ជាច្រើនប្រើ exit តែមួយ ឬ address policy របស់ពួកវាមិនស្របគ្នា តម្លៃនៃ isolation នឹងថយចុះយ៉ាងច្រើន។
នេះគ្រាន់តែជាការពន្យល់បច្ចេកទេសប៉ុណ្ណោះ។ សូមប្រើឧបករណ៍ពាក់ព័ន្ធដោយគោរពតាមច្បាប់របស់ platform និងច្បាប់មូលដ្ឋាន។
