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 मार्गदर्शक वाहतूक बांधणी आणि निर्यात केलेले क्लायंट पर्याय वर्णन करते ज्यांवर हे अवलंबून आहे.