VPN फेलओव्हर: जेव्हा परतीचा मार्ग जुन्या टनेलवरच राहतो
बॅकअप टनेल तेव्हाच फेलओव्हर होतो जेव्हा उत्तरेही त्याचा वापर करतात। दोन्ही साइट्सचे रूट नोंदवा, प्रत्येक टप्पा तपासा आणि विद्यमान सत्रांचे काय होईल ते ठरवा।
बॅकअप टनेल वर येतो, प्राथमिक टनेल खाली जातो, आणि अ‍ॅप्लिकेशन अजूनही वेळमर्यादा ओलांडते। दोन्ही साइट्सवर टनेलची स्थिती निरोगी दिसते, आणि हेच गोंधळ निर्माण करते। जे फेलओव्हर विनंत्या बॅकअपवर हलवते पण उत्तरे जुन्या मार्गावर सोडते, ते फेलओव्हर नाही। खालील मार्गदर्शक फक्त हँडशेक नाही, परतीचा मार्गही तपासते।
प्रथम दोन्ही टोकांवर रूट नोंदवा; एका साइटचे दृश्य असममित मार्ग दाखवू शकत नाही। वेळेच्या दडपणाखाली सर्वात जास्त वगळला जाणारा टप्पाही हाच आहे।
चाचणीपूर्वी दोन्ही साइट्सचे रूट नोंदवा
प्रत्येक संरक्षित प्रीफिक्ससाठी प्राथमिक रूट, बॅकअप रूट आणि त्यांच्यातील निवड करणारी प्राधान्यक्रम लिहा। प्रत्येक VPN एंडपॉइंटमागील LAN गेटवे समाविष्ट करा, कारण एंडपॉइंट क्वचितच शेवटची उडी असतो।
स्थिर मेट्रिक्स, ट्रॅक केलेले रूट आणि गतिशील राउटिंग पात्रता वेगवेगळ्या प्रकारे व्यक्त करतात। तुमची रचना कोणते वापरते आणि पर्याय सक्रिय होण्यासाठी काय लागते ते जाणून घ्या। रूटच्या शेजारी अट लिहा, उदाहरणार्थ तपासणी अयशस्वी होईपर्यंत कमी मेट्रिक।
हे दोन्ही साइट्सवर करा। एका बाजूला प्राधान्य मिळून दुसऱ्या बाजूला दुर्लक्षित होणारा बॅकअप तुम्ही टाळू पाहत असलेली तीच असममिती निर्माण करतो।
प्रत्येक टप्प्यात विनंत्या आणि उत्तरे पहा
निरुपद्रवी अनुमत अ‍ॅप्लिकेशन वापरा आणि तीन टप्पे पहा: सामान्य, प्राथमिक मार्गाचा अपयश आणि पुनर्संचय। प्रत्येक टप्प्यात कोणते टनेल विनंती आणि कोणते उत्तर वाहते ते नोंदवा। पोहोचण्यायोग्य पीअर पत्ता सिद्ध करत नाही की संरक्षित अ‍ॅप्लिकेशन मार्ग कार्यरत आहे। एकमार्गी प्रवाह दिसण्यासाठी दोन्ही साइट्सवर नोंदवा।
विनंत्या हलल्या आणि उत्तरे हलली नाहीत तर दूरच्या साइटचा क्लायंट प्रीफिक्सपर्यंतचा रूट आणि बॅकअपसाठीचा त्याचा प्राधान्यक्रम तपासा। हे राउटिंग निर्णय आहे, टनेल अपयश नाही।
चाचणीनंतर मूळ स्थिती पुनर्संचयित करा आणि प्राथमिक पुन्हा प्राधान्यकृत होतो याची खात्री करा। पुनर्संचयित प्राथमिक प्राधान्यकृत न झाल्यास ती अपूर्ण फेलओव्हर रचना आहे।
गेटवे बदलल्यावर सत्र स्थिती हाताळा
फायरवॉल आणि NAT एका गेटवेवर कनेक्शन स्थिती ठेवू शकतात, आणि दुसऱ्या गेटवेवर मार्ग बदलल्यास ती सोबत जात नाही। काही अ‍ॅप्लिकेशन स्वतः पुन्हा जोडतात; इतर सत्र पुनर्स्थापित होईपर्यंत अयशस्वी होतात। बॅकअप सार्वजनिक स्रोत किंवा अनुवादित खाजगी पत्ता बदलल्यास दूरस्थ प्रवेश नियमही प्रतिक्रिया देऊ शकतात। अखंड फेलओव्हरचे वचन देण्याऐवजी अपेक्षित सत्र पुनरारंभ नोंदवा।
अ‍ॅप्लिकेशन मागणारे तिथे स्थिर पत्ता निश्चिती टिकवा। प्रत्येक सत्रासाठी स्रोत पत्ता बदलणारी फेलओव्हर रचना ही रचना-निवड आहे, आणि ती लिहून ठेवावी। ती निवड वापरकर्ते व्यत्यय किती लक्षात घेतात हे ठरवते।
केवळ नवीन विनंती नाही, दीर्घ सत्र ठेवणारे अ‍ॅप्लिकेशनही तपासा।
प्राथमिक पुनर्संचयित करा आणि फ्लॅपिंग तपासा
रूट घोषणा किंवा प्राधान्यक्रम दोलनाशिवाय स्थिर होतात याची खात्री करा। फ्लॅपिंग प्राथमिक स्पष्ट बिघाडापेक्षा जास्त त्रासदायक ठरू शकतो, कारण प्रत्येक संक्रमण स्थिती रीसेट करते।
गेटवे प्रशासन पुनर्प्राप्ती मार्गाने पोहोचण्यायोग्य ठेवा, जेणेकरून चाचणी स्वतः तुम्हाला बाहेर ठेवणार नाही। टप्पे, निरीक्षण केलेले मार्ग आणि पुनर्प्राप्ती वेळ नोंदवा; तीच नोंद पुढील फेलओव्हर अंदाजनीय करते। strongSwan च्या फॉरवर्डिंगविषयी टिपण्णी एंडपॉइंट Linux होस्ट असताना उपयुक्त असतात।