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। त्यो वाक्यले कसैले नप्रयोग गरेको एसोसिएसनलाई ट्राफिक लिएर अस्वीकार गर्ने टाढाको अनुप्रयोगबाट छुट्याउँछ। परिवर्तनले काउन्टर हल्लाएन भने फर्काउनुहोस् र अभिलेख राख्नुहोस्; अर्को व्यक्ति तपाईं रोकिएको ठाउँबाट सुरु गर्नेछ। यीमध्ये कुनैका लागि सुरुङमा केही पुनर्निर्माण गर्नुपरेन, र कन्फिगरेसन छुनुअघि मिलान जाँच्नुको अर्थ पनि त्यही हो।