3proxy सह SOCKS क्लायंटना HTTP CONNECT पालकाशी जोडा

अॅप्लिकेशनला SOCKS आवश्यक आहे. तुमची मंजूर अपस्ट्रीम सेवा HTTP CONNECT स्वीकारते. अॅप्लिकेशनच्या SOCKS फील्डमध्ये HTTP एंडपॉइंट ठेवल्याने प्रोटोकॉलमध्ये भाषांतर होत नाही.

गेटवे अॅप्लिकेशनकडून SOCKS घेऊ शकतो, विनंती केलेले गंतव्य वाचू शकतो आणि त्या गंतव्यासाठी HTTP पालकाकडे CONNECT बोगदा मागू शकतो. नंतर तो अॅप्लिकेशनचा प्रवाह बोगद्यातून पाठवतो.

SOCKS application → SOCKS-facing gateway → HTTP CONNECT parent → destination

प्रत्येक इंटरफेस स्पष्ट करा

ही रचना समर्थित करणाऱ्या गेटवेसाठी त्याचा पालक प्रकार महत्त्वाचा आहे. 3proxy चे दस्तऐवज connect पालकाला सामान्य HTTP फॉरवर्डिंग प्रॉक्सी म्हणून वापरल्या जाणाऱ्या पालकापासून वेगळे करते.

विद्यमान 3proxy वापरकर्ता आणि प्रमाणीकरण सेटअप असल्यास, फक्त-स्थानिक राउटिंग तुकडा असा दिसू शकतो:

auth strong
allow alex
parent 1000 connect parent.example.net 8080
socks -i127.0.0.1 -p1080

हा तुकडा गृहीत धरतो की खाते आधीच परिभाषित आहे. तो HTTP पालकाला स्वतःला आवश्यक असलेली कोणतीही ओळख जोडत नाही आणि विद्यमान प्रवेश धोरण बदलत नाही. प्रमाणीकरण नसलेल्या सार्वजनिक HTTP पालकाला परवानगी देणाऱ्या मार्गावरील सार्वजनिक गंतव्यांसाठी, HTTP प्रॉक्सी सूची होस्ट आणि पोर्टचे उमेदवार देते. त्या शाखेसाठी पालक ओळख अनुपस्थित ठेवा आणि वास्तविक लक्ष्यासाठी परवानगीची पुष्टी करा; गेटवेचे स्वतःचे खाते स्थानिकच राहते. parent नियम 3proxy च्या दस्तऐवजीकृत कॉन्फिगरेशन मॉडेलनुसार आधीच्या allow नियमाशी जोडलेला आहे.

अॅप्लिकेशन स्थानिक SOCKS एंडपॉइंट वापरते. गेटवे पालकाकडे HTTP CONNECT वापरतो. विनंती केलेला गंतव्य होस्ट आणि पोर्ट परवानगीयोग्य आहेत का हे अजूनही पालकच ठरवतो.

इथे उपयुक्त व्याप्ती सामान्य TCP प्रवाह बोगदा आहे. समोरचा श्रोता SOCKS5 स्वीकारतो म्हणूनच SOCKS5 UDP सहयोग समर्थित होत नाही. HTTP CONNECT पालक आवश्यक UDP रिले स्वयंचलितपणे देत नाही.

HTTPS या मार्गात टोकापासून टोकापर्यंत राहू शकते; प्रॉक्सी इंटरफेसांमधील भाषांतरासाठी गंतव्य वेबसाइटचे रूप धारण करणे आवश्यक नाही. गेटवेसाठी, पालकासाठी आणि वेबसाइटसाठी प्रमाणीकरण वेगवेगळी ओळख आणि देवघेव राहतात.