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 निर्देशिका ढुवानी बाँध्ने काम र निर्यात गरिएका क्लाइन्ट विकल्प वर्णन गर्छ जसमा यो टिकेको छ।