DPD के जवाब साबित करते हैं कि IKE पीयर ज़िंदा है, यह नहीं कि आपका डेटा बह रहा है
लाइवनेस जवाब, एक पैडिंग सूचना और सिकुड़े हुए सिलेक्टर तीन अलग चीज़ें बताते हैं। किसी रुकावट के लिए एक को दोष देने से पहले उन्हें अलग-अलग पढ़ें।
IPsec लॉग उनके सामने की एप्लिकेशन के अटके रहने के दौरान भी लाइवनेस जवाब दिखा सकते हैं, और दोनों तथ्य एक साथ सच हो सकते हैं। DPD जवाब साबित करता है कि पीयर की IKE प्रोसेसिंग ने उस पल जवाब दिया; यह इस बारे में कुछ नहीं कहता कि चाइल्ड SA वह पैकेट ले जा रहा है या नहीं जो आपके लिए मायने रखता है। किसी खराबी के पास के हर चेतावनी को उसका कारण मानना वह तरीका है जिससे सिलेक्टर की समस्या प्रोटोकॉल बग के रूप में निदान हो जाती है। तीन अवलोकन सबसे ज़्यादा उलझाए जाते हैं, और वे तीन अलग सवालों का जवाब देते हैं। टाइमस्टैम्प से पढ़ने से पहले उन्हें संबंध और उद्देश्य से पढ़ें।
हर अवलोकन क्या साबित करता है
तालिका यह अलग करती है कि हर अवलोकन क्या स्थापित करता है और वह केवल किसके साथ आता है।
| Observation | What it establishes | What it leaves open |
|---|---|---|
| DPD replies arrive | The peer's IKE process answered | The child SA, forwarding path and application reply |
| TFC padding notification | The peer will not accept padding for that child SA | Whether ordinary ESP protection still works, which it does |
| Selectors reported as narrowed | The accepted traffic set is a subset of the offer | Whether the subset includes the flow the user needs |
तीनों में से कोई भी अपने आप में गलती नहीं है। हर एक केवल उस प्रवाह के पास दिलचस्प होता है जिसे आप डीबग कर रहे हैं, और जो पंक्ति किसी विशिष्ट प्रवाह से नहीं जुड़ सकती वह सबूत नहीं, संदर्भ है।
लाइवनेस डेटा का स्वास्थ्य नहीं है
DPD INFORMATIONAL विनिमय के रूप में चलता है, IKE डेमन के बीच नियंत्रण-तल की बातचीत। जवाब साबित करता है कि पीयर की IKE प्रक्रिया पहुँच योग्य है और जवाब देने को तैयार है, और टाइमआउट साबित करता है कि नहीं है। कोई भी परिणाम चाइल्ड SA, सिलेक्टर, अग्रेषण पथ या एप्लिकेशन के जवाब की जाँच नहीं करता, इसलिए अटके ट्रांसफर के साथ स्वस्थ DPD एक सुसंगत तस्वीर है, विरोधाभास नहीं।
इसलिए लॉग के शीर्ष पर कितना भी भरोसा दिलाती दिखें, लाइवनेस पंक्तियाँ डेटा-तल टिकट का सबसे कम उपयोगी हिस्सा हैं।
पैडिंग सूचना पैडिंग के बारे में एक कथन है
TFC पैडिंग इन लॉग में सबसे ज़्यादा गलत पढ़ी जाने वाली पंक्ति है। यह कहती है कि ट्रैफ़िक-प्रवाह-गोपनीयता पैडिंग उस चाइल्ड SA के लिए स्वीकार नहीं की जाएगी, जो ESP सुरक्षा के अस्वीकार होने के बजाय एक वैकल्पिक पैडिंग सुविधा के बारे में कथन है। इसे किसी विफलता के पास पाना आमतौर पर शब्दबहुलता का संयोग है, और पैडिंग चालू या बंद करने से सिलेक्टर कवरेज में कुछ नहीं बदलता।
IKEv2 विनिर्देश सूचना और सिलेक्टर वार्ता दोनों को परिभाषित करता है, और किसी कार्यान्वयन का चेतावनी लेबल दोनों में से किसी भी स्थिति में प्रोटोकॉल के अर्थ का स्थान नहीं लेता।
सिकुड़न ज़्यादा शांत है और इसके मायने रखने की संभावना अधिक है
प्रत्युत्तरकर्ता प्रस्तावित सिलेक्टर का एक उपसमुच्चय स्वीकार कर सकता है, और स्वीकृत समुच्चय कई प्रविष्टियों में छप सकता है, एक पोर्ट-योग्य और दूसरा सभी पोर्ट को कवर करता हुआ। केवल पहली पोर्ट-योग्य पंक्ति पढ़ना स्वीकृत को कम आँकता है; केवल चौड़ी पंक्ति पढ़ना उसे अधिक आँकता है। छपे हुए प्रस्ताव की तुलना स्थापित नीति से करें, क्योंकि प्रस्ताव वह है जो पीयर ने कहा और नीति वह है जिसे कर्नेल मिलाएगा। जब वे मेल नहीं खाते, टनल मौजूद है और ट्रैफ़िक नहीं, जो क्लासिक रुक-रुक कर आने वाली शिकायत है। पीयर की तुलना करते समय स्थानीय और दूरस्थ दृष्टिकोण को उलट दें, क्योंकि हर पक्ष का स्थानीय दूसरे का दूरस्थ है।
पोर्ट प्रतिबंध वाली होस्ट-विशिष्ट प्रविष्टियाँ दो बार पढ़ने योग्य हैं, क्योंकि वही ICMP या दूसरे पोर्ट को बाहर रखती हैं जबकि गेटवे तक पिंग काम करता रहता है।
विफल हो रहे प्रवाह के लिए एक रिकॉर्ड बनाएँ
स्रोत, गंतव्य, पता परिवार, प्रोटोकॉल और पोर्ट को उसी रूप में दर्ज करें जैसे वे सुरक्षा निर्णय पर दिखते हैं, जिसमें कोई भी जानबूझकर किया गया अनुवाद शामिल है। ये वही मान हैं जिन्हें सिलेक्टर से मेल खाना चाहिए, और ये वही मान हैं जिन्हें लोग स्मृति से फिर टाइप करते हैं जब टिकट तीसरे हाथों तक पहुँचता है।
फिर चाइल्ड SA और उसके दिशात्मक काउंटर पहचानें: swanctl --list-sas strongSwan होस्ट पर संबद्धता का सारांश देता है, और ip -s xfrm state काउंटर देता है। उन्हें ताज़ा अनुमत अनुरोध के बाद पढ़ें, सिस्टम के निष्क्रिय रहने के दौरान नहीं। आउटबाउंड में कोई वृद्धि न होना चयन या स्थानीय पथ की ओर इशारा करता है; बिना संगत इनबाउंड के आउटबाउंड पीयर, उसके अग्रेषण या उसके जवाबों की ओर इशारा करता है।
पूरा हुआ एप्लिकेशन विनिमय किसी भी काउंटर से ऊपर है, इसलिए परीक्षण टनल संकेतक पर नहीं, एप्लिकेशन पर समाप्त होना चाहिए।
उसके बाद सुधार चुनें
केवल जब वह रिकॉर्ड मौजूद हो तभी चुनने के लिए सुधार होता है: स्वीकृत सिलेक्टर, रूट, फ़िल्टरिंग, पीयर कार्यान्वयन, या कोई सीमा जो आपने अभी प्रदर्शित की है। पीयर को रीसेट करना एक साथ कई स्थितियाँ बदलता है और अक्सर यह बताए बिना ट्रैफ़िक बहाल कर देता है कि कौन-सी गलत थी, इसलिए खराबी लौट आती है। कर्नेल स्टेट डंप टिकट से बाहर रखें, क्योंकि उनमें कुंजियाँ हो सकती हैं और संक्षिप्त सारांश मदद करने वाले किसी भी व्यक्ति के लिए पर्याप्त है।
जब रिकॉर्ड आपके पहले सिद्धांत का खंडन करे, तो रिकॉर्ड पर विश्वास करें और सिद्धांत फिर से लिखें; यह आदत यहाँ चर्चा की गई किसी भी एकल लॉग पंक्ति से अधिक मूल्यवान है।