हर OpenVPN नोड पर एक ही सेवा IP: यह क्या नहीं करती

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

हर नोड पर वही पता क्यों काम करता है

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

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

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

इसे लूपबैक पर दें, सुरंग पर नहीं

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

lo पर पता होना फ़िल्टर नहीं है। सेवा को अब भी उस पर सुनना होता है, और होस्ट का फ़ायरवॉल अब भी वास्तविक आने वाले मार्ग का मूल्यांकन करता है, जो सुरंग इंटरफ़ेस पर आता है। जो मानता है कि लूपबैक का अर्थ केवल स्थानीय है, वह अंत में या तो वैध क्लाइंट्स को अवरुद्ध करता है या ऐसा कुछ उजागर कर देता है जो उसका इरादा नहीं था।

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

ip address show dev lo | grep 10.250.0.1
ip address add 10.250.0.1/32 dev lo

एक रूट धकेलें और एक ही गंतव्य का अर्थ रखें

क्लाइंट को पते के लिए होस्ट रूट चाहिए, जो वह सर्वर देता है जिससे वह जुड़ता है। चूँकि हर सर्वर वही गंतव्य देता है, क्लाइंट के खिसकने पर प्रोफ़ाइल नहीं बदलती।

सेवा को दोष देने से पहले जाँचें कि क्लाइंट ने क्या स्थापित किया।

ip route get 10.250.0.1

HTTP सेवा के लिए पते को एक नाम दें और उस नाम के लिए प्रमाणपत्र दें। साझा IP कोई पहचान नहीं है, और यह TLS सत्यापन नहीं हटाता, और यह एक निजी कुंजी हर नोड पर नकल करने को उचित नहीं ठहराता। साझा पते पर हल होने वाला नाम प्रमाणपत्र की कहानी सामान्य रखता है और ज़रूरत होने पर आपको प्रति-नोड पहचान रखने देता है।

साझा पता क्या नहीं कर सकता

यह फेलओवर नहीं देता। यदि चुना गया नोड मर जाता है, तो पता उसके साथ मर जाता है, और क्लाइंट को कहीं और फिर से जुड़ना पड़ता है।

यह जीवित TCP सत्र को स्थानांतरित नहीं करता, क्योंकि नया कनेक्शन किसी दूसरे होस्ट पर समाप्त होता है जिसे पुराने का कोई ज्ञान नहीं है।

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

सेवा की पहचान नाम के साथ रखें

लिखें कि पते का क्या अर्थ है: यह उस नोड पर सेवा तक पहुँचता है जिससे क्लाइंट अभी जुड़ा है। वह एक वाक्य इस पैटर्न के साथ आने वाली अधिकांश ग़लतफ़हमी को रोक देता है।

फिर टुकड़ों को साथ में प्रलेखित करें: पता, जिस इंटरफ़ेस पर वह रहता है, वह रूट जो सर्वर धकेलता है, और वह नाम व प्रमाणपत्र जो सेवा प्रस्तुत करती है। चार छोटे तथ्य जिन्हें भविष्य का पाठक सत्यापित कर सकता है, उसी क्रम में जिसमें वह उन्हें जाँचेगा।

यदि आवश्यकता नोड-स्थानीय सेवा के लिए स्थिर गंतव्य है, तो यह पैटर्न उपयुक्त है और लगभग कुछ भी खर्च नहीं करता।

यदि आवश्यकता उपलब्धता है, तो एक स्तर ऊपर जाएँ: लोड बैलेंसर, स्वास्थ्य जाँच वाला सेवा नाम, या ऐसा ऑर्केस्ट्रेशन सिस्टम जिसे नोड बदलना पहले से आता है।

इसे जल्दी तय करना साझा पते को वही रखता है जो वह है, एक सुविधाजनक लेबल, न कि ऐसा घटक जिससे चुपचाप वह काम अपेक्षित हो जिसके लिए उसे कभी बनाया ही नहीं गया।