केवल IPv6 कनेक्शन, IPv4 सेवा: SOCKS प्रॉक्सी को पुल बनने दें

गंतव्य तक पहुँचने के लिए आपको उसके पते के परिवार का पता होना ज़रूरी नहीं, बशर्ते रास्ते में कुछ रिले करने को तैयार हो। ऐप्लिकेशन प्रॉक्सी से जुड़ता है, और प्रॉक्सी गंतव्य से दूसरा कनेक्शन खोलता है। ये अलग-अलग पता परिवारों वाले दो सॉकेट हैं, और किसी भी प्रोटोकॉल में ऐसा कुछ नहीं है जो उनका मेल होना ज़रूरी बनाए। यह ऐप्लिकेशन-स्तर का रिले है, मूल IPv4 रास्ता नहीं, और यही अंतर तय करता है कि क्या काम करेगा और क्या नहीं। दोनों को गड्डमड्ड करना ही वह तरीका है जिससे लैपटॉप को IPv4 कनेक्टिविटी वाला बताया जाता है जबकि उसके पास केवल एक प्रॉक्सी है।

दो सॉकेट, दो पता परिवार

SOCKS5 अनुरोध गंतव्य को तीन रूपों में से एक में नाम देता है: शाब्दिक v4 पता, शाब्दिक v6 पता, या प्रॉक्सी द्वारा हल किया जाने वाला नाम। अनुरोध बताता है कि प्रॉक्सी को कहाँ जुड़ना चाहिए, यह नहीं कि क्लाइंट-से-प्रॉक्सी कनेक्शन कैसा दिखता है।

इन पता प्रकारों को एक ही संदेश के भीतर तीन स्वतंत्र विकल्पों के रूप में पढ़ें। IPv6 पर पहुँचने योग्य प्रॉक्सी IPv4 गंतव्य का सॉकेट तब खोल सकता है जब उसके पास काम करने वाला IPv4 आउटगोइंग हो और उसकी नीति अनुरोध की अनुमति दे। SOCKS5 विनिर्देश क्लाइंट के परिवहन का कोई उल्लेख किए बिना ही इन्हें परिभाषित करता है।

नियंत्रित SSH उदाहरण

ऐसा SSH होस्ट लें जिसे इस्तेमाल करने की अनुमति आपको है, जो IPv6 पर उत्तर देता है और स्वयं केवल v4 पर मौजूद HTTPS सेवा तक पहुँच सकता है। OpenSSH का गतिक फ़ॉरवर्डिंग आपकी मशीन पर स्थानीय SOCKS श्रोता रखता है जबकि लॉगिन सत्र v6 से चलता है।

ssh -6 -N -D 127.0.0.1:1081 -o ExitOnForwardFailure=yes [email protected]

ऊपर दिया होस्ट और खाता उदाहरण हैं, और लूपबैक बाइंडिंग श्रोता को इसी कंप्यूटर पर रखती है। इसे वाइल्डकार्ड बाइंडिंग से न बदलें ताकि कोई दफ़्तर बिना प्रमाणीकरण वाली प्रॉक्सी साझा कर सके। ExitOnForwardFailure=yes इसलिए मौजूद है कि विफल फ़ॉरवर्डिंग सत्र समाप्त कर दे, पृष्ठभूमि में चुपचाप चलता आदेश न छोड़े।

सत्र चालू होने पर अनुरोध ऐसा दिखता है:

curl --proxy socks5h://127.0.0.1:1081 https://v4-only.example/

लूपबैक कनेक्शन IPv4 इंटरनेट मार्ग नहीं है। आपकी मशीन से जो बाहर जाता है वह v6 से लॉगिन सत्र है, और दूर का पक्ष ही गंतव्य का सॉकेट खोलता है। socks5h रूप नाम-हल भी उस पक्ष को सौंपता है, जो तब मायने रखता है जब क्लाइंट के पास अपना IPv4 रिज़ॉल्वर मार्ग न हो।

गंतव्य वास्तव में क्या देखता है

गंतव्य रिले का आउटगोइंग पता देखता है। आपके लैपटॉप का कोई पता वहाँ नहीं दिखता। उस सेवा पर स्रोत-अनुमति सूची में रिले का नाम होना चाहिए। उसके लॉग भी ट्रैफ़िक को रिले को ही निस्संदेह ठहराएँगे। इसे ऑडिट से पहले परिवर्तन-रिकॉर्ड में लिखें, क्योंकि क्लाइंट पतों के इर्द-गिर्द बनी अनुमति सूची पहले ही अनुरोध पर विफल होती है।

रिले वह जगह भी है जहाँ बातचीत के दोनों आधे दिखते हैं, जो निदान के दौरान उपयोगी गुण है और नीति के बिना साझा किया गया रिले हो तो दायित्व।

यह DNS64 या NAT64 नहीं है

DNS64 v4 गंतव्यों का प्रतिनिधित्व करने वाले संश्लेषित रिकॉर्ड के साथ उत्तर देता है, और NAT64 कॉन्फ़िगर किए गए मार्ग पर पैकेट फिर से लिखता है। इनमें से कोई भी यह नहीं बताता कि यहाँ क्या होता है, जहाँ एक परिवहन बातचीत खत्म होती है और दूसरी शुरू होती है और कोई संश्लेषित पता परिणाम की व्याख्या नहीं करता। इसलिए सफल अनुरोध यह नहीं बताता कि आपका प्रदाता कौन-सी अनुवाद सेवाएँ चलाता है, और प्रॉक्सी अपने आउटगोइंग पर साधारण NAT चला सकता है।

दोनों तंत्र एक ही नेटवर्क में मौजूद हो सकते हैं, इसलिए जो सबसे करीब लगता है उसके बजाय जो आपने वास्तव में सत्यापित किया है उसका वर्णन करें।

वादा करने से पहले दायरा जानें

OpenSSH का गतिक फ़ॉरवर्डिंग TCP कनेक्शन ले जाता है, मनमाना IP ट्रैफ़िक नहीं, इसलिए UDP, ICMP और प्रॉक्सी को अनदेखा करने वाले किसी भी प्रोटोकॉल को अलग समर्थित डिज़ाइन चाहिए। SSH होस्ट-कुंजी सत्यापन, सर्वर के फ़ॉरवर्डिंग प्रतिबंध और HTTPS प्रमाणपत्र सत्यापन बनाए रखें, क्योंकि प्रॉक्सी एक अतिरिक्त विश्वसनीय भागीदार है, पहचान जाँच कमज़ोर करने का कारण नहीं। यदि लक्ष्य VPN के बाहरी परिवहन को प्रॉक्सी से ले जाना है, तो यह मानने के बजाय कि कोई भी SOCKS श्रोता उसे रिले कर सकता है, सत्यापित करें कि दोनों सिरे उस परिवहन का समर्थन करते हैं।

इनमें से कुछ भी क्लाइंट को दोहरे-स्टैक वाला नहीं बनाता, और ऐसा होना ज़रूरी भी नहीं। यह एक ऐप्लिकेशन को एक रिले के ज़रिए एक सेवा तक पहुँचाता है, जो छोटा दावा है और सत्यापित करना कहीं अधिक आसान।