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 तभी पूरा होता है जब अगला व्यक्ति नोट्स से इसे दोहरा सके।