IPsec की चाइल्ड SA चालू है, पर उसके पैकेट काउंटर शून्य ही रहते हैं

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

शून्य काउंटर वास्तव में क्या सिद्ध करता है

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

यह अंतर बदलता है कि आप पहले क्या जाँचें। अस्वीकृत प्रस्ताव, प्रमाणीकरण की विफलता या मरती IKE SA सब लॉग में या SA सूची में दिखते हैं, शांत शून्य के रूप में नहीं। जो टनल साफ़-सुथरे ढंग से बातचीत करके फिर निष्क्रिय रह जाती है, वह इसके बजाय मिलान, रूटिंग या परीक्षण ट्रैफ़िक के उद्गम की ओर संकेत करती है।

वह प्रवाह भेजें जिसका वर्णन आप भेजने से पहले कर सकें

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

स्रोत पता वह मान है जिसे लोग छोड़ देते हैं, और यही परीक्षण को सबसे अधिक तोड़ता है। वायर्ड पता, Wi-Fi पता और टनल पता वाला लैपटॉप रूट लुकअप के आधार पर इनमें से कोई भी बाँध सकता है, और केवल एक ही सहमत श्रेणी के भीतर हो सकता है। ऐसा औज़ार इस्तेमाल करें जो स्रोत को पिन करने दे, जैसे ping -I 10.1.0.5 10.2.0.9 या curl --interface 10.1.0.5, ताकि पैकेट चुपचाप दूसरा पता न चुन सके। जब पिन किया रन काउंटर हिलाता है और बिना पिन वाला नहीं, तो आपने रूटिंग समस्या पाई है, IPsec समस्या नहीं।

कौन-सी संख्याएँ पढ़ें, और वे कहाँ रहती हैं

Linux पर ip -s xfrm state हर साहचर्य को lifetime current: पंक्ति के साथ छापता है जिसका कुल बाइट और पैकेट योग केवल उसी SA का है, उसके बाद रीप्ले और त्रुटि काउंटरों के लिए stats: पंक्ति आती है। strongSwan साथी पर swanctl --list-sas हर स्थापित चाइल्ड के लिए एक in पंक्ति और एक out पंक्ति दिखाता है, हर एक बाइट गणना और पैकेट गणना पर समाप्त होती है; पुराने stroke औज़ार उसी जोड़े को bytes_i और bytes_o कहते हैं। दोनों दिशाएँ अलग-अलग पढ़ें, क्योंकि जो दिशा सपाट रही वही निष्कर्ष है। दोनों को जोड़ देने से ठीक वही असमानता छिप जाती है जिसे आप खोज रहे हैं।

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

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

रूट, सिलेक्टर और पैकेट कहाँ पैदा हुआ

तीन चीज़ों की साथ-साथ तुलना करें: वह रूट जो कर्नेल आपके गंतव्य के लिए चुनता है, वह नीति जो ट्रैफ़िक को टनल में ले जाती है, और वह सिलेक्टर जोड़ा जिस पर चाइल्ड सहमत हुआ। ip route get 10.2.0.9 from 10.1.0.5 उस इंटरफ़ेस और स्रोत का नाम बताता है जो कर्नेल इस्तेमाल करता, और अक्सर वह वही जोड़ा नहीं होता जिसकी आपने कल्पना की थी। ip xfrm policy स्थानीय रूप से स्थापित टेम्पलेट और सिलेक्टर दिखाता है, जबकि swanctl --list-sas दिखाता है कि साथी किस पर सहमत हुआ। जो लुकअप पैकेट को भौतिक इंटरफ़ेस से बाहर भेजता है वह नीति तक पहुँचता ही नहीं, इसलिए काउंटर हिल नहीं सकते।

बेमेल कई रूपों में आते हैं जो काउंटर से एक जैसे दिखते हैं। IPv4 सिलेक्टर के बाहर IPv6 गंतव्य, गलत सबनेट से स्रोत पता, और चाइल्ड से सँकरा मार्ग सभी वही शून्य पैदा करते हैं। पहले सबसे सँकरे कारण को ठीक करें, क्योंकि केवल संख्या हिलाने के लिए सिलेक्टर चौड़ा करना वह बदल देता है जिसकी रक्षा टनल करता है।

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

एक प्रतिवर्ती बदलाव और ऐसी रिपोर्ट जो समीक्षा में टिके

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

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