ASA पर peer reset IPsec SA हटाता है, IKE स्थिति या सत्र नहीं
peer तक सीमित एक clear केवल IPsec डेटा पथ को तोड़ता है। देखें क्या बचता है, टनल क्यों सेकंडों में फिर बनती है और इसके बजाय कौन-सी परत साफ़ करनी चाहिए।
टनल एक ही एप्लिकेशन के लिए गिरती है, कोई peer तक सीमित IPsec clear चलाता है, और कमांड स्वीकार होने के कारण टिकट बंद कर दिया जाता है। उस क्रम में कहीं नहीं दिखता कि खराबी ठीक हुई है। ASA पर reset शब्द तीन अलग दायरों को कवर करता है, और peer तक सीमित clear उनमें से ठीक एक को छूता है, इसीलिए वही टनल अक्सर ऑपरेटर के आउटपुट पढ़ने से पहले ही फिर ऊपर होती है।
एक शब्द के पीछे तीन दायरे छिपे हैं
IPsec SA का जोड़ा स्वयं डेटा पथ है, प्रत्येक दिशा के लिए एक संबद्धता, क्रम संख्या और काउंटर के साथ। IKE SA वह वार्ता चैनल है जिसने वे संबद्धताएँ बनाईं और अब भी peer संबंध को साथ रखता है। VPN सत्र सत्र डेटाबेस में किसी उपयोगकर्ता, साइट-से-साइट peer या क्लाइंट-रहित कनेक्शन का रिकॉर्ड है।
| Scope | What a clear removes | What usually survives |
|---|---|---|
| IPsec SA | Data-path associations for the matching peer or selector | IKE SA, session records, crypto-map or tunnel-group config |
| IKE SA | Negotiation channel and the IPsec children derived from it | Session records until they age out or are cleared |
| VPN session | Session-database entry for that user or peer type | Configuration, and any SA that is not tied to the session |
दायरे इतने स्वतंत्र हैं कि एक को साफ़ करने पर बाकी काम करते रहते हैं, और यही स्वतंत्रता अधिकांश भ्रम पैदा करती है। IKE SA स्वस्थ रहते हुए IPsec SA साफ़ करें, और ट्रैफ़िक सेकंडों में नई संबद्धताएँ बना देता है, इसलिए टनल खुद ठीक हो गई लगती है। पर प्रस्ताव का असंगत होना, रूट का अंतराल या प्रमाणीकरण की विफलता अब भी वहीं है।
यदि खराबी वार्ता में है, तो IPsec clear कोई दिखने वाली चीज़ नहीं बदलता।
स्थिति तब पढ़ें जब वह अब भी मौजूद है
कुछ भी छूने से पहले peer का पता, प्रयुक्त IKE संस्करण, सुरक्षित नेटवर्क और दिशा-वार काउंटर लिख लें। समर्थित दृश्य संस्करण के अनुसार बदलते हैं, पर आकार स्थिर हैं: show crypto ipsec sa peer, show crypto ikev2 sa detailed या IKEv1 के बराबर, और सत्र परत के लिए show vpn-sessiondb।
उस आउटपुट के बगल में टाइमस्टैम्प और उपयोगकर्ता को दिखने वाली ठीक खराबी लिखें। एक peer सामान्यतः कई सुरक्षित नेटवर्क ढोता है, इसलिए peer तक सीमित clear का प्रभाव-क्षेत्र उस peer के हर चयनकर्ता तक है, टिकट के एक एप्लिकेशन तक नहीं। पहले की तस्वीर के बिना reset का बाद में निदान नहीं हो सकता, क्योंकि clear ठीक उन्हीं काउंटरों को मिटा देता है जिनसे आप तुलना करते।
पहले साक्ष्य दर्ज करें। clear उसे हटा देता है, और बाद में लिया गया स्क्रीनशॉट बताता है कि क्या फिर बना, न कि क्या टूटा था।
peer तक सीमित clear वास्तव में क्या करता है
Cisco का clear कमांड संदर्भ peer तक सीमित IPsec रूप का दस्तावेज़ीकरण करता है। दस्तावेज़ी पता डालने पर वह ऐसा दिखता है:
clear crypto ipsec sa peer 198.51.100.42वह कमांड peer से मेल खाने वाली IPsec संबद्धताओं को तोड़ देता है। यह IKE SA नहीं हटाता, कॉन्फ़िगरेशन नहीं मिटाता और सत्र डेटाबेस को रीसेट नहीं करता। इसे ऐसे प्रबंधन पथ से चलाएँ जो उस टनल पर निर्भर न हो जिसे आप बदल रहे हैं, क्योंकि उस टनल के भीतर ले जाया गया SSH सत्र उसके साथ मर जाएगा और शायद अपने आप वापस न आए। डिवाइस पर बाकी सब चलता रहता है, और ठीक इसीलिए कमांड हानिरहित लगता है।
जब लक्ष्य की खोज अनिश्चित हो, तो बिना शर्त clear पर न लौटें। व्यापक रूप डिवाइस के हर peer तक पहुँचता है, और आप जो रुकावट पैदा करेंगे वह उससे बड़ी होगी जिसके लिए आपको बुलाया गया।
जिस परत को ठीक करना था उसे सत्यापित करें
clear के बाद पुष्टि करें कि संबद्धताएँ नए काउंटरों के साथ लौटीं, बजाय यह मानने के कि reset काम कर गया क्योंकि peer सूची फिर भर गई। फिर टिकट में बताए एप्लिकेशन की जाँच करें, क्योंकि सफल ping सेवा अनुमति या समाप्त सत्र के बारे में कुछ नहीं कहता।
यदि संबद्धताएँ फिर बनें और एप्लिकेशन अब भी विफल हो, तो बचे हुए उम्मीदवार IKE परत और सत्र परत हैं। वह चुनें जिसकी स्थिति आप अब भी देख सकते हैं। जो संस्करण वास्तव में चल रहा है उसके लिए लक्षित क्रिया का प्रयोग करें, चाहे वह IKEv2 clear हो, IKEv1 clear हो या सही सत्र प्रकार तक सीमित सत्र डेटाबेस clear हो। पुनर्निर्माण के लिए बाध्य करने हेतु स्थायी crypto-map कॉन्फ़िगरेशन मिटाकर फिर बनाना लंबे रोलबैक वाला अनुमान है।
फिर से साफ़ करने के बजाय पहले और बाद की दोनों तस्वीरों के साथ एस्केलेट करें।
जब reset रुकावट को लंबा करता है
बार-बार clear उन खराबियों को छिपाते हैं जिन्हें reset ठीक नहीं कर सकता: गुम रूट, नए सबनेट से अब न मेल खाने वाला चयनकर्ता, एक तरफ़ बदला गया पूर्व-साझा कुंजी, या ऐसे प्रस्ताव पर बार-बार विफल होने वाला कुंजी नवीनीकरण जिसे peer स्वीकार नहीं करेगा। हर clear उस peer के हर चयनकर्ता पर स्वस्थ ट्रैफ़िक बाधित करता है जबकि असली कारण अछूता रहता है। इस तरह पाँच मिनट की जाँच बदलाव विंडो में बदल जाती है।
सीमित reset अब भी उपयोगी है। उपयोगी रूप लक्षित, दर्ज और उस परत के निरीक्षण के साथ होता है जिसे उसे ठीक करना था।
कार्य क्रम: peer, संस्करण, चयनकर्ता और काउंटर दर्ज करें; खराबी किस दायरे की है यह पुष्टि करें; सबसे संकीर्ण मेल खाता clear चलाएँ; संबद्धताएँ और एप्लिकेशन सत्यापित करें; परत सुधर जाए पर लक्षण न जाए तो साक्ष्य के साथ एस्केलेट करें।