ការអានកំហុស SO_ORIGINAL_DST របស់ Squid

NF getsockopt(SO_ORIGINAL_DST) ចង្អុលទៅការស្វែងរកគោលដៅដើម។ នៅក្នុងការដំឡើងស្ទាក់ចាប់ Squid ត្រូវរកឃើញថាតើការតភ្ជាប់ដែលបានបញ្ជូនបន្តទៅណាដំបូង។

កម្មវិធីរុករកដែលបានកំណត់ច្បាស់លាស់បញ្ជូនសំណើទៅប្រូកស៊ីដោយចេតនា។ ការតភ្ជាប់នោះមិនទទួលបានប្រវត្តិស្ទាក់ចាប់ NAT ដោយសារតែ intercept ត្រូវបានសរសេរនៅក្បែរច្រករបស់ឧបករណ៍ស្ដាប់ Squid នោះទេ។

ដូច្នេះភាពមិនស៊ីគ្នានេះអាចបរាជ័យមុនពេលវិញ្ញាបនបត្ររបស់គោលដៅមានសារៈសំខាន់។

ចាប់ផ្ដើមពីរបៀបដែលការតភ្ជាប់បានមកដល់

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

ឯកសារ http_port របស់ Squid បញ្ជាក់ភាពខុសគ្នាយ៉ាងច្បាស់៖ ការលោតសញ្ញារបៀបជ្រើសរបៀបប្រូកស៊ីបញ្ជូន; intercept រំពឹងការស្ទាក់ចាប់ NAT នៅស្រទាប់ IP។

បន្ទាប់មក សូមដោះស្រាយសុវត្ថិភាពការដឹកជញ្ជូនដោយឡែក។ ប្រូកស៊ី HTTP អាចដឹក HTTPS តាម CONNECT។ ការតភ្ជាប់ TLS ទៅប្រូកស៊ី ត្រូវការឧបករណ៍ស្ដាប់ និងការកំណត់អតិថិជនដែលត្រូវគ្នា។ ការឌិគ្រីបចរាចរណ៍គោលដៅគឺជាសមត្ថភាពជម្រើសមួយផ្សេងទៀត។

កុំចម្លង “ដំណោះស្រាយ HTTPS” ចាស់ដែលបើកការបង្កើតវិញ្ញាបនបត្រដោយសារតែ URL គោលដៅចាប់ផ្ដើមដោយ HTTPS។ ជួសជុលការស៊ីគ្នារវាងអតិថិជន និងឧបករណ៍ស្ដាប់ជាមុន។ ប្រសិនបើនៅសល់កំហុស TLS ពិតប្រាកដបន្ទាប់ពីនោះ វានឹងជាកំហុសដែលមានប្រយោជន៍ជាងសម្រាប់ការស៊ើបអង្កេត។