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