IPsec ESP: यसले के बोक्छ र यो बगिरहेको छ भनी कसरी प्रमाणित गर्ने
ESP ले टनेल मोडमा भित्री IP प्याकेट बेर्छ र SPI मार्फत आफ्नो एसोसिएसन पहिचान गर्छ। स्थिति पढ्नुहोस्, त्यसपछि एउटा प्रवाहले काउन्टरहरू कसरी सार्छ हेर्नुहोस्।
ESP ले IPsec VPN मा ट्राफिक बोक्छ, र यसको runbook एउटा नियमबाट सुरु हुन्छ: नीति बदल्नु अघि सुरक्षा एसोसिएसन पढ्नुहोस्। ESP को अधिकांश अस्पष्ट व्यवहार नमिलेको सिलेक्टर, पढ्नुको सट्टा अनुमान गरिएको मोड, वा एउटा प्रवाह पठाइँदै गर्दा कसैले नजाँचेको काउन्टरमा फर्कन्छ। तलका तीन चरणले केले के बोक्छ निर्धारण गर्छन्, एउटा प्रवाहले यो प्रयोग गर्छ भनी प्रमाणित गर्छन्, र स्मृतिमा निर्भर नहुने फर्काइ छोड्छन्। प्रत्येक चरणले लेख्न लायक एउटा अवलोकन दिन्छ।
पढ्नु अघि फाँटहरू चिन्नुहोस्
ESP ले सुरक्षित डेटाअघि हेडर र पछाडि ट्रेलर राख्छ। हेडरले प्राप्तकर्ताले कुन एसोसिएसन प्रयोग गर्नुपर्ने हो भनी पहिचान गर्ने सुरक्षा प्यारामिटर इन्डेक्स, पुनरावृत्ति पत्ता लगाउन क्रम नम्बर बोक्छ, र ट्रेलरमा साइफरका लागि पेलोड संरेखित राख्ने प्याडिङ हुन्छ। ट्रेलरको अर्को हेडर फाँटले सुरक्षित सामग्री के हो भन्छ, र यसरी प्राप्तकर्ताले के डिक्याप्सुलेट गर्यो भनी जान्छ।
मोडले त्यो सुरक्षाभित्र के बस्छ भन्ने बदल्छ। टनेल मोडमा सुरक्षित सामग्री पूरा भित्री IP प्याकेट हो, र नयाँ बाहिरी हेडरले यसलाई दुई छेउबीच बोक्छ। ट्रान्सपोर्ट मोडमा सुरक्षाले विद्यमान प्याकेटको माथिल्लो तहको पेलोड बेर्छ, त्यसैले खोल्न दोस्रो IP हेडर हुँदैन। कुन मोड प्रयोग भइरहेको छ भन्ने कन्फिगरेसनको तथ्य हो, व्याख्याको विषय होइन। रेखाचित्रबाट अनुमान नगरी स्थिति प्रविष्टिबाट पढ्नुहोस्।
दुवै मोडमध्ये कुनैले प्याकेट पुर्याउनुपर्ने बाहिरी ठेगाना लुकाउँदैन। यो डिजाइनको गुण हो, कमजोरी होइन, र त्यसैले पेलोड अपारदर्शी हुँदा पनि बीचको पर्यवेक्षकले कुन दुई ठेगाना बोलिरहेका छन् देख्न सक्छ।
पहिलो चरण: स्थिति पढ्नुहोस्, त्यसपछि नीति
स्थिति प्रविष्टिले कुञ्जी र काउन्टर राख्छन्; नीति प्रविष्टिले कसले प्रयोग गर्न पाउने भनी निर्धारण गर्ने सिलेक्टर राख्छन्। Linux मा दुवै प्याकेट क्याप्चरबिना देखिन्छन्, र त्यही क्रममा पढ्दा दुई प्रश्न अलग रहन्छन्।
ip xfrm state
ip xfrm policyस्थिति आउटपुटमा एसोसिएसनको स्रोत र गन्तव्य, मोड, र इन्क्याप्सुलेसनले UDP पोर्ट देखाउँछ कि भनी जाँच्नुहोस्। ती पोर्टको अर्थ NAT ट्राभर्सल प्रयोग भइरहेको छ, जसले बीचको फायरवालले के अनुमति दिनुपर्ने बदल्छ, तर छेउमा कुन सिलेक्टर वा कुञ्जी लागू हुन्छन् भन्ने होइन।
त्यसपछि नीतिका सिलेक्टर पढ्नुहोस्। तपाईंले परीक्षण गरिरहेको ट्राफिकभन्दा साँघुरो प्रिफिक्स भन्ने सिलेक्टर नै काम गरिरहेको टनेलले प्रवाहलाई बेवास्ता गरेजस्तो देखिनुको सबैभन्दा सामान्य कारण हो, र गलत प्रोटोकलको सिलेक्टरले त्यही मौनता दिन्छ।
| Field | Where it appears | What it decides |
|---|---|---|
| Security parameter index | ESP header, and the receiving state entry | Which association and keys the receiver applies |
| Sequence number | ESP header | Replay detection for that association |
| Next header | ESP trailer | What the decapsulated payload contains |
| Inner IP header | Inside tunnel-mode payload only | The original source and destination the endpoints act on |
| Traffic selectors | Policy, not the packet | Which local traffic is allowed to use the association |
विक्रेताका उपकरणले त्यही जानकारी बढी सुविधाजनक रूपमा छाप्छन्। ipsec statusall strongSwan मा यसले चाइल्ड एसोसिएसन, तिनका सिलेक्टर र बाइट काउन्टर सूचीबद्ध गर्छ, जुन कुन चाइल्ड हेर्ने भनी पहिले नै थाहा भए कच्चा xfrm आउटपुट पढ्नुभन्दा प्रायः छिटो हुन्छ।
दोस्रो चरण: एउटा प्रवाहले काउन्टर सार्छ भनी प्रमाणित गर्नुहोस्
काउन्टर तब मात्र अर्थपूर्ण हुन्छन् जब तिनलाई केले सार्नुपर्ने थियो भनी थाहा हुन्छ, त्यसैले सिलेक्टरले पक्कै समेट्ने स्रोत र गन्तव्य छान्नुहोस् र एउटा हानिरहित अनुरोध पठाउनुहोस्। त्यसपछि त्यही प्रविष्टि फेरि पढ्नुहोस् र तुलना गर्नुहोस्।
ip -s xfrm state
tcpdump -ni any espदुई पढाइले फरक कथा भन्छन्। बाहिरतिर बढ्ने तर भित्रतिर कहिल्यै नबढ्ने प्याकेटले कुञ्जीको समस्या नभई फर्वार्डिङ वा फर्कने बाटोको समस्या देखाउँछन्, किनकि प्याकेट इन्क्याप्सुलेट भएर गयो। कुनै काउन्टर नसर्ने हो भने ट्राफिक नीतिसँग कहिल्यै मिलेन, र सिलेक्टर नै हेर्ने ठाउँ हो।
त्यही चरणको क्याप्चरले तारमा भएको इन्क्याप्सुलेसन पुष्टि गर्छ, बाहिरी प्याकेट ESP हुन् कि UDP-इन्क्याप्सुलेटेड ESP भन्ने पनि समेटेर। यसले तपाईंलाई प्रवाह साँच्चै बोकेका ठेगाना पनि देखाउँछ, र ती कहिलेकाहीँ तपाईं पढिरहनुभएको कन्फिगरेसनका भन्दा फरक हुन्छन्।
तेस्रो चरण: एउटा कुरा बदल्नुहोस् र फर्काइ राख्नुहोस्
केही सम्पादन गर्नु अघि एसोसिएसनको स्रोत, गन्तव्य, मोड, सिलेक्टर र काउन्टर लेख्नुहोस्। कुनै परिवर्तनले अवस्था बिगार्यो भने, अनुमानबाट चल्ने कन्फिगरेसन फेरि बनाउनुको सट्टा अघिल्लो स्थिति पुनर्स्थापना गर्न दिने त्यही अभिलेख हो। त्यो अभिलेख लेख्न एक मिनेट लाग्छ र पछि एक घण्टा बचाउँछ। परिवर्तन गर्ने व्यक्तिपछि बाँकी रहने एकमात्र सामग्री पनि त्यही हो।
एउटा सिलेक्टर वा एउटा प्यारामिटर बदल्नुहोस्, पुनः लोड गर्नुहोस्, र त्यही प्रवाहमा दोस्रो चरण दोहोर्याउनुहोस्। एसोसिएसन मेटाउँदा त्यसलाई प्रयोग गर्ने हरेक प्रवाह भाँचिन्छ, त्यसैले लक्षित सम्पादन र चाइल्ड पुनः लोड गर्नु के हुन्छ भनी हेर्न स्थिति खाली गर्नुभन्दा लगभग सधैं राम्रो हुन्छ।
सिलेक्टर सम्पादनको फर्काइ भनेको अघिल्लो नीति पुनर्स्थापना गरेर पुनः लोड गर्नु हो, सिलेक्टर स्थानीय नभई वार्ताद्वारा तय हुने भए सामु पक्षलाई मिल्ने परिवर्तन चाहिन सक्छ भन्ने सर्तसहित। त्यो निर्भरता ताजा हुँदै लेख्नुहोस्, किनकि आधा पुनर्स्थापित जोडी दुई अन्तिम अवस्थामध्ये कुनैभन्दा पनि सोच्न गाह्रो हुन्छ।
अन्तमा, दायरा इमानदार राख्नुहोस्। बगिरहेको ESP एसोसिएसनले दुई गेटवेले खण्डलाई सुरक्षित गरी पुर्याइरहेका छन् भनी प्रमाणित गर्छ, र त्यसले माथिको अनुप्रयोगले आफ्ना प्रयोगकर्तालाई प्रमाणित गर्छ कि भण्डारण गरेको कुरा इन्क्रिप्ट गर्छ भन्ने केही भन्दैन। ती फरक प्रमाण भएका फरक नियन्त्रण हुन्, र अर्को व्यक्तिले टिप्पणीबाट त्यसलाई दोहोर्याउन सकेपछि मात्र runbook पूरा हुन्छ।