IPsec सुरक्षा नीति किन रुट तालिकाको प्रविष्टि होइन

टनेलबाट 10.20.0.5 मा ping गर्नुहोस् र केही फर्केर आउँदैन, जबकि रुट तालिकाले त्यो सबनेट पुग्न सकिने दाबी गर्छ। रुटिङ र IPsec फरक प्रश्नको उत्तर दिन्छन्, र तीमध्ये एउटा मात्र पुग्ने क्षमताबारे हो। फर्वार्ड लुकअपले बाटो छान्छ, त्यसपछि सुरक्षा नीति डेटाबेसले त्यो बाटो संरक्षित गर्नुपर्ने, त्यसै गरी छोड्नुपर्ने वा अस्वीकार गर्नुपर्ने निर्णय गर्छ। दुवै नमिल्दा प्याकेट चुपचाप मर्छ, त्यसैले तिनीहरूलाई त्यही क्रममा पढ्नुहोस्।

तालिकाबाट होइन, लुकअपबाट सुरु गर्नुहोस्

कर्नेललाई सोध्नुहोस् यो वास्तवमा के गर्छ: ip route get 10.20.0.5 ले छानिएको रुट, बाहिर जाने इन्टरफेस र प्रयोग गर्ने स्रोत ठेगाना देखाउँछ। प्रिफिक्स, नीति नियम, मार्क वा रुचाइएको स्रोतले त्यो उत्तर बदल्न सक्छन्, त्यसैले जीवित लुकअप आँखाले तालिका पढ्नुभन्दा राम्रो हुन्छ।

संरक्षित दायराभित्रको गन्तव्य परीक्षण गर्नुहोस्, गेटवे ठेगाना होइन। पारिको गेटवेसम्म पुग्नुले कुनै रुट छ भन्ने मात्र प्रमाणित गर्छ; तपाईंलाई वास्तवमै चाहिने सबनेटबारे यसले केही भन्दैन। त्यसपछि लुकअपले छानेको इन्टरफेस टनेलले प्रयोग गर्ने भनी तपाईंले अपेक्षा गरेको हो कि होइन भनी पुष्टि गर्नुहोस्।

दुवैतर्फ चयनकर्ता मिलाउनुहोस्

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

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

नीति मिल्नु भनेको स्थापित अवस्था होइन

मिल्ने नीतिले प्याकेट संरक्षित हुनुपर्छ भन्ने मात्र भन्छ; संरक्षण गर्न कर्नेललाई अझै सुरक्षा एसोसिएसन चाहिन्छ। तिनीहरूलाई ip xfrm state ले सूचीबद्ध गर्नुहोस्, वा strongSwan ले वार्ता गर्दा swanctl --list-sas ले, र प्रत्येक प्रविष्टिका चयनकर्ता र काउन्टर पढ्नुहोस्।

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

रुट-आधारित टनेललाई अझै के चाहिन्छ

XFRM इन्टरफेसले टनेललाई तपाईंले रुट गर्न सक्ने उपकरणजस्तो देखाउँछ, जो साँच्चै उपयोगी छ। तर प्याकेट त्यहाँ पुगेपछि के हुन्छ भन्ने निर्णय गर्ने नीति र अवस्था यसले हटाउँदैन। रुटले अर्को हप मात्र दिन्छ, त्यसभन्दा बढी होइन।

उपकरण छ र रुट त्यसतर्फ देखाउँछ तर कुनै एसोसिएसन भित्री चयनकर्तासँग मिल्दैन भने, प्याकेट त्यागिन्छ, र जतिसुकै रुट सम्पादन गरे पनि कुञ्जी वा चयनकर्ता उत्पन्न हुँदैन। तपाईंले रुट गरेको त्यही स्रोत र गन्तव्यसँग इन्टरफेस जाँच्नुहोस्, त्यसपछि त्यसलाई अवस्था सूचीसँग तुलना गर्नुहोस्।

केही सम्पादन गर्नुअघि स्वामित्व स्पष्ट पार्नुहोस्

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

कन्फिगरेसनको स्वामित्वले तपाईंको सुधार पुनःसुरुवातपछि टिक्छ कि टिक्दैन निर्धारण गर्छ। एउटा घटकले अवस्था स्थापित गर्न सक्छ भने अर्कोले रुट व्यवस्थापन गर्छ, र दोस्रोमा हातले गरिएको सम्पादन टनेल अर्को पटक उठ्दा अधिलेखन हुन्छ। मालिक कन्फिगरेसन बदल्नुहोस्, त्यसपछि दुवै दृश्य फेरि पढ्नुहोस्; RFC 4301 यो विभाजन अरूलाई बुझाउनुपर्दा दुवै डेटाबेस अलग राख्छ।