गळतीशिवाय राउटरवर VPN फेलओव्हर धोरण कसे तयार करावे
पसंतीचा टनेल पडल्यावर रहदारीने काय करावे हे ठरवा: बॅकअप टनेल, सामान्य WAN किंवा ब्लॉक। नंतर ते राउटरवर तयार करा आणि तपासा।
फेलओव्हरने तंतोतंत कॉन्फिगर केल्याप्रमाणे काम केले आणि तीच समस्या होती। प्राथमिक टनेल पडल्यावर राउटरने डीफॉल्ट मार्ग केबल मोडेमकडे हलवला, लॅपटॉप ब्राउझिंग करत राहिले आणि कोणीही फोन केला नाही। दोन दिवसांनंतर कुणाच्या लक्षात आले की आर्थिक सामायिक फोल्डर सहा तासांपर्यंत उघड्या इंटरनेट मार्गाने उपलब्ध होता। राउटरवरील VPN फेलओव्हर धोरण ही राउटिंगची युक्ती नाही; पसंतीचा मार्ग गेल्यावर रहदारीने काय करावे याचा तो निर्णय आहे, आणि तो निर्णय मार्ग नाहीसा होण्यापूर्वी असायला हवा।
डिटेक्टर निवडण्यापूर्वी निकाल ठरवा
सहसा टेबलावर तीन निकाल असतात: प्रभावित क्लायंट बॅकअप टनेलद्वारे पाठवणे, त्यांना सामान्य WAN वापरू देणे किंवा त्यांना पूर्णपणे ब्लॉक करणे। कोणता कोणत्या VLAN, SSID किंवा उपकरण वर्गाला लागू होतो ते लिहा। एकच सपाट “WAN वर जा” नियम हेच कारण आहे की वरील आर्थिक फोल्डर सार्वजनिक मार्गावर आला।
हे तीन परस्पर बदलण्यायोग्य नाहीत। WAN फॉलबॅक सपोर्ट डेस्कला फोनला उत्तर देत ठेवतो, पण अंतर्गत नावे स्थानिक रिझोल्व्हरसमोर उघड करतो। बॅकअप टनेल धोरण टिकवतो, पण दुसरी बाजू न स्वीकारणाऱ्या एक्झिट पत्त्यावर उतरू शकतो। ब्लॉकिंग पगार VLAN साठी बरोबर आणि टनेल कधीही न वापरलेल्या गेस्ट नेटवर्कसाठी चूक आहे।
| निकाल | कोणासाठी योग्य | काय तुटते |
|---|---|---|
| बॅकअप टनेल | धोरण टिकले पाहिजे, दूरस्थ प्रवेश आवश्यक | नवीन एक्झिट पत्ता, परतीचा मार्ग, संथ की नूतनीकरण |
| सामान्य WAN | गेस्ट किंवा फक्त सार्वजनिक रहदारी | अंतर्गत नावे, DNS आणि IPv6 उघड |
| ब्लॉक | पगार, प्रशासन, फक्त-VPN सर्व काही | वापरकर्ते सर्व प्रवेश गमावतात आणि तुम्हाला फोन करतात |
खरोखर भीती वाटणाऱ्या बिघाडाशी डिटेक्टर जुळवा
हँडशेक स्थिती, इंटरफेस स्थिती आणि वापरण्यायोग्य फॉरवर्डिंग या तीन वेगळे संकेत आहेत, आणि वापरकर्त्यासाठी फक्त शेवटचा महत्त्वाचा आहे। WireGuard पीअर अलीकडचा हँडशेक दाखवू शकतो, तर पुरवठादाराचा अपस्ट्रीम पॅकेट काळ्या भोकात टाकत असतो। OpenVPN क्लायंटने ढकललेला मार्ग सोडवला जाणे थांबल्यानंतरही “कनेक्टेड” वर बसून राहू शकतो।
pfSense वर व्यावहारिक रचना dpinger ने पोसलेला गेटवे गट आहे, जो देखरेख पत्ता तपासतो आणि हानी किंवा विलंब त्याच्या मर्यादा ओलांडल्यावर गेटवे डाउन म्हणून चिन्हांकित करतो। ती देखरेख टनेलच्या पलीकडे कशाकडे तरी वळवा, उदाहरणार्थ दूरच्या LAN मधील होस्ट किंवा त्यातून तुम्ही पोहोचता त्या सार्वजनिक पत्त्याकडे। ती टनेलच्याच पीअर पत्त्याकडे वळवणे म्हणजे आधीच जिवंत असल्याचे तुम्हाला माहीत असलेला भाग मोजणे।
बॅकअप शेवटचा उपाय राहील अशा पद्धतीने गट तयार करा
एका सपाट सदस्य यादीऐवजी स्तर वापरा। प्राथमिक स्तर 1 मध्ये, बॅकअप टनेल स्तर 2 मध्ये, WAN स्तर 3 मध्ये फक्त धोरण परवानगी देणाऱ्या VLAN साठी। pfSense मध्ये हे System > Routing > Gateway Groups अंतर्गत आहे: दोन्ही गेटवे जोडा, त्यांना वेगवेगळे स्तर द्या, Trigger Level member down plus packet loss वर ठेवा, जतन करा आणि नंतर गट इंटरफेस डीफॉल्ट म्हणून किंवा गरज असलेल्या फायरवॉल नियमांच्या Gateway फील्डमध्ये लागू करा।
pfSense 2.5 आणि त्यानंतरच्या आवृत्त्यांवरील OpenVPN क्लायंट इन्स्टन्ससाठी, इन्स्टन्सची Default Gateway सेटिंग टनेल सिस्टमचा डीफॉल्ट मार्ग बदलते की नाही हे ठरवते। नियमानुसार धोरण राउटिंग तुम्ही गृहीत धरलेला मार्ग प्रत्यक्षात स्थापित असल्यासच अपेक्षेप्रमाणे वागते। बदलानंतर Status > Gateways तपासा, टनेल स्थिती चिन्हावर विश्वास ठेवण्याऐवजी।
दोन सेटिंग्ज बहुतेक फ्लॅपिंग करतात। एक म्हणजे पुरवठादाराच्या स्वतःच्या पुनर्एकत्रणापेक्षा लहान प्रोब अंतराल। दुसरा म्हणजे प्राथमिक आणि बॅकअप स्तर सामायिक करणारा गट, त्यामुळे दोन्ही सतत पात्र राहतात। तुमचे वापरकर्ते तुमच्याऐवजी संक्रमणे जाणवण्यापूर्वी हानी व विलंब मर्यादांद्वारे हिस्टेरेसिस जोडा।
टनेलने कधीही न बाळगलेले मार्ग बंद करा
आधी DNS गळती। रिझोल्व्हर WAN वर उत्तर देत राहतो आणि तिथून पुढे पाठवतो, त्यामुळे रहदारी टनेलवर खिळलेली असतानाही नावे ISP मार्गे सोडवली जात राहतात। रिझोल्व्हरचे आउटबाउंड इंटरफेस मर्यादित करा, अंतर्गत रिझोल्व्हर क्लायंटकडे ढकला आणि फक्त-VPN VLAN वर बाकी सर्वांसाठी पोर्ट 53 ब्लॉक करा।
IPv6 ला स्वतःचा निर्णय हवा। दुहेरी स्टॅकचे LAN टनेल गमावूनही कार्यरत जागतिक IPv6 डीफॉल्ट मार्ग टिकवू शकते, त्यामुळे ब्राउझर IPv6 ला प्राधान्य देतात आणि WAN मार्गे बाहेर पडतात, तर IPv4 पूर्णपणे बंदिस्त दिसतो। एकतर IPv6 टनेलमध्ये राउट करा किंवा टनेल डाउन असताना जागतिक प्रीफिक्सची जाहिरात थांबवा। अर्धे धोरण काहीही नसण्यापेक्षा वाईट आहे, कारण ते काम करत असल्यासारखे दिसते।
मग परतीचा मार्ग। बॅकअप एक्झिट वेगळा स्रोत पत्ता वापरत असल्यास, दुसऱ्या बाजूने रहदारी कशी परत पाठवावी हे माहीत असले पाहिजे, आणि जुन्या पत्त्याशी बांधलेली प्रत्येक स्थिती आधीच मेली आहे। प्राथमिक पडल्यावर उघडे असलेले सत्र स्थलांतरित होत नाहीत; ते कालबाह्य होईपर्यंत थांबतात आणि अॅप्लिकेशन काय करावे हे ठरवते।
पडणे, फ्लॅपिंग आणि परत येण्याचा मार्ग तपासा
निरुपद्रवी रहदारी सुरू असताना प्राथमिक ओढा, नंतर चार गोष्टी वाचा: Status > Gateways गटातील सदस्यांच्या स्थितीसाठी, pfctl -ss जुन्या गेटवेवर अजूनही खिळलेल्या स्थितीसाठी, एक्झिट मार्गासाठी क्लायंटकडून traceroute, आणि कोणत्या सर्व्हरने उत्तर दिले हे पाहण्यासाठी रिझोल्व्हर क्वेरी।
आता ते फ्लॅप करा। प्राथमिक तीस सेकंद वर, तीस खाली, दोन वेळा घ्या। रहदारी प्रत्येक संक्रमणाचा पाठलाग करत असेल, तर मर्यादा खूप कडक आहेत किंवा स्तर चुकीचे आहेत। ते तुमच्या वेळापत्रकानुसार दुरुस्त करा, नाहीतर पुरवठादार ते त्याच्या वेळापत्रकानुसार करेल।
शेवटी, तुम्ही अजूनही राउटरचे व्यवस्थापन करू शकता याची खात्री करा। कन्सोल केबल, व्यवस्थापन VLAN किंवा सेल्युलर मोडेमसारखा बँडबाह्य मार्ग ठेवा। तुम्हाला बाहेर कुलूपबंद करणारी फेलओव्हर चाचणी ही अशी चाचणी आहे जी तुम्ही पूर्ण करू शकत नाही, आणि अगम्य राउटर स्वतःहून परत येऊ शकत नाही।
धोरण पूर्ण ठरवण्यापूर्वी, टर्मिनल न उघडता चार प्रश्नांची उत्तरे देता आली पाहिजेत: टनेल डाउन असताना कोणते VLAN WAN वापरू शकतात, डिटेक्टर काय पाहतो आणि किती वाट पाहतो, कोणते नाव सर्व्हर आणि IPv6 मार्ग मार्गासोबत हलतात, आणि बॅकअपही अपयशी ठरल्यास तुम्ही पुन्हा कसे आत येता। कोणतेही उत्तर “डीफॉल्ट जे होते ते” असेल, तर धोरण अजूनही राउटरचे आहे, तुमचे नाही।