दूसरा VPN एंडपॉइंट: यह क्या कवर करता है और क्या नहीं

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

तुलना करें कि दोनों एंडपॉइंट क्या साझा करते हैं

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

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

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

तय करें कि क्लाइंट कैसे बदलता है

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

सत्र के दौरान पता परिवर्तनों पर क्लाइंट का दस्तावेज़ पढ़ें। कुछ कार्यान्वयन टनल के पूरे जीवनकाल में मूल साथी रखते हैं और केवल पुनः कनेक्ट होने पर विकल्प देखते हैं। यही अंतर तय करता है कि मृत एंडपॉइंट संक्षिप्त रुकावट देता है या ऐसा सत्र जो कभी नहीं सुधरता। होने की धारणा के बजाय पुनः कनेक्ट का रास्ता जाँचें।

बदला हुआ निकास पता एप्लिकेशन की स्थिति भी तोड़ता है। फ़ेलओवर पुनर्प्राप्ति है, और उसे निर्बाध निरंतरता कहना ऐसी अपेक्षा बनाता है जिसे ट्रांसपोर्ट पूरा नहीं कर सकता।

एक वास्तविक विफलता जाँचें

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

dig +short vpn2.example.net
ip route get 10.20.30.41
journalctl -u openvpn@backup --since '-10 min'

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

फिर मूल को वापस लाएँ और पुष्टि करें कि क्लाइंट लौटता है या नहीं। संयोग से होने वाला फ़ेलबैक ऐसा व्यवहार है जिसकी योजना किसी ने नहीं बनाई।

लिखें कि दूसरा पता क्या देता है

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

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