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 पूर्ण होते।