AllowCONNECT របស់ Apache និងច្រកគោលដៅ HTTPS

ប្រូកស៊ី Apache របស់អ្នកស្តាប់នៅច្រក 3128។ អតិថិជនមួយទៅដល់វាដោយជោគជ័យ ប៉ុន្តែសេវា HTTPS នៅច្រក 8443 បរាជ័យ។ ការផ្លាស់ប្តូរច្រកស្តាប់របស់ប្រូកស៊ីទំនងជាមិនដោះស្រាយភាពខុសគ្នាជាក់លាក់នោះទេ។

អតិថិជនភ្ជាប់ទៅអ្នកស្តាប់របស់ប្រូកស៊ីជាមុន។ បន្ទាប់មក សំណើ CONNECT របស់វាបញ្ជាក់ឈ្មោះម៉ាស៊ីន និងច្រកគោលដៅដាច់ដោយឡែក។ Apache អាចទទួលយកការតភ្ជាប់ដំបូង ហើយបដិសេធប្រតិបត្តិការទីពីរ។

អាន AllowCONNECT ជាគោលនយោបាយគោលដៅ

សម្រាប់ Apache 2.4 mod_proxy_connect ដោះស្រាយសំណើ CONNECT ចូល។ សេចក្តីណែនាំ AllowCONNECT របស់វាគ្រប់គ្រងច្រកគោលដៅដែលមានសម្រាប់សំណើទាំងនោះ។ តម្លៃលំនាំដើមដែលបានឯកសារគឺ 443 និង 563។

AllowCONNECT 443 8443

ឧទាហរណ៍នេះជ្រើសរើសច្រកគោលដៅទាំងពីរនោះ។ វាជំនួសការជ្រើសរើសលំនាំដើម វាមិនបន្ថែម 8443 ខណៈពេលរក្សាច្រកលំនាំដើមទាំងអស់ដោយស្ងាត់ៗទេ។ ប្រើសេចក្តីណែនាំនៅក្នុងការកំណត់ម៉ាស៊ីនមេ ឬហ៊ូសនិម្មិតដែលពាក់ព័ន្ធ។

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

ឧទាហរណ៍ប្រូកស៊ីបញ្ច្រាសឆ្លើយសំណួរមួយផ្សេង

លទ្ធផលស្វែងរកសម្រាប់ Apache និង HTTPS ច្រើនតែបង្ហាញគេហទំព័រសាធារណៈដែលបញ្ជូនបន្តទៅ backend ថេរ។ ការកំណត់នោះមិនមែនជារបៀបដែលកម្មវិធីរុករកស្នើសុំឱ្យប្រូកស៊ីខាងមុខបើកផ្លូវរូង CONNECT ទៅគេហទំព័រដែលបានជ្រើសរើសនោះទេ។ ការចម្លងសេចក្តីណែនាំកំណត់ផ្លូវរបស់វាអាចទុកបញ្ហាប្រូកស៊ីដើមដោយមិនប៉ះពាល់។

នៅពេលធ្វើរោគវិនិច្ឆ័យការបរាជ័យ កត់ត្រាអ្នកស្តាប់ដែលអតិថិជនបានទៅដល់ អាជ្ញាធរ CONNECT ដែលបានស្នើ និងការឆ្លើយតបរបស់ប្រូកស៊ី។ ប្រសិនបើ CONNECT ជោគជ័យ ហើយ TLS បរាជ័យបន្ទាប់មក ការអនុញ្ញាតច្រកគោលដៅបានបំពេញតួនាទីរួចហើយ។ បន្តជាមួយ ការបរាជ័យ TLS ជំនួសឱ្យការពង្រីក AllowCONNECT ម្តងហើយម្តងទៀត។