តើ SOCKS5 និង HTTP proxy ខុសគ្នាយ៉ាងណា? ត្រូវយល់ជាមុនសិន ទើបកំណត់ក្នុងកម្មវិធីរុករកតាមស្នាមម្រាមដៃ

ពេលជ្រើស proxy មនុស្សភាគច្រើនមើលតែតំបន់ ល្បឿន និងតម្លៃ ហើយកម្រឈប់មើលជួរប្រភេទណាស់ គឺ HTTP ឬ SOCKS5។ ប៉ុន្តែជួរនេះហើយដែលកំណត់រឿងបី៖ សំណើ DNS ចេញពីខាងណា ចរាចរណ៍ UDP អាចឆ្លងកាត់បានឬអត់ និងតើ proxy នឹងកែប្រែក្បាលសំណើ (request header) របស់អ្នកឬអត់។ រឿងទាំងនេះស្ទើរតែមិនដឹងខ្លួនពេលរុករកធម្មតា ប៉ុន្តែនៅពេលយក proxy ទៅកំណត់ក្នុងបរិយាកាសកម្មវិធីរុករកតាមស្នាមម្រាមដៃដូចជា MakoBrowser វានឹងប៉ះពាល់ដោយផ្ទាល់ដល់គុណភាពបរិយាកាស។ ខាងក្រោមនេះនឹងពន្យល់ជាមុនថាតើភាពខុសគ្នារបស់វានៅឯណា បន្ទាប់មកទើបផ្តល់ការវិនិច្ឆ័យជ្រើសរើស និងវិធីកំណត់ និងផ្ទៀងផ្ទាត់ឲ្យដំណើរការពេញលេញ។

ភាពខុសគ្នាជាមូលដ្ឋាន៖ មួយយល់ភាសាគេហទំព័រ មួយទៀតគ្រាន់តែដឹកជញ្ជូន

HTTP proxy ដំណើរការនៅ layer កម្មវិធី អាចអានសំណើ HTTP ដែលឆ្លងកាត់វាបាន ដូច្នេះវាមានសមត្ថភាពកែប្រែ។ ចំណែក SOCKS5 គ្រាន់តែជាឆ្នេរបញ្ជូនទូទៅ មិនខ្វល់ថាខាងក្នុងដាក់អ្វីទេ។

ពេលចូលទំព័រ http proxy អាចឃើញអាសយដ្ឋានសំណើ និងក្បាលសំណើ។ ពេលចូល https កម្មវិធីរុករកនឹងផ្ញើសំណើ CONNECT មួយដើម្បីបង្កើត tunnel ជាមុន ហើយបន្ទាប់ពី tunnel បង្កើតរួច ខ្លឹមសារនឹងមើលមិនឃើញពី proxy — ជំហាននេះមានពន្យល់ច្បាស់នៅក្នុងការពន្យល់អំពីវិធីសាស្ត្រ CONNECT របស់ MDN។ មានន័យថា HTTP proxy ដោះស្រាយ HTTPS ក៏ដោយប្រើ tunnel ដែរ គ្រាន់តែសមត្ថភាពរបស់វាវិលជុំវិញពិធីការ HTTP ជានិច្ច។

តួនាទីរបស់ SOCKS5 ខុសគ្នា។ RFC 1928 ពិពណ៌នាវាថាជា «ស្រទាប់ការពាររវាង layer កម្មវិធី និង layer ដឹកជញ្ជូន» ហើយកំណត់បញ្ជាបីប្រភេទ គឺ CONNECT BIND និង UDP ASSOCIATE។ បកប្រែជាភាសាងាយ៖ វាមិនវិភាគខ្លឹមសារចរាចរណ៍ទេ គ្រាន់តែបញ្ជូនទិន្នន័យទៅគោលដៅតាមដើម ហើយអ្វីដែលវាបញ្ជូនមិនមែនមានតែ TCP ទេ។

ភាពខុសគ្នានៅពេលអនុវត្តជាក់ស្តែង មានចំណុចសំខាន់ៗដូចខាងក្រោម៖

• អាចឆ្លងកាត់ចរាចរណ៍អ្វី៖ HTTP proxy ដោះស្រាយ HTTP និង HTTPS ចំណែក SOCKS5 អាចបញ្ជូនចរាចរណ៍ TCP ណាមួយ ហើយគាំទ្រ UDP ដោយខ្លួនឯង។
• តើវាកែសំណើរបស់អ្នកឬអត់៖ HTTP proxy មើលឃើញខ្លឹមសារសំណើនៅ layer HTTP ហើយ implementation ខ្លះបន្ថែមក្បាលដូចជា Via និង X-Forwarded-For ដែរ ចំណែក SOCKS5 មិនកែប្រែខ្លឹមសារ layer កម្មវិធីទេ។
• វិធីផ្ទៀងផ្ទាត់អត្តសញ្ញាណ៖ HTTP proxy ប្រើ Basic auth ជាទូទៅ ដែលព័ត៌មានសម្ងាត់គ្រាន់តែ encode ជា base64 ហើយសុវត្ថិភាពពឹងលើការការពាររបស់ HTTPS។ ចំណែក SOCKS5 មានការចរចាអត្តសញ្ញាណដោយឡែក ហើយ RFC 1929 កំណត់វិធីប្រើឈ្មោះអ្នកប្រើ និងពាក្យសម្ងាត់ដោយឡែក។
• ទម្លាប់ច្រក (port)៖ សេវា SOCKS ប្រពៃណីដំណើរការលើច្រក 1080 ប៉ុន្តែអ្នកផ្តល់សេវាឲ្យច្រកណា សូមបំពេញច្រកនោះ។

បន្ទាប់ពីកំណត់ចូលកម្មវិធីរុករកតាមស្នាមម្រាមដៃ អ្វីដែលពិតជាមានបញ្ហាគឺ DNS និង UDP

ពេលជ្រើសប្រភេទ proxy ខុស អ្វីដែលមានបញ្ហាមុនគេជាធម្មតាមិនមែន «ភ្ជាប់មិនបាន» ទេ ប៉ុន្តែជាសំណើ DNS ដែលលួចចេញតាមបណ្តាញមូលដ្ឋាន។

ការវិភាគ DNS នៅខាងណា ជាអ្នកកំណត់ថានឹងលេចធ្លាយឬអត់

ឈ្មោះដែនត្រូវបានវិភាគនៅខាងណា អាស្រ័យលើការកំណត់របស់ client មិនមែនលើឈ្មោះប្រភេទ proxy ទេ។ SOCKS5 គាំទ្រការផ្ញើឈ្មោះដែនទៅឲ្យខាង proxy ដោះស្រាយផ្ទាល់ — RFC 1928 បានកំណត់អាសយដ្ឋានប្រភេទឈ្មោះដែនដោយឡែក។ ប៉ុន្តែ client មិនចាំបាច់ធ្វើដូច្នេះតាមលំនាំដើមទេ៖ ឧទាហរណ៍ Firefox ត្រូវធីក «ប្រើ proxy DNS នៅពេលប្រើ SOCKS v5» ទើបការវិភាគឆ្លងកាត់ proxy។ បើមិនធីក client នឹងវិភាគឈ្មោះដែនជាមូលដ្ឋានទៅជា IP ជាមុន រួចទើបផ្ញើទៅ proxy ដូច្នេះសំណើ DNS នឹងធ្លាក់ទៅដៃអ្នកផ្តល់សេវាបណ្តាញមូលដ្ឋាន។ នេះជាប្រភពដែលឃើញញឹកញាប់បំផុតនៃការលេចធ្លាយ DNS តាម proxy។

HTTP proxy ជាធម្មតាផ្ញើឈ្មោះម៉ាស៊ីនទៅឲ្យ proxy វិភាគ ប៉ុន្តែក៏មិនគួរសន្មតដែរ៖ WebRTC ភ្ជាប់ផ្ទាល់ ការវិភាគជាមុនរបស់កម្មវិធីរុករក និងចរាចរណ៍ដែលមិនឆ្លងកាត់ proxy សុទ្ធតែអាចបញ្ជូនសំណើវិភាគត្រឡប់ទៅមូលដ្ឋានវិញ។

ការផ្ទៀងផ្ទាត់មិនស្មុគស្មាញទេ។ បន្ទាប់ពីបើកបរិយាកាសរួច សូមចូលទំព័រពិនិត្យការលេចធ្លាយ DNS ណាមួយ រួចមើលថាម៉ាស៊ីនមេវិភាគស្ថិតនៅតំបន់ណា។ បើបង្ហាញជាអ្នកផ្តល់សេវាបណ្តាញមូលដ្ឋាន មានន័យថាការវិភាគមិនបានដើរតាម proxy។

តើការគាំទ្រ UDP សំខាន់នៅពេលណា

កម្មវិធីរុករកនឹងព្យាយាមប្រើ QUIC ពេលចូលគេហទំព័រដែលគាំទ្រ HTTP/3 ហើយ QUIC ផ្អែកលើ UDP។ ពេល proxy គាំទ្រតែ TCP ចរាចរណ៍នឹងប្តូរទៅ TCP ដោយស្វ័យប្រវត្តិ ទំព័រនៅតែបើកបានធម្មតា ហើយក្នុងការប្រើប្រាស់ប្រចាំថ្ងៃស្ទើរតែមិនដឹងខុសគ្នា។ អ្វីដែលត្រូវការ SOCKS5 ពិតប្រាកដ គឺពេលក្នុងបរិយាកាសក៏មានឧបករណ៍ដែលពឹងលើ UDP ដែរ។

បើធ្វើតែប្រតិបត្តិការគេហទំព័រ UDP មិនមែនជាចំណុចសម្រេចទេ ប៉ុន្តែបើក្នុងបរិយាកាសមានឧបករណ៍បន្ថែម វាទើបជាចំណុចសម្រេច។

សេណារីយ៉ូណាគួរប្រើ SOCKS5 សេណារីយ៉ូណា HTTP គឺគ្រប់គ្រាន់

ការជ្រើសរើសមិនមើលថាប្រភេទណា «កម្រិតខ្ពស់ជាង» ទេ គឺមើលតែរចនាសម្ព័ន្ធចរាចរណ៍របស់អ្នក និងប្រភេទដែលអ្នកផ្តល់សេវាផ្តល់ឲ្យ។

ការវិនិច្ឆ័យខាងក្រោមនេះអាចផ្ទឹមផ្ទាល់បាន៖

1. អ្នកផ្តល់សេវាផ្តល់តែប្រភេទ HTTP ហើយសេណារីយ៉ូគ្រាន់តែជាចរាចរណ៍គេហទំព័រតាមកម្មវិធីរុករក៖ ប្រើ HTTP proxy តែម្តង គឺគ្រប់គ្រាន់ណាស់។
2. ក្នុងបរិយាកាសក្រៅពីកម្មវិធីរុករក ក៏មានឧបករណ៍ពឹងលើ UDP ឬចង់បន្ថយការប៉ះពាល់ DNS៖ គួរជ្រើស SOCKS5 ជាមុន។
3. ត្រូវការ proxy ធ្វើ cache ត្រងខ្លឹមសារ និងត្រួតពិនិត្យការចូលប្រើ៖ HTTP proxy សមស្របជាង ព្រោះតម្លៃរបស់វាស្ថិតនៅក្នុងការអានខ្លឹមសារសំណើបាន។
4. គ្រាន់តែបើកគណនីច្រើនដើម្បីធ្វើបណ្តាញសង្គម ឬប្រតិបត្តិការហាង៖ ប្រភេទទាំងពីរសុទ្ធតែបំពេញបាន ហើយគម្លាតពិតប្រាកដមិននៅលើពិធីការទេ។

មានការយល់ខុសពីរដែលផ្សព្វផ្សាយយ៉ាងទូលំទូលាយ ដែលគួរបំបែកមើល។ ទីមួយគឺ «SOCKS5 លឿនជាងជាក់ជានិច្ច» — ល្បឿនអាស្រ័យលើចំណុះ បន្ទុក និងចម្ងាយខ្សែភ្ជាប់របស់ម៉ាស៊ីនមេ proxy ដែលមិនមានទំនាក់ទំនងផ្ទាល់នឹងប្រភេទពិធីការទេ។ ទីពីរគឺ «SOCKS5 អនាមិកជាង» — វាគ្រាន់តែមិនកែប្រែខ្លឹមសារចរាចរណ៍ មិនមែនលាក់អត្តសញ្ញាណអ្នកទេ ហើយការថតកំណត់ត្រាឬអត់អាស្រ័យលើអ្នកផ្តល់សេវា proxy។

ក៏គួររំលឹកបន្ថែម៖ ប្រភេទ proxy គ្រាន់តែជាប៉ារ៉ាម៉ែត្រមួយក្នុងការជ្រើសរើសប៉ុណ្ណោះ។ តើ proxy ជាប្រភេទផ្តាច់មុខ តំបន់នឹងនរឬអត់ និងនឹងប្តូរ IP ញឹកញាប់ឬអត់ សុទ្ធតែមានឥទ្ធិពលលើការញែកបរិយាកាស ច្រើនជាងប្រភេទពិធីការទៅទៀត។ បើអ្នកសម្រេចចិត្តយូរអំពីប្រភេទ ប៉ុន្តែកំពុងប្រើ proxy រួមដែលប្តូរ IP មិនឈប់ នោះលំដាប់គឺខុសហើយ។

ការកំណត់ proxy ក្នុងកម្មវិធីរុករកតាមស្នាមម្រាមដៃ៖ ពីបំពេញប្រភេទដល់ផ្ទៀងផ្ទាត់ដំណើរការ

ការកំណត់ខ្លួនវាមានតែប៉ុន្មានជំហាន ប៉ុន្តែលំដាប់ខុសនឹងធ្វើឲ្យធ្វើឡើងវិញម្តងហើយម្តងទៀត — សាកល្បងពិនិត្យនៅក្រៅបរិយាកាសជាមុន បន្ទាប់មកទើបកំណត់ក្នុងបរិយាកាស ហើយចុងក្រោយផ្ទៀងផ្ទាត់ម្តងទៀតក្នុងកម្មវិធីរុករក។

1. ផ្ទៀងផ្ទាត់ជាមុនថា proxy ខ្លួនឯងអាចប្រើបាន។ បន្ទាប់ពីទទួលបាន host ច្រក ប្រភេទ និងព័ត៌មានផ្ទៀងផ្ទាត់អត្តសញ្ញាណរួច សូមសាកល្បងភ្ជាប់ម្តងនៅក្រៅបរិយាកាស ដើម្បីអាចបែងចែកបានរវាង «proxy ប្រើមិនបាន» និង «ការកំណត់បរិយាកាសមានបញ្ហា»។

2. បើកការកំណត់ proxy របស់បរិយាកាស រួចជ្រើសប្រភេទ។ ប្រភេទត្រូវតែដូចនឹងអ្វីដែលអ្នកផ្តល់សេវាផ្តល់ឲ្យ។ បើយក proxy SOCKS5 ទៅបំពេញជា HTTP នឹងភ្ជាប់មិនបានតែម្តង ហើយសារកំហុសក៏ច្រើនតែមិនច្បាស់ ដែលងាយវិនិច្ឆ័យខុសថាជាកំហុសបរិយាកាស។

   

3. បំពេញ host ច្រក និងព័ត៌មានផ្ទៀងផ្ទាត់អត្តសញ្ញាណ។ បើមានឈ្មោះអ្នកប្រើ និងពាក្យសម្ងាត់ សូមបំពេញ ហើយប្រយ័ត្នកុំចម្លងចន្លោះលើសចូលជាមួយ នេះជាកំហុសកម្រិតទាបដែលឃើញញឹកញាប់បំផុត។

   

4. បន្ទាប់ពីរក្សាទុក សូមដំណើរការការពិនិត្យ proxy ក្នុងបរិយាកាសម្តង ដើម្បីបញ្ជាក់ថា IP ចេញ និងប្រទេស/តំបន់ ត្រូវនឹងការរំពឹងទុក។

5. បន្ទាប់ពីបើកបរិយាកាស សូមផ្ទៀងផ្ទាត់ម្តងទៀតក្នុងកម្មវិធីរុករក។ ផ្តោតលើ IP ចេញ ទីតាំងវិភាគ DNS និង WebRTC បីចំណុច។

6. កំណត់ឲ្យថេរ។ គណនីមួយគួរភ្ជាប់នឹងច្រកចេញថេរមួយ មិនគួរប្តូរ node ញឹកញាប់ដោយសារ «ចង់ឲ្យមើលទៅកាន់តែសុវត្ថិភាព» ទេ — ការប្តូរញឹកញាប់ខ្លួនវាគឺជាសញ្ញាមិនប្រក្រតីមួយ។

ជំហានទី 4 និងជំហានទី 5 ពិនិត្យរឿងពីរផ្សេងគ្នា៖ ការពិនិត្យក្នុងបរិយាកាសបញ្ជាក់ថាខ្សែ proxy ភ្ជាប់បានឬអត់ ចំណែកការផ្ទៀងផ្ទាត់ក្នុងកម្មវិធីរុករកបញ្ជាក់ថាចរាចរណ៍លេចធ្លាយចេញពីកន្លែងផ្សេងឬអត់។ បើធ្វើតែផ្នែកទីមួយ ងាយខកខាន DNS និង WebRTC។

ការផ្ទៀងផ្ទាត់បីចំណុចដែលចាំបាច់ត្រូវធ្វើបន្ទាប់ពីកំណត់រួច

ការកំណត់ proxy រួចមិនស្មើនឹងដំណើរការទេ គឺត្រូវបញ្ជាក់ IP ចេញ ទីតាំងវិភាគ DNS និង WebRTC ដោយឡែកទាំងបីចំណុច។

• IP ចេញ និងតំបន់៖ ចូលទំព័រពិនិត្យ IP ណាមួយ រួចបញ្ជាក់ថាបង្ហាញ IP របស់ proxy មិនមែន IP ម៉ាស៊ីនផ្ទាល់ ហើយតំបន់ត្រូវនឹងការពិពណ៌នារបស់អ្នកផ្តល់សេវា។
• ទីតាំងវិភាគ DNS៖ ប្រើទំព័រពិនិត្យការលេចធ្លាយ DNS ដើម្បីមើលទីតាំងរបស់ម៉ាស៊ីនមេវិភាគ។ ចំណុចនេះក្នុងសេណារីយ៉ូ SOCKS5 ក៏សំខាន់ដូចគ្នា ព្រោះទីតាំងវិភាគអាស្រ័យលើការកំណត់របស់ client មិនអាចសន្មតបានទេ។
• WebRTC៖ ពិនិត្យថាកម្មវិធីរុករកបង្ហាញ IP ពិតតាម WebRTC ឬអត់។ បញ្ហានេះឃើញញឹកញាប់នៅក្នុងកម្មវិធីរុករកធម្មតាដែលកែតែ proxy ប៉ុន្តែមិនបានញែកបរិយាកាស។

ក៏មានចំណុចមួយទៀតដែលងាយមើលរំលង៖ តំបន់ពេលវេលា ភាសា និងតំបន់ប្រព័ន្ធ ត្រូវតម្រូវឲ្យត្រូវនឹងតំបន់ច្រកចេញ។ កំណត់ proxy តំបន់អាមេរិក ប៉ុន្តែតំបន់ពេលវេលានៅតែ UTC+8 ភាពមិនស៊ីគ្នាបែបនេះងាយត្រូវគេកត់សម្គាល់ជាងការជ្រើសប្រភេទពិធីការខុសទៅទៀត។

បើនៅក្នុងដៃមានបរិយាកាសដប់ឬរាប់សិបដែលត្រូវកំណត់ ការកំណត់ប្រភេទ ច្រកចេញ និងតំបន់ឲ្យទៅជាការកំណត់អាចប្រើឡើងវិញ ងាយស្រួលជាងការបំពេញដោយដៃរាល់ដង។ នេះក៏ជាហេតុផលដែល MakoBrowser គ្រប់គ្រង proxy ជាមួយបរិយាកាសជាមួយគ្នា — បរិយាកាស គណនី និងច្រកចេញបណ្តាញត្រូវបានថែទាំនៅកន្លែងតែមួយ ពេលប្តូរមនុស្សទទួលបន្ត មិនចាំបាច់សួរថា «គណនីនេះកំណត់ node ណា» ទេ។ បើចង់ដំណើរការបរិយាកាសមួយជាមុនសិន អាចចាប់ផ្តើមពីការដំឡើង client នៅទំព័រទាញយក។

សំណួរដែលសួរញឹកញាប់

តើ SOCKS5 និង HTTP proxy មួយណាលឿនជាង

មិនមានចម្លើយថេរទេ។ ល្បឿនអាស្រ័យលើចំណុះ បន្ទុក ចម្ងាយខ្សែភ្ជាប់របស់ម៉ាស៊ីនមេ proxy និងគេហទំព័រគោលដៅ ហើយមានទំនាក់ទំនងតិចតួចជាមួយប្រភេទពិធីការ។ ជំនួសឲ្យការសម្រេចចិត្តយូរអំពីប្រភេទ គួរមើលគុណភាពខ្សែរបស់ proxy ខ្លួនឯងជាមុន។

តើកម្មវិធីរុករកតាមស្នាមម្រាមដៃចាំបាច់ត្រូវប្រើ SOCKS5 ដែរឬទេ

មិនចាំបាច់ទេ។ បើដំណើរការតែចរាចរណ៍គេហទំព័រ ហើយអ្នកផ្តល់សេវាផ្តល់តែប្រភេទ HTTP នោះ HTTP proxy ក៏ប្រើបានដូចគ្នា។ អត្ថប្រយោជន៍របស់ SOCKS5 ផ្តោតលើការគាំទ្រ UDP និងការវិភាគ DNS ពីចម្ងាយដែលអាចគ្រប់គ្រងបាន ដូច្នេះពេលក្នុងបរិយាកាសមានឧបករណ៍ពឹងលើ UDP ទើបគួរគិតដល់វាជាមុន។

បំពេញ proxy រួចហើយ ហេតុអ្វីនៅតែបង្ហាញ IP ពិត

មូលហេតុដែលឃើញញឹកញាប់មានបី៖ ជ្រើសប្រភេទខុសធ្វើឲ្យ proxy ពិតជាមិនដំណើរការ កម្មវិធីរុករកភ្ជាប់ផ្ទាល់តាម WebRTC និង DNS នៅតែវិភាគនៅមូលដ្ឋាន។ សូមពិនិត្យតាមលំដាប់ក្នុងផ្នែកមុន គឺអាចកំណត់បានថាជាចំណុចណា។

តើ HTTP proxy អាចចូលគេហទំព័រ HTTPS បានឬទេ

បាន។ កម្មវិធីរុករកនឹងបង្កើត tunnel មួយលើ proxy តាមវិធីសាស្ត្រ CONNECT ជាមុន ហើយចរាចរណ៍ក្នុង tunnel ត្រូវបានអ៊ិនគ្រីប ដូច្នេះ proxy មើលមិនឃើញខ្លឹមសារទំព័រជាក់លាក់ទេ។ នេះជាវិធីស្តង់ដារដែល HTTP proxy ដោះស្រាយ HTTPS។

តើប្រភេទ proxy ប៉ះពាល់សុវត្ថិភាពគណនីឬទេ

ប្រភេទ proxy ខ្លួនវាមិនកំណត់លទ្ធផលគណនីទេ អ្វីដែលមានឥទ្ធិពលពិតគឺច្រកចេញថេរឬអត់ តំបន់ត្រូវនឹងគណនីឬអត់ និងមានការប្តូរញឹកញាប់ឬអត់។ គ្មានឧបករណ៍ណាធានាបានថាគណនីនឹងមិនត្រូវផ្ទៀងផ្ទាត់ទេ ការធ្វើឲ្យបរិយាកាសស្អាត និងជៀសវាងការរំជើបរំជួលមិនប្រក្រតី ទើបជាផ្នែកដែលអ្នកអាចគ្រប់គ្រងបាន។