ASA वर failback: मार्ग परत आल्यावर प्रत्यक्षात काय हलते
मार्ग प्राथमिकाकडे परत आला म्हणजे जुने प्रवाह हलले असे नाही. uplink, टनेल, कनेक्शन तक्ता आणि अ‍ॅपचा निकाल एकत्र पाहा.
दोन uplink असलेल्या ASA वर failback हा failover चा उलट नाही. peer कडे जाणारा मार्ग बदलतो, आणि नंतर प्लॅटफॉर्मला तीन वेगळ्या स्थिती यंत्रणा जुळवाव्या लागतात: मार्ग तक्ता, IKE आणि IPsec सुरक्षा सहयोग, आणि कनेक्शन तक्ता. प्रत्येक इतरांपेक्षा मागे राहू शकते, आणि तोच उशीर बहुतेक लोक परत न येणारी टनेल म्हणून वर्णन करतात.
failback प्रत्यक्षात काय बदलते
मार्ग शोध हा दिसणारा भाग आहे. निरीक्षित ऑब्जेक्ट सुधारल्यावर peer च्या बाह्य पत्त्याकडे जाणारा निरीक्षित मार्ग परत येतो, आणि 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 आणि peer चा पत्ता तरंगू न देता स्थिर ठेवणाऱ्या रचनांचा युक्तिवाद आहे.
crypto-map आणि VTI रचना येथे वेगळ्या पद्धतीने वागतात, आणि Cisco चे 9.24 VTI दस्तऐवज मार्ग-आधारित पर्यायाचे वर्णन करते. ASA मार्ग-आधारित VPN चालवू शकत नाही हे जुने सर्वसाधारण विधान समर्थित आवृत्त्यांसाठी लागू होत नाही.
पुरावे या क्रमाने वाचा
नियंत्रण स्तरापासून सुरुवात करा: निवडलेल्या मार्गासाठी show route, दुव्याच्या स्थितीसाठी show interface, आणि निरीक्षित ऑब्जेक्टसाठी SLA मॉनिटरचे काउंटर. नंतर कोणता peer जिवंत आहे हे पाहण्यासाठी show crypto ikev2 sa, किंवा IKEv1 चे समतुल्य वाचा, त्यानंतर संरक्षित प्रवाहांसाठी show crypto ipsec sa. त्यानंतर show conn address <host> ने कनेक्शन तक्ता अरुंद करा आणि जुन्या व नव्या नोंदींमधील इंटरफेस स्तंभाची तुलना करा. आउटपुट वेळेच्या ठसांसह लिहून ठेवा, कारण त्यांचा क्रम हेच निदान आहे.
अ‍ॅप्लिकेशन चाचणीने पूर्ण करा: आधीपासून असलेला एक प्रवाह आणि मार्ग परत आल्यानंतर तयार झालेला दुसरा. जुना प्रवाह अयशस्वी झाला आणि नवा चालला, तर तुमच्याकडे कनेक्शन-स्थितीची कथा आहे. दोन्ही अयशस्वी झाले तर टनेल किंवा धोरण चुकीचे आहे आणि कनेक्शन तक्ता लक्ष विचलित करणारा आहे.
ती नोंद तीनही टप्प्यांत एकाच स्वरूपात ठेवा आणि अचूक आवृत्ती नोंदवा. कालरेषा सतत एकाच बदलाकडे निर्देश करत राहिल्यास बग ID चा अंदाज लावण्याऐवजी नोंद सपोर्टला पाठवा.