Proxy អាចភ្ជាប់បាន មិនមានន័យថាវាសមស្របសម្រាប់ប្រើប្រាស់ទេ។ មគ្គុទ្ទេសក៍នេះបង្ហាញការត្រួតពិនិត្យ 5 ចំណុច៖ ទីតាំង និងប្រតិបត្តិករ, IP លំនៅឋាន ឬ data center, ការតភ្ជាប់ និង packet loss, ការលេចធ្លាយ DNS/WebRTC និងសញ្ញានៃការត្រូវបានសម្គាល់តាមពេលវេលា។
បន្ទាប់ពីកំណត់ Proxy ហើយ ការដែលទំព័របង្ហាញថាបានភ្ជាប់ គឺគ្រាន់តែជាជំហានដំបូង។ អ្វីដែលកំណត់ថាបរិស្ថាននេះអាចប្រើបានពិតប្រាកដឬអត់ គឺព័ត៌មានលម្អិតដែលងាយមើលរំលង៖ អាសយដ្ឋានចេញជារបស់អ្នកណា, ជួរអាសយដ្ឋានជាប្រភេទលំនៅឋាន ឬ data center, សំណើ DNS ចេញពីទីណា និង WebRTC មានបង្ហាញអាសយដ្ឋានពិតឬអត់។
ចំណុចត្រួតពិនិត្យ 5 ខាងក្រោម ជាមួយវិធីធ្វើជាក់លាក់ អាចពិនិត្យតាមលំដាប់ក្នុងប្រហែល 10 នាទី។
1. ទីតាំង និងប្រតិបត្តិករត្រឹមត្រូវឬទេ
បើកទំព័រណាមួយដែលបង្ហាញ IP បច្ចុប្បន្ន ហើយពិនិត្យ 3 ចំណុច៖ ប្រទេស និងទីក្រុងត្រូវនឹងតំបន់ដែលអ្នកត្រូវការឬទេ, ឈ្មោះប្រតិបត្តិករត្រូវនឹងសេវាដែលបានទិញឬទេ និង ASN ត្រូវនឹងអ្វីដែលបានប្រកាសឬទេ។
ជំហាននេះអាចរកឃើញបញ្ហាដែលកើតជាញឹកញាប់៖ អ្នកផ្តល់សេវានិយាយថា node នៅអាល្លឺម៉ង់ ប៉ុន្តែច្រកចេញពិតនៅសហរដ្ឋអាមេរិក។ មូលដ្ឋានទិន្នន័យ IP ក៏អាចមានព័ត៌មានខុសគ្នា ដូច្នេះគេហទំព័រត្រួតពិនិត្យផ្សេងៗអាចបង្ហាញលទ្ធផលមិនដូចគ្នា។ គួរផ្ទៀងផ្ទាត់ពីប្រភព 2 ឬ 3 ហើយយកអង្គភាពដែលចុះបញ្ជីក្នុង whois ជាគោល។
ពិនិត្យ IPv6 ផងដែរ។ ក្នុងបរិស្ថានខ្លះ ទិន្នន័យ browser ឆ្លងកាត់ Proxy ប៉ុន្តែ IPv6 នៅតែចេញពីបណ្តាញមូលដ្ឋាន។ ប្រើទំព័រតេស្ត IPv6 ប៉ុណ្ណោះ ដើម្បីបញ្ជាក់ថាលទ្ធផលក៏ចង្អុលទៅច្រកចេញ Proxy។ ប្រសិនបើវានៅបង្ហាញអាសយដ្ឋានពិតរបស់អ្នក នោះបរិស្ថានត្រូវបានការពារតែផ្នែកខ្លះប៉ុណ្ណោះ។
2. ជួរ IP លំនៅឋាន ឬ data center
ប្រភេទ IP ងាយត្រូវមើលរំលងជាងទីតាំង ប៉ុន្តែឥទ្ធិពលអាចផ្ទាល់ជាង។ IP លំនៅឋានត្រូវបានចុះបញ្ជីជាមួយប្រតិបត្តិករអ៊ីនធឺណិត broadband ខណៈ IP data center ស្ថិតក្នុងជួរអាសយដ្ឋានរបស់អ្នកផ្តល់ cloud ឬ IDC។ ភាពខុសគ្នានេះអាចស្វែងរកជាសាធារណៈក្នុងមូលដ្ឋានទិន្នន័យប្រភេទ IP។
វិធីសាមញ្ញគឺពិនិត្យអង្គភាពដែលចុះបញ្ជីសម្រាប់ ASN។ ឈ្មោះដែលមាន Cloud, Hosting, Data Center ឬ VPS ជាទូទៅជាជួរ data center; ឈ្មោះដែលមាន Telecom, Broadband, Cable ឬ Communications ជាញឹកញាប់ជាជួរលំនៅឋាន ឬ ISP។ ពិនិត្យ reverse DNS ផងដែរ៖ IP លំនៅឋានភាគច្រើនមាន reverse record ដែលប្រតិបត្តិករផ្តល់ឱ្យ ខណៈ PTR របស់ IP data center ជាញឹកញាប់ប្រើទម្រង់ domain របស់អ្នកផ្តល់ cloud។
បើអ្នកប្រើ cloud server ផ្ទាល់ខ្លួនជាប្រភេទ Proxy ច្រកចេញនឹងជាអាសយដ្ឋាន data center ជានិច្ច។ វាជាលទ្ធផលពីរចនាសម្ព័ន្ធ ហើយមិនអាចប្តូរដោយ configuration បានទេ។ អត្ថប្រយោជន៍គឺស្ថេរភាព គ្រប់គ្រងបាន និង IP ប្រើដោយអ្នកតែម្នាក់; គុណវិបត្តិគឺប្រភេទ IP។ អ្វីសំខាន់ជាងគេអាស្រ័យលើកម្រិតតឹងរឹងនៃការគ្រប់គ្រងហានិភ័យរបស់ platform គោលដៅ៖ បរិស្ថានមិនសូវតឹងអាចប្រើ data center បាន ប៉ុន្តែបរិស្ថានតឹងជាងអាចត្រូវការ Proxy លំនៅឋាន ឬ ISP។
3. ការតភ្ជាប់ និង packet loss
ភ្ជាប់បានមិនស្មើនឹងមានស្ថេរភាពទេ។ ការ ping ខ្លីៗអាចមិនឃើញបញ្ហា ដូច្នេះត្រូវតាមដានជាបន្តរយៈពេលមួយ។
ធ្វើ ping ជាបន្ត ឬផ្ញើសំណើដដែលទៅគោលដៅថេររាប់រយដង ហើយមើលអត្រា packet loss និងការប្រែប្រួល latency។ លទ្ធផលល្អគឺ packet loss សូន្យ និង latency នៅកម្រិតប្រហាក់ប្រហែលគ្នា។ packet loss ជាបន្តបន្ទាប់ ឬ latency លោតខ្លាំង ជាទូទៅបង្ហាញពីការកកស្ទះបណ្តាញ ឬ bandwidth មិនគ្រប់។ ដើម្បីរកផ្នែកដែលមានបញ្ហា សាកល្បងជាផ្នែក៖ ដំបូងវាស់ latency ពីឧបករណ៍មូលដ្ឋានទៅ Proxy server ហើយបន្ទាប់មកពី server ទៅគេហទំព័រគោលដៅ។ ផ្នែកណាអាក្រក់ច្បាស់ គឺជាចំណុច bottle neck។
ប្រភេទ Proxy ក៏ត្រូវតែត្រូវគ្នា។ SSH, SOCKS5 និង HTTP មិនអាចលាយ configuration តាមចិត្តបានទេ; protocol ដែលជ្រើសក្នុង client ត្រូវតែដូចគ្នានឹងអ្វីដែល server បើកពិត បើមិនដូច្នោះអាចមើលទៅដូចបានភ្ជាប់ ប៉ុន្តែ traffic មិនឆ្លងកាត់ត្រឹមត្រូវ។ Port ក៏ដូចគ្នា។ បើ port លំនាំដើមដូច SSH 22 ត្រូវបានអ្នកផ្តល់សេវាបិទ សូមកែ firewall rule មុនពេលសង្ស័យ password។
4. DNS និង WebRTC មានការលេចធ្លាយឬទេ
ការត្រួតពិនិត្យទាំងពីរនេះកំណត់ថាទីតាំងពិតរបស់អ្នកអាចលេចតាមផ្លូវផ្សេងឬអត់។
ដើម្បីពិនិត្យ DNS leak សូមចូលទំព័រដែលមាន DNS leak test ហើយមើលថាសំណើ resolve ចេញពី node ណា។ បើ resolver ចុងក្រោយនៅតែក្នុងបណ្តាញមូលដ្ឋាន ការដែល traffic ឆ្លង Proxy មិនគ្រប់គ្រាន់ទេ ព្រោះ platform អាចប៉ាន់ស្មានតំបន់ពិតពីទីតាំង DNS resolution ហើយប្រៀបធៀបជាមួយទីតាំង IP។ ដំណោះស្រាយគឺបើក remote DNS resolution ក្នុងបរិស្ថាន ឬជ្រើសប្រភេទ Proxy ដែលអាច resolve DNS តាម Proxy។
WebRTC leak ពិបាកមើលឃើញជាង។ Browser ប្រមូលព័ត៌មាន network interface ក្នុងម៉ាស៊ីនសម្រាប់ peer-to-peer communication ហើយក្នុង configuration ខ្លះ វាអាចឆ្លងកាត់ Proxy ដោយមិនប្រើវា និងបង្ហាញ private address ឬ public address។ បើក WebRTC test ហើយពិនិត្យថាមាន IP ពិតរបស់អ្នកក្នុង candidate addresses ឬទេ។ បើមាន សូមបិទ WebRTC ក្នុង browser ឬ environment settings ឬកំណត់ឱ្យវាប្រើតែ Proxy។
5. តំបន់ពេលវេលា និងភាសាស្របគ្នាឬទេ
បើច្រកចេញបង្ហាញថានៅសហរដ្ឋអាមេរិក ប៉ុន្តែ browser ប្រើម៉ោង Beijing ភាសាចិន និងការបង្ហាញ font តាមភាសាចិន នោះមានភាពមិនស្របគ្នាច្បាស់។ កំណត់ time zone ភាសា និងតំបន់ interface ឱ្យសមនឹងទីតាំង IP។ មិនចាំបាច់ធ្វើត្រាប់តាមទីក្រុងណាមួយឱ្យដូចពិតទាំងស្រុងទេ។
តើតាមដានរយៈពេលវែងដូចម្តេចដើម្បីដឹងថា IP ត្រូវបានសម្គាល់
ការត្រួតពិនិត្យខាងលើអាចធ្វើចប់ក្នុងថ្ងៃដដែល ប៉ុន្តែកេរ្តិ៍ឈ្មោះ IP ត្រូវមើលតាមពេលវេលា។ សង្កេតសញ្ញាដូចជា CAPTCHA លេចញឹកញាប់ជាងមុននៅលើគេហទំព័រគោលដៅ, ការចូលគណនីចាប់ផ្តើមស្នើឱ្យផ្ទៀងផ្ទាត់ជំហានទីពីរញឹកញាប់, មុខងារដែលធ្លាប់ប្រើធម្មតាត្រូវបានកម្រិត ឬគេហទំព័រដដែលត្រឡប់មកធម្មតាភ្លាមៗបន្ទាប់ពីប្តូរបណ្តាញ។
បើការផ្ទៀងផ្ទាត់កើតឡើងញឹកញាប់បន្ទាប់ពីសកម្មភាពតែពីរបី ជាធម្មតាមានមូលហេតុ 2៖ ប្រភេទ IP មិនសមស្រប ឬជួរអាសយដ្ឋាននេះធ្លាប់ត្រូវបានមនុស្សជាច្រើនប្រើ និងមានប្រវត្តិស្រាប់។ មូលដ្ឋានទិន្នន័យ anti-abuse អាចបង្ហាញថាជួរនេះធ្លាប់ត្រូវបានសម្គាល់ឬអត់។ អត្ថប្រយោជន៍នៃ server ផ្ទាល់ខ្លួនបង្ហាញនៅទីនេះ៖ ចាប់ពីថ្ងៃទិញ IP នេះប្រើដោយអ្នកតែម្នាក់ ហើយចាប់ផ្តើមពីប្រវត្តិដែលស្អាតជាង។
មានទិសដៅអនុវត្ត 2៖ ប្តូរទៅ Proxy លំនៅឋាន ឬប្តូរទៅ node តំបន់ដែលមានអ្នកប្រើតិចជាង។
លំដាប់ត្រួតពិនិត្យនៅថ្ងៃបញ្ចប់ configuration
- នៅទំព័រ IP lookup ផ្ទៀងផ្ទាត់ទីតាំង ប្រតិបត្តិករ និង ASN ហើយពិនិត្យ IPv6 leak
- ប្រើអង្គភាពចុះបញ្ជី ASN និង reverse DNS ដើម្បីកំណត់ថាជួរនេះជាលំនៅឋាន ឬ data center
- ផ្ញើសំណើជាបន្តរាប់រយដង ហើយមើល packet loss និង latency variation; បើចាំបាច់ តេស្តជាផ្នែកៗ
- ប្រើ DNS leak test និង WebRTC test ដើម្បីបញ្ជាក់ថាច្រកចេញពិតមិនត្រូវបានបង្ហាញ
- កំណត់ time zone ភាសា និងតំបន់ interface ឱ្យស្របនឹងទីតាំង IP
បន្ទាប់ពីនេះ រៀងរាល់ 1 ឬ 2 សប្តាហ៍ គួរត្រួតពិនិត្យឡើងវិញនូវប្រេកង់ CAPTCHA និងការផ្ទៀងផ្ទាត់ជំហានទីពីរ ហើយកត់ត្រាទុក។ បើក្រុមថែទាំបរិស្ថានជាច្រើនក្នុងពេលតែមួយ ការកំណត់ទំនាក់ទំនងថេររវាងបរិស្ថាននីមួយៗ ច្រកចេញ និងប៉ារ៉ាម៉ែត្រ នឹងជួយសន្សំការងារច្រើន។ អាចប្រើការគ្រប់គ្រងបរិស្ថានជាច្រើនរបស់ឧបករណ៍ដូចជា PurpleMark នៅដំណាក់កាលនេះ។
Proxy ដែលដំណើរការ និង Proxy ដែលសមស្រប គឺជារឿងពីរផ្សេងគ្នា។ រឿងទីមួយត្រូវការតែ configuration ត្រឹមត្រូវ; រឿងទីពីរត្រូវការផ្ទៀងផ្ទាត់រាល់ចំណុច។ ចំណុចដែលមិនបានពិនិត្យ ដូចជា DNS leak, WebRTC និងប្រភេទ IP គឺជាអ្វីដែលអាចបន្ថយភាពគួរឱ្យទុកចិត្តរបស់បរិស្ថានទាំងមូលដោយមិនសូវដឹងខ្លួន។
