NAT पछाडिको OpenVPN क्लाइन्ट कसरी इन्टरनेट एक्जिट बन्छ

तीन Linux होस्ट, एउटा डिजाइन: सार्वजनिक रूपमा पहुँचयोग्य OpenVPN हब, एउटा ल्यापटप र भित्र केही पनि फर्वार्ड नगर्ने साधारण घरायसी राउटरको पछाडि रहेको एक्जिट मेसिन। एक्जिट आफैं हबमा डायल गर्छ। त्यसपछि ग्राहकको इन्टरनेट ट्राफिक ल्यापटपमा टनेलभित्र पस्छ र एक्जिटको आफ्नै अपलिङ्कबाट बाहिर निस्कन्छ। यो व्यवस्थामा अचम्मको सबै कुरा एउटा विवरणबाट आउँछ: जडान एक्जिटले सुरु गरेको थियो, त्यसैले भित्र जाने बाटो पहिल्यै छ र त्यो बनाउन पोर्ट फर्वार्डिङ आवश्यक छैन।

तलको विवरण कन्फिगरेसनको क्रम नभई प्याकेटको बाटो पछ्याउँछ, किनकि कुन घटकले कुन निर्णय लिन्छ भन्ने थाहा भएपछि मात्र कन्फिगरेसनको अर्थ हुन्छ। प्रत्येक तहले ठ्याक्कै एउटा निर्णय लिन्छ, र गल्तीहरू दुई तहलाई एउटै मानिने ठाउँमा जम्मा हुन्छन्।

दुई ट्रान्सपोर्ट सत्र, एउटा आन्तरिक बाटो

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

outer: consumer --TLS--> hub
outer: exit     --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink

दुवै बाह्य जडान ग्राहकको तर्फबाट बाहिर जाने भएकाले, एक्जिटको राउटरले कहिल्यै इनबाउन्ड SYN देख्दैन र कहिल्यै गन्तव्य NAT नियम आवश्यक पर्दैन। यसले स्थापित ट्रान्सपोर्टलाई जीवित राख्न मात्र पर्छ, जुन यसले कुनै पनि लामो जडानका लागि पहिल्यै गर्छ। सार्वजनिक इन्टरनेटमा केही पनि पहिले एक्जिटसम्म पुग्न आवश्यक छैन, त्यसैले त्यो अपलिङ्कमा गतिशील ठेगाना समस्या होइन। राउटरले बाहिर जाने सत्रलाई अनुमति दिनुपर्छ, तर त्यो ब्राउजरले पहिल्यै प्रयोग गर्ने अनुमति नै हो।

iroute ले सर्भरभित्र वास्तवमा के स्थापना गर्छ

कुन साथी कुन गन्तव्यको मालिक हो भन्ने हबले मात्र निर्णय गर्छ, र त्यो निर्णय यसले कर्नेलमा होइन, आफ्नै प्रयोगकर्ता स्पेस रुटिङ तालिकामा लिन्छ। एक्जिटका लागि exit-node नामको client-config-dir प्रविष्टिले त्यहाँ पूर्वनिर्धारित प्रिफिक्स दाबी गर्न सक्छ:

# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0

त्यो लाइनले सर्भर प्रक्रियालाई भन्छ "कुनै पनि गन्तव्य भएका आन्तरिक प्याकेट यो ग्राहकका हुन्"। यसले हबको अपरेटिङ सिस्टममा पूर्वनिर्धारित रुट थप्दैन र हबलाई इन्टरनेट गेटवे बनाउँदैन। OpenVPN 2.6 सन्दर्भ ग्राहक-विशिष्ट आन्तरिक रुटिङ र कर्नेल रुटिङलाई छुट्टाछुट्टै संयन्त्रका रूपमा राख्छ, र यही विभाजनका कारण यो डिजाइन हबको पूर्वनिर्धारित रुटलाई नछोई काम गर्छ।

ग्राहकलाई ऐनाजस्तो निर्देशन चाहिन्छ, push का रूपमा पुर्याइन्छ, ताकि उसको आफ्नै ट्राफिक स्थानीय गेटवेबाट बाहिर जानुको सट्टा टनेलभित्र पसोस्। सबनेट टोपोलोजीमा पूल एक्जिटको tun उपकरणमा जोडिएको रुट हो, त्यसैले फर्कने दिशालाई थप push चाहिँदैन; एक्जिटले पाउनु नहुने कुरा तलको रिडाइरेक्सन हो, जसले उसको आफ्नै अपलिङ्क ट्राफिकलाई प्रयोग गर्न खोजिरहेको टनेलमै फर्काइदिन्छ। यसलाई ग्राहकलाई मात्र पठाउनुहोस् र CCD फाइल छानिएको छ भनी विश्वास गर्नुको सट्टा क्लाइन्टमा लागू भएका रुटहरू पढ्नुहोस्।

# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"

फर्वार्डिङ एक्जिटको कर्नेलले गर्छ

एक्जिटभित्र ग्राहकको प्याकेट tun इन्टरफेसमा कुनै इन्टरनेट होस्टको ठेगानामा आउँछ। कर्नेलले आफ्नो रुटिङ तालिका हेर्छ, उत्तम मिलानका रूपमा वास्तविक अपलिङ्क भेट्टाउँछ र त्यसपछि दुई स्वतन्त्र नीति लागू गर्छ: यो प्याकेट बिल्कुलै फर्वार्ड गर्न मिल्छ कि मिल्दैन, र त्यो इन्टरफेसबाट त्यो स्रोत ठेगानासहित बाहिर जान मिल्छ कि मिल्दैन। फर्वार्डिङ एउटा sysctl हो, र धेरै वितरणहरूमा पूर्वनिर्धारित रूपमा बन्द हुन्छ।

त्यसैले एक्जिटलाई निरन्तर खुला IPv4 फर्वार्डिङ, ग्राहकको टनेल स्रोतहरूलाई अपलिङ्कतर्फ स्वीकार गर्ने नियम र tun मार्फत फर्कने उत्तर-बाटो चाहिन्छ। पूरै होस्टका लागि फर्वार्डिङ खोल्दा यसको बाटो हुने अरू सबैको व्यवहार पनि बदलिन्छ, त्यसैले नियमले सबै स्वीकार गर्नुको सट्टा स्रोत र इन्टरफेसको नाम दिनुपर्छ।

फर्कने बाटो स्रोत अनुवादले किन्छ

इन्टरनेट होस्टसँग 10.90.0.x ठेगानासम्म कुनै रुट छैन, त्यसैले उत्तरहरू एक्जिटसम्म पुग्नुअघि नै खारेज हुन्थे। प्याकेट अपलिङ्क छोड्दा स्रोत पुनर्लेखन गर्दा त्यो समाधान हुन्छ, र जडान ट्र्याकिङले फर्कंदा त्यो पुनर्लेखन उल्टाइदिन्छ।

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9   # run on the exit: must point at the tun

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

हब कहाँ लागू गर्न सक्छ र कहाँ सक्दैन

client-to-client र परम्परागत प्रयोगकर्ता स्पेस डेटा पाथसँग हबले सर्भर प्रक्रियाभित्रै साथीहरूबीच आन्तरिक प्याकेट सुम्पन्छ। ती कहिल्यै हबको कर्नेल FORWARD चेनबाट जाँदैनन्, त्यसैले त्यहाँको कर्नेल नियमले जतिसुकै होसियारीसाथ लेखिए पनि साथीहरूबीचको आवागमन सीमित गर्न सक्दैन। कार्यान्वयन सर्भरको आफ्नै नीतिमा हुनुपर्छ: कसलाई जडान गर्न अनुमति छ, कुन CCD फाइल पाउँछ, र एक्जिटको पूर्वनिर्धारित स्वामित्व दिइन्छ कि दिइँदैन।

त्यसैले पूर्वनिर्धारित iroute व्यापक विश्वासको निर्णय हो। एक्जिटले मनपरी इन्टरनेट ठेगानाबाट फर्कने ट्राफिक वैध रूपमा स्वीकार गर्नुपर्छ, र यो तपाईंले नियन्त्रण, प्याच र अनुगमन गर्ने मेसिन हुनुपर्छ। त्यही स्वामित्व तपाईंले राउटर नसुम्पने साथीलाई दिनु नै यो डिजाइनले निम्त्याउने गल्ती हो।

सदस्यता नै वास्तविक नियन्त्रण हो। आफ्नै रुट कन्फिगर गर्न सक्ने जुनसुकै क्लाइन्टले एक्जिट प्रयोग गर्न खोज्न सक्छ, त्यसैले कसले जडान गर्न सक्छ वा एक्जिटले कुन साथीलाई सेवा दिन्छ भन्ने सीमित गर्नु डिजाइनको हिस्सा हो, पछिको सोचाइ होइन।

एक्जिट हराउँदा सुरक्षित रूपमा असफल हुनु

एक्जिट अफलाइन गर्नुहोस्, आन्तरिक पूर्वनिर्धारित स्वामित्व उसको सत्रसँगै हराउँछ। हुनु नहुने कुरा यो हो कि हब चुपचाप प्रतिस्थापन एक्जिट बनोस्: VPN पूलबाट हबको अपलिङ्कसम्म कुनै पूर्वनिर्धारित रुट नहुँदोस्, र हबमा त्यही ट्राफिक खुसीसाथ फर्वार्ड गर्ने व्यापक मास्करेड नियम नहुँदोस्। त्यो असफलता जानाजान परीक्षण गर्नुहोस्, त्यसपछि पहिल्यै खुलेको पृष्ठको सट्टा नयाँ प्रवाहले पुनःप्राप्ति परीक्षण गर्नुहोस्।

# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

एक्जिट गएपछि पनि ग्राहकको ट्राफिक इन्टरनेटसम्म पुग्छ भने अरू केहीले बोकिरहेको छ र तपाईंले सोचेको सीमा अवस्थित छैन। DNS र IPv6 लाई पनि छुट्टै निर्णय मान्नुहोस्: IPv4 रुट र मास्करेडले AAAA ट्राफिकबारे केही भन्दैन, र हबले धकेलेको रिजोल्भरले क्वेरी वास्तवमै जहाँबाट बाहिरिन्छ त्यहीँबाट उत्तर दिन्छ।