SOCKS5 वर OpenVPN: आवृत्ती, ट्रान्सपोर्ट आणि DNS जुळवा

या वर्कस्टेशनमधून बाहेर पडण्याचा एक मार्ग SOCKS प्रॉक्सी आहे, आणि त्यामागे OpenVPN कोणत्याही उपयुक्त तपशिलाशिवाय कनेक्ट टाइमआउट नोंदवते। त्याच मशीनवरील ब्राउझर त्या प्रॉक्सीमधून चालतो, ओळखपत्रे बरोबर आहेत, आणि पोर्ट उत्तर देतो। तीन गोष्टी इतक्या वेगळ्या असतात की आधी तपासल्या पाहिजेत: प्रॉक्सी जी SOCKS आवृत्ती बोलते, क्लायंटने निवडलेला ट्रान्सपोर्ट, आणि जिथे नाव विश्लेषण होते। फायरवॉलला दोष देण्यापूर्वी यातील प्रत्येकाची खात्री करा।

फायरवॉलपूर्वी SOCKS आवृत्ती जुळवा

समुदाय OpenVPN socks-proxy साठी SOCKS5 बोलते। ते अशा प्रॉक्सीवर लावा जी फक्त SOCKS4 देते; TCP जोडणी उघडते आणि नंतर थांबते, कारण क्लायंट अशा सलामीच्या उत्तराची वाट पाहतो जी दुसरे टोक कधीही पार्स करत नाही। बाहेरून हे थांबणे अगदी फिल्टर झालेल्या पोर्टसारखे दिसते, म्हणूनच आवृत्तीचा प्रश्न कोणत्याही फायरवॉल नियमापूर्वी येतो। SOCKS-जाणते फेच एकाच कमांडमध्ये हे ठरवते।

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example

पूर्ण झालेली विनंती एकाच वेळी दोन गोष्टी सिद्ध करते: प्रॉक्सीने SOCKS विनंती स्वीकारली आणि तिने नावाचे विश्लेषण केले। कोणत्याही URL स्कीमची गरज नाही, कारण curl नग्न होस्टला HTTP मानतो, आणि हे या चाचणीसाठी पुरते आहे।

हे फेच क्लायंट लॉग लपवत असलेले अपयशही वगळते। प्रॉक्सी ब्राउझरला परवानगी देऊनही VPN गंतव्य नाकारू शकते, आणि मग नकार CONNECT वर होतो, कोणत्याही VPN प्रमाणीकरणापूर्वी। OpenVPN फक्त टाइमआउट सांगते, म्हणून प्रॉक्सीचे स्वतःचे उत्तर हाच तुम्हाला हवा असलेला पुरावा आहे।

ट्रान्सपोर्ट दोन्ही बाजूंनी TCP असावा

SOCKS5 येथे TCP स्ट्रीम नेतो, म्हणून बोगद्यालाच proto tcp-client लागतो। जे प्रोफाइल अजूनही UDP वर सेट आहे ते या मार्गाने चालणार नाही, कारण क्लायंट प्रोटोकॉलचा UDP असोसिएशन मोड वापरत नाही। प्रोफाइल फिरवणे हा खरा बदल आहे, औपचारिकता नाही: दूरच्या टोकाला त्याच पोर्टवर TCP वर ऐकावे लागेल। नंतर पेलोड TCPच्या आत TCP होतो, जिथे हरवलेला सेगमेंट दोनदा पुन्हा पाठवला जातो आणि गती घटते, जे इंटरॅक्टिव्ह सत्रांना मोठ्या हस्तांतरणांपेक्षा कितीतरी जास्त जाणवते।

proto tcp-client
remote gw.lab.example 8443
socks-proxy 127.0.0.1 9050

ही सूचना प्रॉक्सी होस्ट, ऐच्छिक पोर्ट आणि ऐच्छिक ओळखपत्र फाइल घेते। त्या प्रोफाइलमध्येच ठेवा जेणेकरून दुसरीकडे ठेवलेली प्रत तसेच वागेल।

संपूर्ण साखळी एका कंटेनरमध्ये मर्यादित करा

साखळी होस्टवर करणे म्हणजे त्याचा डीफॉल्ट मार्ग ताब्यात घेणे आणि resolver अशा स्थितीत सोडणे जी नंतर कोणी समजावू शकणार नाही। नामस्थान किंवा कंटेनर त्याऐवजी ती मर्यादित करते, त्यामुळे होस्ट स्वतःचा मार्ग ठेवतो आणि SOCKS हॉप व बोगदा एकत्र राहतात। त्याच्या आत काहीही बोगदा उपकरण, ते उपकरण संरचित करण्याचे हक्क आणि पोहोचण्यायोग्य प्रॉक्सीशिवाय उभे राहत नाही। Compose सेवा हे cap_add: NET_ADMIN आणि bind-माउंट केलेल्या /dev/net/tun ने मिळवते।

cap_add:
  - NET_ADMIN
devices:
  - /dev/net/tun:/dev/net/tun

ही जोडी कंटेनर privileged चालवण्यापेक्षा अरुंद आहे, आणि उपकरणापर्यंतच्या प्रवेशाचा सगळा आवश्यक भाग एवढाच आहे। Tor क्लायंट किंवा वेगळा प्रॉक्सी कंटेनर ऐकणारा पुरवू शकतो। दोन्ही स्थितींमध्ये तो loopback वर बांधा, आणि प्रॉक्सी नेटवर्कवर उघड करण्याऐवजी नामस्थानातून होस्टमार्फत त्याच्यापर्यंत पोहोचा।

नाव विश्लेषण हीच ती जागा आहे जिथे विलगीकरण अयशस्वी होते

जो बोगदा पॅकेट नेतो पण होस्टच्या resolver ला विचारतो त्याने काहीही वेगळे केले नाही। दोन गोष्टी विलगीकरण खरे करतात: नामस्थानाचा स्वतःचा resolver असणे, आणि त्याच्या क्वेऱ्या प्रॉक्सी किंवा बोगद्यातून जाणे, कधीही भौतिक इंटरफेसवरून नाही। चाचणीसाठी दोन नावे वापरा: एक जे फक्त बोगद्यामागे अस्तित्वात आहे, आणि एक सार्वजनिक ज्याने तोच मार्ग घ्यायला हवा।

docker compose exec vpn cat /etc/resolv.conf
docker compose exec vpn getent hosts internal.lab.example

जर दूरचे नाव विश्लेषित होते आणि सार्वजनिक नाही, तर साखळी निवडक आहे, तुटलेली नाही, आणि फरक सांगतो की प्रत्येक क्वेरीने कोणता मार्ग घेतला। जर दोन्ही होस्टवरून विश्लेषित होतात पण कंटेनरच्या आत कोणीही नाही, तर कंटेनर अजूनही होस्टचा resolver उधार घेत आहे। जी resolver फाइल सापडली ती नोंदवा, कारण तीच सेटिंग बदलायची आहे।

प्रत्येक हॉप क्रमाने सिद्ध करा

यादी लहान आहे। SOCKS5 विनंतीला उत्तर मिळते, बोगदा प्रॉक्सीमार्फत त्याच्या ऐकणाऱ्यापर्यंत पोहोचतो, आणि नामस्थानातून बाहेर पडणारे पॅकेट ते पत्ता नेतात ज्याची दूरचे टोक अपेक्षा करते। अधिक संरचना चढवण्याऐवजी प्रत्येकाची स्वतंत्रपणे खात्री करा। जेव्हा क्लायंट म्हणतो जोडलेले आहे आणि काहीच हलत नाही, तेव्हा तुटणे जवळजवळ नेहमी दुसऱ्या किंवा तिसऱ्या तथ्यात असते।

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example
docker compose exec vpn ip route get 203.0.113.10
docker compose exec vpn getent hosts internal.lab.example

जे संयोजन चालले ते लिहून ठेवा: SOCKS आवृत्ती, ट्रान्सपोर्ट, resolver आणि नामस्थान सेटिंग्ज। ही साखळी दुसऱ्यांदा स्मरणातून सोडवणे टिपेपेक्षा जास्त महाग आहे। ती चार तथ्ये तिकिटात ठेवा, चॅट थ्रेडमध्ये नाही।

जी साखळी जोडलेली असे सांगते आणि काहीही पुढे नेत नाही, ती सहसा त्या हॉपवर अयशस्वी झाली आहे जी तुम्ही अजून सिद्ध केली नाही। आणखी थर चढवण्यापूर्वी ती हॉप तपासा।