क्या दो OpenVPN सर्वरों के क्लाइंट एक-दूसरे तक पहुँच सकते हैं?

दूसरा OpenVPN सर्वर खड़ा करने से क्लाइंट जुड़ने की दूसरी जगह मिलती है, और कुछ नहीं। यह उन क्लाइंट को पहले सर्वर के नेटवर्क पर नहीं रखता, और client-to-client नाम का विकल्प केवल एक सर्वर प्रक्रिया के भीतर फ़ॉरवर्डिंग बदलता है। दोनों पूल तब एक नेटवर्क बनते हैं जब आप जानबूझकर उनके बीच रूट करते हैं, हर दिशा के लिए एक मालिक के साथ। नीचे सब कुछ उपयोगकर्ता-स्पेस TUN मोड और उस आंतरिक फ़ॉरवर्डिंग के बंद होने पर आधारित है, इसलिए निर्णय कर्नेल लेता है।

भ्रम: एक खाता सूची, एक नेटवर्क

प्रमाणन और पहुँच को आपस में मिला दिया जाता है क्योंकि दोनों सर्वर कॉन्फ़िगरेशन में रहते हैं। जो उपयोगकर्ता दोनों में से किसी भी गेटवे में लॉग इन कर सकता है, बाहर से दो दरवाज़ों वाली एक ही प्रणाली के उपयोगकर्ता जैसा दिखता है। भीतर, हर सर्वर अपने पूल से पते बाँटता है और केवल उन्हीं क्लाइंट के लिए रूट स्थापित करता है जिन्हें वह समाप्त करता है। इसलिए गेटवे A पर बैठा क्लाइंट जब गेटवे B के क्लाइंट को पैकेट भेजता है, तो ऐसा गंतव्य माँगता है जिसके बारे में उसका अपना सर्वर कभी सुना ही नहीं। पैकेट A के डिफ़ॉल्ट रूट पर जाता है, टनल छोड़ता है और ऐसे फ़ायरवॉल पर पहुँचता है जिससे कभी उसे अनुमति देने को नहीं कहा गया।

इसलिए दूसरा सर्वर जोड़ने से अतिरेक, खोज या साझा ब्रॉडकास्ट डोमेन नहीं जुड़ता। यह एक रूटेड नेटवर्क जोड़ता है जिसे योजना चाहिए, और योजना पता-निर्धारण से शुरू होती है।

हर गेटवे को अपना पूल और ट्रांज़िट पता दें

दो रेंज जो किसी और चीज़ से ओवरलैप नहीं कर सकतीं, साथ में होस्टों के बीच एक छोटा ट्रांज़िट लिंक, यही पूरी पता योजना है। ट्रांज़िट को अपने नियंत्रण वाले निजी सेगमेंट पर रखें, और किसी भी सर्वर के लीज़ देने से पहले संख्याएँ लिख लें।

दोनों सर्वरों को एक ही पूल देने के प्रलोभन का विरोध करें ताकि प्रोफ़ाइल एक जैसी रहें। कर्नेल रूट यह नहीं बता सकता कि साझा रेंज के भीतर कोई मनमाना पता अभी दो होस्टों में से किसके पास है, इसलिए रूटिंग तालिका एक गेटवे की ओर इशारा करेगी और क्लाइंट दूसरे से जुड़ा हो सकता है। इंटरफ़ेस नाम स्थानीय परिपाटियाँ हैं, साझा अवस्था नहीं। यहाँ दोनों होस्ट टनल डिवाइस को tun0 और ट्रांज़िट लिंक को transit0 कहते हैं, जो ठीक है क्योंकि कोई पैकेट ये नाम नहीं ढोता।

दोनों ओर रूट स्थापित करें

हर गेटवे को ट्रांज़िट पते के रास्ते दूसरे के पूल के लिए रूट चाहिए, और किसी के भी हॉप बनने के लिए फ़ॉरवर्डिंग चालू होनी चाहिए। पहले मौजूदा तालिका की पुष्टि करें, फिर प्रविष्टि जोड़ें और उसे रीकनेक्ट हुक के बजाय होस्ट के नेटवर्क मैनेजर से स्थायी बनाएँ।

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

पूल बदलकर दूसरे होस्ट पर भी यही दोहराएँ। असंबंधित स्क्रिप्ट से वही रूट बार-बार जोड़ना ही वह तरीका है जिससे होस्ट के पास कई प्रतियाँ और अगली बार तालिका पढ़ने पर रहस्यमय बदलाव रह जाता है। यदि ट्रांज़िट लिंक स्वयं टनल है, तो रूट उस टनल की टोपोलॉजी की ओर जाता है और हॉप को उसके रीकनेक्ट में टिकना होगा। तीस सेकंड के लिए गायब होने वाला ट्रांज़िट पता पूलों के बीच का रास्ता भी साथ ले जाता है, जो एक डिज़ाइन गुण है जिसे खोजने के बजाय घोषित करना बेहतर है।

मालिकी का नकली दावा किए बिना क्लाइंट रूट पुश करें

क्लाइंट को दूर के पूल के लिए रूट चाहिए, वरना उनका अपना ऑपरेटिंग सिस्टम पैकेट अपने डिफ़ॉल्ट गेटवे पर भेज देता है और टनल उसे कभी नहीं देखती। सर्वर कॉन्फ़िगरेशन इसे पहुँचाने की स्वाभाविक जगह है।

push "route 10.64.20.0 255.255.255.0"

मिरर पंक्ति दूसरे सर्वर के कॉन्फ़िगरेशन में रखें, फिर परीक्षण क्लाइंट को रीकनेक्ट करें और उसकी तालिका पढ़ें। पुश किए गए रूट अनदेखा करने वाले क्लाइंट को अपना स्वीकृत कॉन्फ़िगरेशन चाहिए, और जो रूट कभी नहीं पहुँचता वह अभिगम नियंत्रण नहीं है। किसी क्लाइंट को दूसरे गेटवे के पूरे पूल के लिए iroute न दें। वह निर्देश एक जुड़े क्लाइंट के पीछे के सबनेट के लिए है, और गेटवे के बीच गायब रूट को ढकने के लिए उसका उपयोग करने से बनता है ऐसा सर्वर जो मानता है कि उसके पास वे पते हैं जहाँ वह पहुँच नहीं सकता.

एक अनुरोध सिद्ध करें और दूसरे को अस्वीकार करें

कोई वास्तविक क्रिया चुनें, उदाहरण के लिए 10.64.10.21 पर क्लाइंट से 10.64.20.37 पर सेवा तक HTTPS, और दोनों होस्टों पर ठीक उसी की अनुमति दें। हर फ़ायरवॉल अपनी इनबाउंड ओर अनुरोध और रिटर्न ओर ट्रैक किया गया उत्तर स्वीकार करता है; गंतव्य की अपनी सेवा नीति को भी उसे स्वीकार करना होगा।

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

पारस्परिक रूट होने पर स्रोत NAT अनावश्यक है और यहाँ सक्रिय रूप से हानिकारक है: स्रोत का अनुवाद छिपा देता है कि किस क्लाइंट ने अनुरोध किया और गंतव्य पक्ष की स्रोत-आधारित नीति को विफल करता है। जाँचें कि इंटरनेट इग्रेस के लिए मौजूदा masquerade नियम इस रास्ते को भी नहीं पकड़ता। फिर अस्वीकृति जाँचें। जो सेवा पूल B के लिए स्थानीय रहनी चाहिए वह पूल A से अगम्य रहे, और एक ही गेटवे के क्लाइंट जोड़ों की भी जाँच होनी चाहिए, क्योंकि अभी बदली गई फ़ॉरवर्डिंग नीति उन पर भी लागू होती है।

मानसिक मॉडल में एक और सुधार: ट्रांज़िट लिंक डिक्रिप्ट किए गए आंतरिक पैकेट ढोता है, इसलिए यह निजी गारंटी नहीं बल्कि विश्वास सीमा है। यदि यह ऐसे नेटवर्क से गुज़रता है जो आपके नियंत्रण में नहीं है, तो उस हॉप को स्वीकृत एन्क्रिप्टेड टनल से सुरक्षित करें और उसकी वास्तविक टोपोलॉजी से रूट करें। एंड-टू-एंड TLS अब भी एप्लिकेशन का स्वयं प्रमाणन करता है, इसीलिए आंतरिक सेवा को उसका उपयोग जारी रखना चाहिए।