दूसरी 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 उपकरण या क्लाइंट संस्करण बदलने पर उसे फिर जाँचें। निष्क्रिय बैकअप मार्ग चुपचाप सड़ते हैं: उस प्रविष्टि के बारे में कोई चेतावनी नहीं देता जिसे कोई उपयोग नहीं करता, उस दिन तक जब सब उस पर निर्भर होते हैं।