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। ते वाक्य कोणीही न वापरलेल्या असोसिएशनची रहदारी घेऊन नाकारणार्या दूरच्या अॅप्लिकेशनपासून वेगळे करते। बदल काउंटर हलवत नसेल तर तो उलटवा आणि नोंद ठेवा; पुढची व्यक्ती तुम्ही थांबलेल्या जागेपासून सुरुवात करेल। यापैकी कशासाठीही बोगद्यात काही पुन्हा बांधावे लागले नाही, आणि कॉन्फिगरेशनला हात लावण्यापूर्वी जुळणी तपासण्याचा मुद्दा हाच आहे।