គោលដៅដើមក្នុងការបញ្ជូន TCP ទៅ SOCKS បែបថ្លា

ជញ្ជាំងភ្លើងអាចផ្លាស់ប្ដូរកន្លែងដែលការតភ្ជាប់ TCP ធ្លាក់ចុះ។ ប៉ុន្តែដោយការផ្លាស់ប្ដូរនោះតែម្នាក់ឯង វាមិនអាចបង្រៀនកម្មវិធីដើមឱ្យនិយាយ SOCKS បានទេ។

ម៉ាស៊ីនបម្រើ SOCKS ធម្មតារំពឹងការចរចាដែលពិពណ៌នាគោលដៅដែលបានស្នើ។ កម្មវិធីដែលមិនដឹងអំពីប្រូកស៊ី ផ្ទុយទៅវិញបញ្ជូនបៃពិធីការរបស់ខ្លួនភ្លាមៗ។ បញ្ជូនបៃទាំងនោះត្រង់ទៅអ្នកស្ដាប់ SOCKS ហើយភាគីទាំងពីរនឹងមិនយល់ព្រមលើសារដំបូងទេ។

សមាសភាគដែលខ្វះគឺអ្នកបកប្រែ

សមាសភាគ TCP ទៅប្រូកស៊ីបែបថ្លាស្ថិតនៅចន្លោះចំណុចប្រទាក់ទាំងនោះ។ វាស្វែងរកគោលដៅដែលកម្មវិធីបានស្នើដំបូង បង្កើតសម័យ SOCKS ឬ HTTP CONNECT សមស្រប បន្ទាប់មកបញ្ជូនទិន្នន័យកម្មវិធីលើលំហូរដែលកើតឡើង។

នៅលើផ្លូវ Linux iptables របស់វា ប្រភព redsocks ទាញយកគោលដៅដែលបានរក្សាទុកដោយប្រើ SO_ORIGINAL_DST។ ប្រព័ន្ធប្រតិបត្តិការ និងវិធីបង្វែរផ្សេងទៀតប្រើយន្តការផ្សេងគ្នា។ នេះជាលក្ខណៈរបស់អ្នកបង្វែរ និងការរៀបចំបណ្ដាញ មិនមែនមុខងាររបស់អតិថិជន SOCKS ធម្មតាទេ។

ព័ត៌មានគោលដៅដើមក៏ពន្យល់ផងដែរថាហេតុអ្វីការផ្លាស់ទីច្បាប់បង្វែរពីម៉ាស៊ីនប្រូកស៊ីទៅច្រកចេញចូលដែលមិនពាក់ព័ន្ធមិនតែងតែសមមូល។ ដំណើរការទទួលត្រូវការទិន្នន័យមេតាដែលរបៀបស្ទាក់ចាប់របស់វាទាមទារ។ អាសយដ្ឋានដែលសរសេរឡើងវិញនៅកន្លែងផ្សេងអាចលែងផ្ដល់ព័ត៌មាននោះក្នុងទម្រង់ដែលរំពឹងទុក។

រក្សាវិសាលភាពរបស់អ្នកបកប្រែឱ្យច្បាស់។ ការតភ្ជាប់ TCP ដែលបានបង្វែរហើយដំណើរការ មិនបញ្ជាក់ពីការគាំទ្រ UDP បំពាន ICMP ឬគ្រប់ផ្លូវដោះស្រាយនោះទេ។ ពិធីការប្រូកស៊ីខាងលើ និងការអនុវត្តរបស់អ្នកបកប្រែនៅតែកំណត់ប្រតិបត្តិការដែលគាំទ្រ។

នៅពេលការរៀបចំបរាជ័យភ្លាមៗបន្ទាប់ពីការតភ្ជាប់ សូមពិនិត្យព្រំដែនពិធីការមុនពេលពង្រីកច្បាប់ចូល។ អ្នកស្ដាប់ SOCKS ដែលអាចទៅដល់បានយ៉ាងល្អអាចបដិសេធបៃដែលមិនធ្លាប់ជាសំណើ SOCKS។