IPsec की स्थिति को उसकी कुंजियाँ प्रकाशित किए बिना कैसे जाँचें

IPsec की स्थिति का डंप स्टेटस रिपोर्ट नहीं है, और उसे वैसा मानना ही वह रास्ता है जिससे कुंजी सामग्री किसी सार्वजनिक समस्या ट्रैकर में पहुँच जाती है। कर्नेल निरीक्षण के कुछ आउटपुट में वे ट्रैफ़िक कुंजियाँ होती हैं जिन्हें कर्नेल इस्तेमाल कर रहा है, साथ में पते, सिलेक्टर और काउंटर जो वाकई उपयोगी हैं। सुरक्षित आदत यह है कि पहले सारांश इकट्ठा करें और कच्ची स्थिति की ओर तभी बढ़ें जब सारांश प्रश्न का उत्तर न दे सके। अगर आपको कच्ची स्थिति देखनी ही है, तो उसे स्थानीय रूप से देखें और कुछ अधिक संकीर्ण साझा करें।

जाँच 1: क्या यह कलाकृति मशीन से निकल भी सकती है

कॉन्फ़िगरेशन फ़ाइल, निजी कुंजी, अनियंत्रित पैकेट कैप्चर और कच्चा स्थिति डंप सभी रहस्य हैं जब तक उल्टा साबित न हो। कुंजियाँ छापने वाला कमांड इस बात से सुरक्षित नहीं हो जाता कि आपने उसे निदान के लिए चलाया।

नियम एक वाक्य में कहने लायक सरल है: वह अवलोकन साझा करें जो प्रश्न का उत्तर देता है, वह मशीन-स्थिति नहीं जिसने उसे बनाया।

जाँच 2: स्थिति डंप नहीं, सारांश कमांड चुनें

strongSwan के लिए swanctl --list-sas एसोसिएशन का सारांश दिखाता है: पहचान, स्थापित चाइल्ड SA, स्थितियाँ और काउंटर। इसे कच्चे कुंजी डंप की ज़रूरत नहीं होती, और टिकट में सबसे पहले यही चिपकाया जाना चाहिए। कर्नेल की ओर, iproute2 उन संस्करणों में ip xfrm state list nokeys का समर्थन करता है जो इस विकल्प का दस्तावेज़ीकरण करते हैं, जिससे एसोसिएशन फ़ील्ड बनाए रखते हुए कुंजी सामग्री दब जाती है।

इस पर भरोसा करने से पहले स्थानीय मैनुअल में वाक्यविन्यास की पुष्टि करें, क्योंकि यह विकल्प हर रिलीज़ में मौजूद नहीं है, और इसके बिना सामान्य स्थिति सूची अलग आउटपुट वाला अलग कमांड है। पुराने बिल्ड पर ip xfrm state चलाकर यह देखना कि फ़्लैग मौजूद है या नहीं, ठीक वही गलती है जिसके बारे में यह चेकलिस्ट है।

जाँच 3: केवल वही दर्ज करें जो जाँच को चाहिए

एसोसिएशन की स्थिति, एल्गोरिदम, सिलेक्टर, टाइमस्टैम्प, दिशा और प्रासंगिक काउंटर आमतौर पर पर्याप्त होते हैं। खाता पहचान, सार्वजनिक पते और आंतरिक टोपोलॉजी अक्सर नहीं, और उन्हें नैदानिक मूल्य खोए बिना छिपाया जा सकता है।

डिफ़ॉल्ट रूप से छिपाएँ और अनुरोध पर फिर जोड़ें। आपका टिकट पढ़ने वाला एक और फ़ील्ड माँग सकता है; लेकिन चिपकाई गई कुंजी को वह अनदेखा नहीं कर सकता।

एक मध्य मार्ग है जिसे जानना चाहिए: सारांश भी संवेदनशील हो सकता है। पहचान, सहकर्मी पते और चाइल्ड SA के नाम आपकी टोपोलॉजी बताते हैं, और कुछ संगठनों में यह स्वयं सीमित जानकारी है। चिपकाने से पहले तय करें कि दर्शक कौन है, और सार्वजनिक समस्या की जगह सही पहुँच नियंत्रण वाला चैनल चुनें। सुरक्षित कमांड सुरक्षित गंतव्य के बराबर नहीं है।

जाँच 4: एक प्रयास को दोनों सिरों पर जोड़ें

एक ही कनेक्शन प्रयास के लिए क्लाइंट और गेटवे को एक ही समय पर कैप्चर करें, और सुनिश्चित करें कि आप जिस एसोसिएशन का वर्णन कर रहे हैं वही उस प्रयास ने बनाई है। पिछले प्रयास की पुरानी चाइल्ड SA को ताज़ा रूट स्नैपशॉट के साथ मिलाने से ऐसी रिपोर्ट बनती है जो भीतर से सुसंगत और पूरी तरह भ्रामक है।

एसोसिएशन को टनल से नहीं, उसके अद्वितीय पहचानकर्ताओं से पहचानें, और विफलता की दिशा लिखें। अगर लक्षण एक दिशा में ट्रैफ़िक न होना है, तो कौन सी दिशा बताएँ और एक हानिरहित परीक्षण गंतव्य जोड़ें, ताकि पाठक अनुमान लगाने के बजाय पथ पर विचार कर सके। एक दिशा में शून्य और दूसरी दिशा में बढ़ता काउंटर समस्या को किसी भी कुंजी डंप से कहीं बेहतर स्थानीयकृत करता है। टाइमस्टैम्प एक ही समय क्षेत्र में रखें और बताएँ कौन सा।

जाँच 5: अगर सामग्री पहले ही उजागर हो चुकी है तो क्या करें

अटैचमेंट हटाना यह साबित नहीं करता कि किसी ने उसे रखा नहीं, और सार्वजनिक पेस्ट जल्दी कॉपी हो जाता है।

इसे घटना मानें और ऑपरेटर की प्रतिस्थापन प्रक्रिया अपनाएँ: प्रभावित कुंजियाँ या क्रेडेंशियल बदलें, देखें कि क्या उजागर होना व्यापक समझौते का संकेत है, और जो भी सूचना मार्ग लागू हो उसका पालन करें। तकनीकी सफ़ाई आसान हिस्सा है; यह मान लेना कि किसी ने उसे पढ़ा नहीं, कठिन हिस्सा है।

टिकाऊ अभ्यास एक छोटा टेम्पलेट है जिसे आप चिपकाने से पहले भरते हैं: कौन सा सिरा, कौन सा एसोसिएशन पहचानकर्ता, कौन सी दिशा, कौन सा काउंटर और क्या पहले ही बाहर रखा गया है। swanctl list-sas का दस्तावेज़ सारांश फ़ील्ड का वर्णन करता है, और ज़्यादातर टिकटों को असल में यही चाहिए। बाकी सब कुछ जिसे ज़रूरत है उसके अनुरोध पर उपलब्ध है। नैदानिक रिपोर्ट में साक्ष्य होने चाहिए, पहुँच नहीं।