pfSense पर OpenVPN फ़ेलओवर के तीन प्रकार, तीन तंत्र

pfSense पर „OpenVPN failover“ कम से कम तीन असंबंधित डिज़ाइनों को समेटता है और हर एक के लिए अलग तंत्र चाहिए। बैकअप इंटरनेट लिंक पर सुरंग को जीवित रखना, किसी दूसरे सर्वर से फिर जुड़ना और LAN ट्रैफ़िक को किसी दूसरी स्थापित सुरंग में मोड़ना एक ही सुविधा के रूपांतर नहीं हैं। गेटवे समूह बनाने से पहले वह विफलता चुनें जिसके विरुद्ध आप बचाव कर रहे हैं। जो समूह उनमें से एक को ठीक करता है, वह बाकी दो के लिए कुछ नहीं करता।

समूह बनाने से पहले विफलता का नाम लें

वह वाक्य लिखें जो आप रुकावट के दौरान सत्य देखना चाहते हैं। „सुरंग बैकअप WAN से फिर जुड़ती है“ और „शाखा अब भी दूसरी सुरंग से एप्लिकेशन तक पहुँचती है“ अलग वाक्य हैं। केवल पहला ट्रांसपोर्ट के बारे में है।

फिर उसे किसी तंत्र से जोड़ें। स्थानीय WAN का नुकसान इंटरफ़ेस-चयन की समस्या है, मृत दूरस्थ छोर कनेक्शन-सूची की समस्या है, और स्थापित सुरंग के भीतर अप्रयोग्य पथ रूटिंग और नीति की समस्या है।

स्थानीय WAN: ट्रांसपोर्ट को खिसकाएँ

pfSense के OpenVPN क्लाइंट के लिए समर्थित बहु-WAN व्यवस्था उपयुक्त गेटवे समूह को वह इंटरफ़ेस चुनती है जिससे क्लाइंट बंधता है। यही बाहरी कनेक्शन को प्राथमिक के फेल होने पर बैकअप लिंक से निकलने देता है। अपने आप में यह नहीं बदलता कि भीतरी ट्रैफ़िक कैसे रूट होता है।

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

अग्रेषित LAN पैकेटों के लिए नीति-आधारित रूटिंग नियम वह सेटिंग नहीं है जो स्थानीय रूप से बनाया गया VPN ट्रांसपोर्ट कनेक्शन खिसकाती है। ये दो अलग लुकअप हैं, और एक बदलने से दूसरा नहीं बदलता।

दूरस्थ छोर: दूसरा सर्वर

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

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

यह तंत्र दो सुरंगों को एक साथ अग्रेषित भी नहीं कराता। यह एक कनेक्शन के बाद दूसरा क्रमिक रूप से रखता है, और उनके बीच का अंतराल हर उस चीज़ को दिखता है जो चल रही थी।

सुरंग का पथ: दूसरा निकास चुनें

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

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

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

मॉनिटर, NAT और fail-closed नियम

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

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

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

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