फक्त 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 श्रोता ती रिले करू शकतो असे गृहीत धरण्याऐवजी दोन्ही टोके त्या वाहतुकीला समर्थन देतात याची पडताळणी करा.

यातील काहीही क्लायंटला दुहेरी-स्टॅक बनवत नाही, आणि त्याची गरजही नाही। हे एका अॅप्लिकेशनला एका रिलेमार्फत एका सेवेपर्यंत पोहोचवते, जे लहान दावा आहे आणि पडताळणे खूप सोपे आहे.