दुसरे WAN VPN प्रवेश अयशस्वी होताना प्राथमिक अजूनही काम करते

प्राथमिक बोगदा सुरू राहतो, वापरकर्ते काम करत राहतात आणि तुम्ही काहीही बदलले तरी दुसरे ISP सर्किट रिकामे पडून राहते। तुम्ही बॅकअप सर्किटसाठी पत्ता प्रकाशित केला, त्यावर नाव दाखवले, कदाचित क्लायंटमध्ये बॅकअप प्रवेश जोडला, आणि क्लायंट एकतर तो कधीच वापरत नाही किंवा प्रमाणीकरण करून नंतर बंद पडतो। मी शोधलेल्या प्रकरणांमध्ये फेलओव्हर वैशिष्ट्य सहसा ठीक होते; प्रवेश वापरण्यायोग्य बनवणाऱ्या पाचपैकी एक गोष्ट गहाळ होती। त्या इंटरफेसवर काहीही ऐकत नसतानाही नाव बॅकअप पत्त्यावर रिझोल्हो होऊ शकते, आणि उत्तर प्राथमिकमधून बाहेर जात असतानाही श्रोता जोडणी स्वीकारू शकतो। प्रत्येक WAN ला स्वतःच्या करारासह वेगळा प्रवेश माना, मग अयशस्वीता क्लायंटची बग वाटणे थांबते।

प्रत्येक WAN ला स्वतःचा प्रवेश करार आवश्यक

प्रत्येक WAN साठी पाच फील्ड नोंदवा: सार्वजनिक नाव आणि पत्ता, ट्रान्सपोर्ट आणि पोर्ट, तो संपवणारा इंटरफेस किंवा संदर्भ, त्याने सादर करावयाची पीअर ओळख आणि उत्तर कुठून बाहेर पडते। दोन सर्किट म्हणजे दोन पूर्ण संच। जर दुसऱ्या संचाला संपवणारा इंटरफेस नाही किंवा परतीचा मार्ग नाही, तर तुमच्याकडे बॅकअप प्रवेश नाही; तुमच्याकडे हेतू वर्णन करणारा DNS रेकॉर्ड आहे।

उपकरण आणि त्याची आवृत्तीही ही रचना समर्थावी लागते। DNS रेकॉर्ड दुसऱ्या इंटरफेसवर सेवा उघडू शकत नाही, आणि अनेक प्लॅटफॉर्मवर श्रोता उपकरणानुसार नाही तर पत्त्यानुसार कॉन्फिगर केला जातो। ASA वर इंटरफेस-आधारित IPsec क्रिप्टो मॅप आणि बोगदा गट बाहेरील इंटरफेशी जोडतो, त्यामुळे दुसऱ्या अपलिंकला ते पॅकेट प्रत्यक्ष येणाऱ्या ठिकाणी धोरण लागते। रूट-आधारित रचना वेगळे वागतात: श्रोता प्रत्येक पत्त्यावर किंवा एका नामित पत्त्यावर बांधला जाऊ शकतो, आणि तो निवड ISP B उत्तर देऊ शकतो की नाही हे ठरवते।

दुसरे WAN खरोखर उत्तर देते का ते तपासा

दोन्ही सर्किटच्या बाहेरून चाचणी करा, गेटवेच्या मागील मशीनवरून नाही, आणि क्लायंट प्रोफाइल वापरत असलेले नेमके नाव चाचणी करा। TLS श्रोत्यासाठी झटपट तपासणी openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts तुमच्या नेटवर्कबाहेरील होस्टवरून चालवलेली आहे। तुम्हाला पूर्ण झालेला हॅन्डशेक हवा ज्याची साखळी प्रोफाइलमधील नावाशी जुळते, केवळ जोडणी स्वीकारणारा TCP पोर्ट नाही।

RFC 9525 क्लायंट काय तपासतो हे स्पष्ट करते: त्याला पोहोचायची असलेली ओळख, सेवा सादर करणाऱ्या प्रमाणपत्राशी तुलना केलेली। प्राथमिक प्रवेशाचे प्रमाणपत्र परत देणारा दुसरा प्रवेश, किंवा दोन्हीपैकी कोणतेही नाव न दाखवणारे डीफॉल्ट प्रमाणपत्र, पोर्ट उघडा आणि फायरवॉल परवानगी देत असूनही ही चाचणी अपयशी ठरते।

इथल्या बहुतेक अयशस्वीता दोन नमुन्यांनी स्पष्ट होतात। लटकणाऱ्या जोडणीचा अर्थ सहसा त्या इंटरफेसवर श्रोता नाही, केवळ प्राथमिक सबनेटना परवानगी देणारा प्रवेश नियम, किंवा दुसऱ्या सर्किटसमोरील कॅरियर उपकरण पोर्ट टाकून देत आहे। चुकीच्या ओळखीसह संपणाऱ्या हॅन्डशेकचा अर्थ सहसा वेगळा ट्रस्टपॉइंट, डीफॉल्ट व्हर्च्युअल होस्ट, किंवा ओळख न जुळवता प्राथमिकवरून कॉपी केलेले कॉन्फिगरेशन।

उत्तराचा मागोवा घ्या, केवळ विनंतीचा नाही

दुसरे WAN सहसा परतीच्या वाटेवर बिघडते। विनंती ISP B वर येते, उपकरण उत्तर देते, आणि उत्तर ISP A वरील डीफॉल्ट मार्गाने बाहेर पडते, अशा स्रोत पत्त्यासह जो क्लायंटने कधीही मागितला नव्हता। स्टेटफुल भाषांतर ते अधिक बिघडवते: जर मॅपिंग प्राथमिक इंटरफेससाठी बनवले असेल, तर परत येणारा पॅकेट भाषांतर चुकवतो किंवा क्लायंटचा फायरवॉल फेकून देईल असा स्रोत बाळगतो। प्रदाते तुम्हाला दिलेल्या सर्किटशी संबंधित नसलेले स्रोत पत्तेही टाकून देतात, म्हणूनच हे स्वच्छ प्रोटोकॉल त्रुटीऐवजी एकतर्फी ब्लॅक होलसारखे दिसते।

दुसऱ्या प्रवेशातून स्रोत असलेल्या रहदारीसाठी मार्गनिर्णय तपासा। उत्तर विनंती आलेल्या इंटरफेसवरून बाहेर पडावे, किंवा किमान त्या मार्गाचा भाग म्हणून दूरची बाजू स्वीकारेल असा पत्ता बाळगावा। धोरण-मार्गनिर्णय प्लॅटफॉर्मवर याचा अर्थ येणाऱ्या इंटरफेसवर किंवा भाषांतरित स्रोतावर आधारित नियम, आणि प्रत्येक बाहेरील इंटरफेसला बांधलेले भाषांतर विधान। क्लायंट जोडत असताना दोन्ही इंटरफेसवर एकाच वेळी कॅप्चर करा; ISP B वर येणारा SYN आणि ISP A वरून जाणारा SYN-ACK एकाच फेरीत प्रश्न मिटवतो।

क्लायंटला दुसऱ्या प्रवेशाची माहिती मिळवण्याचा मार्ग द्या

फेलओव्हर हा क्लायंटच्या बाजूचा निर्णय आहे, आणि प्रत्येक क्लायंट कुटुंब पर्यायांबद्दल वेगळ्या पद्धतीने माहिती घेते। ASA वर बॅकअप-सर्व्हर यादी गट धोरणाच्या webvpn गुणधर्मांद्वारे पोहोचवली जाते, तर इतर क्लायंट प्रोफाइलमधील यादी किंवा वापरकर्त्याने निवडावयाचे मॅन्युअल दुसरे प्रोफाइल अपेक्षितात। Cisco चे जोडणी-धोरण मार्गदर्शक क्लायंट-कॉन्फिगर केलेली आणि गेटवे-पुरवलेली अशी दोन्ही बॅकअप माहिती वर्णन करते, आणि ती प्रोटोकॉल-विशिष्ट तपशील प्रत्येक क्लायंट किंवा बोगदा मोडवर सामान्यीकृत करू नयेत। दुसरा प्रवेश चुकीच्या एकाभोवती बांधण्यापूर्वी तैनात केलेला क्लायंट कोणती यंत्रणा लागू करतो याची पुष्टी करा।

यंत्रणा कोणतीही असो, प्राथमिक मार्ग गमावण्यापूर्वी क्लायंटला पर्यायी नाव रिझोल्हो करता आले पाहिजे। तेच अवलंबित्व लोक चुकतात: जर बॅकअप नाव नुकत्याच अयशस्वी झालेल्या बोगद्यातूनच पोहोचणाऱ्या रिझॉल्व्हरने उत्तर दिले, तर फॉलबॅक सुरूही होऊ शकत नाही। दुसरे नाव स्थानिक पातळीवर किंवा इंटरनेटवरून उत्तर देणाऱ्या रिझॉल्व्हरमध्ये प्रकाशित करा। स्थलांतरानंतर नवीन प्रमाणीकरण आणि नवीन अनुप्रयोग सत्र अपेक्षा करा, कारण क्लायंट फेलओव्हर स्टेटफुल फेलओव्हर नाही आणि दीर्घकालीन सत्रे त्यात टिकत नाहीत।

दोन प्रदात्यांवर एकच पत्ता हे वेगळे उत्पादन आहे

एकच सार्वजनिक पत्ता दोन्ही सर्किटमधून पोहोचण्यायोग्य ठेवणे ही मार्गनिर्णय सेवा आहे, VPN वरील चेकबॉक्स नाही। त्यासाठी दोन्ही प्रदाते वाहून नेण्यास तयार असलेली पत्ता जागा लागते, त्यांची नेटवर्के स्वीकारतील अशा पद्धतीने जाहीर केलेली, जी प्रदाता-स्वतंत्र जागा आणि BGP सह मल्टिहोमिंग देतो। ISP A चा पत्ता ISP B च्या इंटरफेसला देण्याने तिथे पोहोचत नाही; पॅकेट त्या नेटवर्कमध्ये पोहोचते ज्याने तो प्रिफिक्स कधीही जाहीर केला नाही आणि अपस्ट्रीममध्ये टाकून दिले जाते।

दोन प्रवेश प्रकाशित करण्यासाठी तुम्हाला यातील काहीही लागत नाही। जर क्लायंट दोन नावे ठेवू शकतो आणि त्यांच्यात फेल होऊ शकतो, तर दोन स्वतंत्र प्रवेश पुरेसे आहेत, आणि तुम्ही AS क्रमांक, पियरिंग व्यवस्था आणि सर्वत्र स्वीकारावा लागणारा प्रिफिक्स टाळता। पोर्टेबल-पत्ता पर्यायाचा विचार तेव्हाच करा जेव्हा तुम्हाला खरोखर एक स्थिर प्रवेश बिंदू हवा असतो जो क्लायंट पुन्हा कॉन्फिगर करून बदलू शकत नाहीत, किंवा जेव्हा TTL विलंबासह DNS-आधारित फेलओव्हर तुम्ही डिझाइन करत असलेल्या व्यत्ययासाठी खूप संथ आहे।

पुढे काय तपासावे

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

प्रत्येक WAN साठी पत्ता, पोर्ट, संपवणारा इंटरफेस, प्रमाणपत्र नाव, परतीचा मार्ग आणि भाषांतर नियम असलेली छोटी नोंद ठेवा, आणि सर्किट, NAT उपकरण किंवा क्लायंट आवृत्ती बदलल्यावर ती पुन्हा तपासा। निष्क्रिय बॅकअप मार्ग गुपचूप कुजतात: कोणीही न वापरलेल्या प्रवेशाबद्दल कोणताही इशारा येत नाही, ज्या दिवशी सर्वजण त्यावर अवलंबून असतात त्या दिवसापर्यंत।