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 अनुमान गर्नुको सट्टा अभिलेख सपोर्टमा पठाउनुहोस्।