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 र नामस्थान सेटिङ। यो श्रृंखला दोस्रो पटक सम्झनाबाट हल गर्न टिप्पणीभन्दा महँगो पर्छ। ती चार तथ्य टिकटमा राख्नुहोस्, च्याट थ्रेडमा होइन।

जुन श्रृंखलाले जोडिएको बताउँछ र केही पठाउँदैन, त्यो प्रायः त्यही हपमा असफल भएको हुन्छ जुन तपाईंले अझै प्रमाणित गर्नुभएको छैन। अर्को तह थप्नुअघि त्यो हप परीक्षण गर्नुहोस्।