धेरै सबनेट भएको IPsec फिर्ती ट्राफिक गुमाउँदै छ? reqid गन्नुहोस्

ट्राफिक एउटा साइट छोड्छ र कहिल्यै फर्कंदैन, दुवै गेटवेले पूरा भएको वार्तालापको रिपोर्ट गर्छन्, र एक मात्र सुराग जवाफ नभएका बाहिर जाने प्याकेटको थुप्रो हो। Linux इन्डपोइन्टमा सामान्य कारण इन्क्रिप्शनको बल, MTU वा राउटिङ तालिका होइन। यो नीति प्रविष्टिहरूको सूक्ष्मता र प्रत्येक नीतिलाई सुरक्षा सम्बन्धसँग जोड्ने संख्या हो। तलको प्रक्रियाले अरू केही छुनुअघि ती दुई डेटाबेस पढ्छ।

केही बदल्नुअघि लक्षण अलग गर्नुहोस्

पूरा भएको IKE वार्तालापसँगको एकतर्फी असफलताले समस्या डेटा मार्गमा सीमित गर्छ। कि त बाहिर जाने नीति मिल्यो र जवाफ फ्याँकियो, कि जवाफ कहिल्यै पुगेन किनकि अर्को पक्षसँग त्यो पठाउने केही थिएन। कुनै एप्लिकेसनबाट दुवै एउटै देखिन्छन्, र xfrm डेटाबेसले तिनलाई छुट्याउँछन्।

MTU बाट सुरु नगर्नुहोस्। गलत MTU ले रोकावट र खण्डनका लक्षण उत्पन्न गर्छ, बढ्दो बाहिर जाने काउन्टरसहित सफा दिशा विभाजन होइन।

नीति डेटाबेस र अवस्था डेटाबेस पढ्नुहोस्

Linux मा इन्क्रिप्शन नीति प्रविष्टिले निर्धारण गर्छ, त्यसैले मिल्ने नीति, मार्ग होइन, प्याकेटलाई सुरुङमा हाल्छ। ip xfrm policy चलाउनुहोस् ताकि प्रत्येक प्रविष्टिको चयनकर्ता, दिशा, प्राथमिकता र टेम्प्लेट देखियोस्, र ip xfrm state ताकि स्थापित सम्बन्धहरू तिनका reqid सहित देखियोस्। नीति र सम्बन्ध त्यही reqid ले जोडिन्छ।

तीनै दिशा हेर्नुहोस्। बाहिर जाने र भित्र आउनेले यो होस्टतर्फ र यहाँबाट ट्राफिक समेट्छ; अगाडि पठाउने दिशा तब महत्त्वपूर्ण हुन्छ जब होस्टले अरूका लागि राउट गर्छ। एउटा दिशामा हराएको वा नमिलेको प्रविष्टिले कुनै पनि क्रिप्टोग्राफिक दोषबिना एकतर्फी नतिजा व्याख्या गर्छ।

शास्त्रीय असमानता: धेरै सबनेटका लागि एउटा reqid

सामान्य असफलता त्यस्तो साथीबाट आउँछ जसले सबै तय भएका सबनेटका नीति एउटै reqid मुनि स्थापित गर्छ, जो racoon को generate_policy require सँग हुन्छ। ट्राफिक त्यसपछि अन्तिममा स्थापित सम्बन्धबाट बाहिर जान्छ, जबकि अर्को पक्षले प्रत्येक सबनेटका लागि छुट्टै सम्बन्ध राख्छ। जवाफहरू त्यस्तो सम्बन्धमा आउँछन् जसको reqid ले तिनलाई स्वीकार गर्नुपर्ने नीति देखाउँदैन, र कर्नेलले डिक्रिप्सनपछि तिनलाई फ्याँक्छ।

सुधार विन्यास परिवर्तन हो, फायरवाल नियम होइन: generate_policy unique; ले प्रत्येक नीतिलाई आफ्नै reqid दिन्छ, ताकि साथीका प्रति-नीति सम्बन्धका मिल्ने साझेदार हुन्छन्। यो लागू गर्नुहोस्, फेरि वार्तालाप गर्नुहोस्, र सफलता घोषणा गर्नुअघि अपेक्षित सबनेटका फरक reqid गन्नुहोस्।

यदि दुई सबनेटले अझै एउटा reqid साझा गर्छन् र अर्को पक्षले दुई अपेक्षा गर्छ, तपाईंले असमानता भेट्नुभयो। म्यापिङ लेख्नुहोस्, किनकि अर्को परिवर्तनले त्यसलाई सुधार्यो वा कायम राख्यो भन्ने प्रमाण यही हो।

चयनकर्ता वार्तालापबाट आउँछन्, तपाईंको विन्यासबाट होइन

संरक्षित दायराहरू दुवै टुप्पाले सहमति जनाएका हुन्, एउटा पक्षले मागेका होइनन्। जुन क्लाइन्टले फराकिलो टाढाको दायरासामु होस्ट-जोडी प्रस्ताव गर्छ उसले गेटवेको साँघुरो संस्करण पाउँछ, र क्लाइन्टले त्यसलाई फराकिलो बनाउन सक्दैन। स्थापित चयनकर्ता पढ्नुहोस्, तपाईंको स्थानीय फाइलका होइनन्।

जब लक्ष्य उल्टो हुन्छ, अर्थात् एउटा गन्तव्यलाई सुरुङबाहिर राख्नु, तब कम प्राथमिकता संख्याको बाइपास नीति थप्नुहोस् ताकि त्यसले स्वतः स्थापित प्रविष्टिलाई जितोस्। टेम्प्लेटबिना नीतिले स्पष्ट पाठलाई अनुमति दिन्छ, जसले यसलाई परिवर्तन रेकर्डका लागि जानाजानी अपवाद बनाउँछ, डिबगिङ कदम होइन।

यही क्रममा प्रमाणित गर्नुहोस्, र कसरी पछाडि हट्ने जान्नुहोस्

प्रत्येक सबनेटका लागि दुवै दिशामा नीति सूचीबद्ध गर्नुहोस्, होस्टले राउट गर्छ भने अगाडि पठाउने दिशा पनि। फरक reqid गन्नुहोस् र अपेक्षा गर्ने पक्षमा प्रति-नीति एकको पुष्टि गर्नुहोस्। स्थापित चयनकर्ताको तुलना तय भएकासँग गर्नुहोस्। कुञ्जी नवीकरणपछि प्रति-सम्बन्ध काउन्टर फेरि पढ्नुहोस्, किनकि जाँचिएको सम्बन्ध पहिले नै गइसकेको हुन सक्छ। मार्ग सबैभन्दा अन्तमा जाँच्नुहोस्, किनकि टाढाको सबनेटको हराएको मार्गले सफा नीति काउन्टरसहित समान एकतर्फी लक्षण उत्पन्न गर्छ।

साथी बदल्नुअघि दुवै xfrm आदेशको हालको आउटपुट सुरक्षित गर्नुहोस्। यदि नयाँ सेटिङले फिर्ती दिशा पुनर्स्थापित गर्दैन भने, त्यो आउटपुट पुनर्स्थापित गर्नु स्मृतिबाट सुरुङ पुनर्निर्माणभन्दा छिटो फर्कने उपाय हो, र तुलना इमानदार राख्छ।