ASA पर failback: रूट लौटने पर वास्तव में क्या हिलता है
रूट का प्राथमिक पर लौटना यह नहीं दर्शाता कि पुराने फ़्लो हट गए। uplink, टनल, कनेक्शन तालिका और ऐप का परिणाम एक साथ देखें।
दो uplink वाले ASA पर failback, failover का उलटा नहीं है। पीयर की ओर रूट बदलता है, और इसके बाद प्लेटफ़ॉर्म को तीन अलग स्टेट मशीनों को मिलाना पड़ता है: रूट तालिका, IKE और IPsec सुरक्षा एसोसिएशन, और कनेक्शन तालिका। इनमें से हर एक दूसरों से पीछे रह सकता है, और यही देरी वह चीज़ है जिसे ज़्यादातर लोग ऐसी टनल कहते हैं जो वापस नहीं आती।
failback वास्तव में क्या बदलता है
रूट लुकअप दिखने वाला हिस्सा है। जब ट्रैक किया गया ऑब्जेक्ट ठीक होता है, पीयर के बाहरी पते तक का ट्रैक किया गया रूट लौट आता है, और ASA जो अगला पैकेट भेजता है वह फिर प्राथमिक लिंक से जाता है। उसके बाद सब कुछ इस पर निर्भर है कि मौजूदा स्थिति नए पथ से मेल खाती है या नहीं।
ARP और NAT शांत निर्भरताएँ हैं। नए next hop को हल हो सकने वाला गेटवे और ऐसा अनुवाद चाहिए जो अब भी दूर के छोर से मेल खाए, वरना failback के बाद के पहले पैकेट कहीं नहीं जाते और रूट ठीक दिखता है जबकि कुछ भी काम नहीं करता।
एक ही समयरेखा पर चार दृष्टिकोण
वही चार चीज़ें बदलाव से पहले, उसके दौरान और बाद में दर्ज करें, क्योंकि एक स्नैपशॉट यह नहीं बता सकता कि कौन-सी परत हिली।
| View | What to record |
|---|---|
| Uplink and route | Interface state, the tracked object result, the route selected for the outer peer address |
| IKE and IPsec | The live peer, IKE version, security associations, protected-traffic counters |
| Connection table | Interface and endpoint pair for old flows and for flows created after the change |
| Application | One pre-existing operation and one fresh request, each marked success, reset, stall or recovered |
जो रूट कभी नहीं बदला और जो रूट ऐसे बदला जबकि किसी पुराने कनेक्शन ने अपनी फ़ॉरवर्डिंग स्थिति रखी, दोनों एक ही शिकायत और बिल्कुल अलग साक्ष्य देते हैं।
पुराने कनेक्शन बैकअप पथ पर क्यों रहते हैं
रूट बदलने से ASA किसी फ़्लो को तोड़ता नहीं। स्थापित कनेक्शन उसी फ़ॉरवर्डिंग निर्णय को रखते हैं जिसके साथ वे बने, और प्लेटफ़ॉर्म अलग नियंत्रण देता है कि यह कितनी देर तक अनुमत है: floating-connection timeout और connection holddown। Cisco की ASA 9.24 कनेक्शन-सेटिंग्स गाइड इन्हें अलग प्रश्न मानती है, और व्यवहार ठीक वैसा ही है। एक मौजूदा फ़्लो के जीवित रहने को नियंत्रित करता है; दूसरा यह कि नए फ़्लो पसंदीदा पथ कब उपयोग कर सकते हैं।
इनमें से कोई भी बदलने से पहले अपने रिलीज़ के लिए लागू मान पढ़ें। इन्हें घटाने से वे सत्र बंद हो जाते हैं जिन्हें लोग अब भी उपयोग कर रहे हैं। इन्हें बढ़ाने से failback ऐसा लगता है जैसे हुआ ही न हो, क्योंकि नए कनेक्शन पूरे समय पुराना पथ लेते रहते हैं।
रूट लौटने से टनल फिर से कुंजी नहीं बनाती
IPsec सुरक्षा एसोसिएशन अपना बातचीत से तय जीवनकाल लेकर चलती हैं और उस रूट बदलाव से बच जाती हैं जिसने उन्हें ढोया था। इसलिए टनल failback के दौरान ऊपर बनी रह सकती है जबकि उसका बाहरी एड्रेसिंग अब उपयोग हो रहे पथ से मेल नहीं खाता; यही DPD और ऐसे डिज़ाइन के पक्ष में तर्क है जो पीयर के पते को तैरने देने के बजाय स्थिर रखते हैं।
crypto-map और VTI डिज़ाइन यहाँ अलग व्यवहार करते हैं, और Cisco का 9.24 VTI दस्तावेज़ रूट-आधारित विकल्प का वर्णन करता है। यह पुराना व्यापक दावा कि ASA रूट-आधारित VPN नहीं चला सकता, समर्थित रिलीज़ के लिए सही नहीं है।
साक्ष्य इस क्रम में पढ़ें
कंट्रोल प्लेन से शुरू करें: चुने गए पथ के लिए show route, लिंक स्थिति के लिए show interface, और ट्रैक किए गए ऑब्जेक्ट के लिए SLA मॉनिटर के काउंटर। फिर show crypto ikev2 sa, या IKEv1 के समतुल्य, पढ़कर देखें कौन-सा पीयर जीवित है, उसके बाद संरक्षित फ़्लो के लिए show crypto ipsec sa। इसके बाद show conn address <host> से कनेक्शन तालिका सीमित करें और पुरानी व नई प्रविष्टियों में इंटरफ़ेस कॉलम की तुलना करें। आउटपुट टाइमस्टैम्प के साथ लिखें, क्योंकि उनका क्रम ही निदान है।
ऐप्लिकेशन परीक्षण से समाप्त करें: एक फ़्लो जो पहले से था और एक जो रूट लौटने के बाद बना। यदि पुराना फ़्लो विफल हो और नया काम करे, तो आपके पास कनेक्शन-स्थिति की कहानी है। यदि दोनों विफल हों, तो टनल या नीति गलत है और कनेक्शन तालिका ध्यान भटकाने वाली है।
उस रिकॉर्ड को तीनों चरणों में एक ही आकार में रखें और सटीक रिलीज़ लिखें। जब समयरेखा बार-बार एक ही बदलाव की ओर इशारा करे, तब बग ID का अनुमान लगाने के बजाय रिकॉर्ड सपोर्ट को भेजें।