IPv6 मात्र जडान, IPv4 सेवा: SOCKS प्रोक्सीलाई पुल बन्न दिनुहोस्

गन्तव्यको ठेगाना परिवारको ठेगाना नभए पनि त्यहाँ पुग्न सकिन्छ, बाटोमा केही रिले गर्न तयार भएसम्म। एप्लिकेसन प्रोक्सीसँग जोडिन्छ, र प्रोक्सीले गन्तव्यसँग दोस्रो जडान खोल्छ। यी स्वतन्त्र ठेगाना परिवार भएका दुई सकेट हुन्, र कुनै पनि प्रोटोकलले तिनीहरू मिल्नुपर्ने माग गर्दैन। यो एप्लिकेसन-तहको रिले हो, मूल IPv4 बाटो होइन, र यही भिन्नताले के काम गर्छ र के गर्दैन भन्ने निर्धारण गर्छ। दुवैलाई गल्याउनु नै ल्यापटपलाई IPv4 जडान भएको भनी वर्णन गर्ने तरिका हो, जबकि उसँग भएको सबै एउटा प्रोक्सी मात्र हो।

दुई सकेट, दुई ठेगाना परिवार

SOCKS5 अनुरोधले गन्तव्यलाई तीन रूपमध्ये एकमा नाम दिन्छ: शाब्दिक v4 ठेगाना, शाब्दिक v6 ठेगाना, वा प्रोक्सीले समाधान गर्ने नाम। अनुरोधले प्रोक्सी कहाँ जोडिनुपर्छ भनी वर्णन गर्छ, क्लाइन्ट-देखि-प्रोक्सी जडान कस्तो देखिन्छ भनेर होइन।

यी ठेगाना प्रकारलाई एउटै सन्देशभित्रका तीन स्वतन्त्र छनोटका रूपमा पढ्नुहोस्। IPv6 मार्फत पुग्न सकिने प्रोक्सीले काम गर्ने IPv4 निकास भएको र यसको नीतिले अनुरोधलाई अनुमति दिएको बेला IPv4 गन्तव्यको सकेट खोल्न सक्छ। SOCKS5 विशिष्टता मा क्लाइन्टको यातायातको कुनै उल्लेख नगरी तिनीहरू परिभाषित गरिएका छन्।

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

प्रयोग गर्न अनुमति भएको SSH होस्ट लिनुहोस्, जुन IPv6 मा जवाफ दिन्छ र आफैँ v4 मा मात्र रहेको HTTPS सेवासम्म पुग्न सक्छ। OpenSSH को गतिशील फर्वार्डिङले लगइन सत्र v6 मार्फत चलिरहँदा तपाईंको मेसिनमा स्थानीय SOCKS श्रोता राख्छ।

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 श्रोताले यसलाई रिले गर्न सक्छ भनी मान्नुको सट्टा दुवै छेउले त्यो यातायात समर्थन गर्छन् भनी प्रमाणित गर्नुहोस्।

यीमध्ये केहीले पनि क्लाइन्टलाई दोहोरो-स्ट्याक बनाउँदैन, र त्यसको आवश्यकता पनि छैन। यसले एउटा एप्लिकेसनलाई एउटा रिलेमार्फत एउटा सेवासम्म पुग्न दिन्छ, जुन सानो दाबी हो र प्रमाणित गर्न धेरै सजिलो छ।