Privoxy៖ ភ្ជាប់អតិថិជនប្រូកស៊ី HTTP ទៅនឹងផ្លូវរូង SOCKS

ផ្លូវរូង SSH បែបឌីណាមិក រួមទាំងការបញ្ជូនបែបឌីណាមិករបស់ PuTTY ផ្តល់ចំណុចប្រទាក់ SOCKS។ កម្មវិធីដែលទទួលតែប្រូកស៊ី HTTP មិនអាចប្រើច្រកនោះដោយគ្រាន់តែហៅវាថា HTTP បានទេ។

ស្ពានពិធីការមូលដ្ឋានអាចឈរនៅចន្លោះពួកវា។ កម្មវិធីផ្ញើសំណើប្រូកស៊ី HTTP ទៅស្ពាន ហើយស្ពានបើកការតភ្ជាប់គោលដៅតាមរយៈសេវា SOCKS។

Privoxy ចងក្រងការរៀបចំនេះតាមរយៈច្បាប់បញ្ជូនរបស់វា។ សម្រាប់ផ្លូវរូង SOCKS5 មូលដ្ឋានដែលមានស្រាប់ បំណែកកំណត់រចនាសម្ព័ន្ធគឺ៖

forward-socks5 / 127.0.0.1:1080 .

កម្មវិធីភ្ជាប់ទៅអ្នកស្តាប់ HTTP របស់ Privoxy មិនមែនច្រក 1080 ទេ។ រក្សាអ្នកស្តាប់នោះឱ្យនៅមូលដ្ឋានក្រោមគោលនយោបាយចូលប្រើដែលបានបម្រុង។ ចំណុចចុងក្រោយក្នុងច្បាប់មានអត្ថន័យដែលបានចងក្រង។ វាមិនមែនជាកន្លែងជំនួសសម្រាប់ឈ្មោះម៉ាស៊ីនអ៊ីនធឺណិតដែលបាត់នោះទេ។

នេះគឺជាការបកប្រែពិធីការ

ឯកសារបញ្ជូនរបស់ Privoxy ពន្យល់វាក្យសម្ព័ន្ធបញ្ជូន SOCKS និងការដោះស្រាយឈ្មោះម៉ាស៊ីន។ ការបញ្ជូនច្រក TCP ធម្មតាមិនធ្វើការបកប្រែដូចគ្នាទេ៖ វាដឹកបៃ HTTP របស់អតិថិជនដោយមិនផ្លាស់ប្តូរទៅអ្នកស្តាប់ SOCKS ដែលនៅតែរំពឹងការចរចា SOCKS។

ស្ពានក៏ក្លាយជាផ្នែកនៃការកំណត់រចនាសម្ព័ន្ធដែលអ្នកត្រូវយល់។ Privoxy អាចមានការកំណត់ត្រងមាតិកា និងការចូលប្រើផ្ទាល់ខ្លួន។ ការបន្ថែមវាមិនដូចគ្នានឹងការធ្វើឱ្យកម្មវិធីដើមគាំទ្រ SOCKS តាមបែបដើមនោះទេ។

សម្រាប់គេហទំព័រ HTTPS កម្មវិធីជាធម្មតាស្នើ CONNECT ទៅស្ពាន HTTP ហើយស្ពានទទួលការតភ្ជាប់គោលដៅតាមរយៈ SOCKS។ TLS ធម្មតារបស់គេហទំព័រនៅតែជាទំនាក់ទំនងរវាងកម្មវិធី និងគេហទំព័រ។ ស្ពានមិនចាំបាច់ក្លែងខ្លួនជាគេហទំព័រដើម្បីផ្តល់ផ្លូវនេះទេ។

ប្រសិនបើកម្មវិធីអាចប្រើ SOCKS ដោយផ្ទាល់ ធាតុបន្ថែមអាចមិនចាំបាច់។ ប្រើស្ពានដើម្បីដោះស្រាយភាពមិនស៊ីគ្នានៃពិធីការពិតប្រាកដ ដោយបែងចែកអ្នកស្តាប់ និងដំណើរការខាងលើឱ្យច្បាស់។