IPsec प्रस्तावमा के के हुन्छ? IKE र ESP फिल्डहरू
प्रस्ताव एउटा पूर्ण अफर हो, एल्गोरिदमको झोला होइन। कुन फिल्ड IKE का हुन् र कुन ESP का, र किन एउटै बेमेलले पूरै सेट अस्वीकार गर्छ हेर्नुहोस्।
IKE सुरु हुन्छ, दुवै पक्षले AES घोषणा गर्छन्, तर टनेल NO_PROPOSAL_CHOSEN सँगै असफल हुन्छ। लगले प्रस्तावको नाम बताउँछ तर नमिलेको फिल्ड बताउँदैन। प्रस्ताव एउटा पूर्ण अफर हो, र एउटा असंगत फिल्डले त्यो लाइन मात्र होइन, पूरै संयोजन अवैध बनाउँछ। यसलाई स्वतन्त्र एल्गोरिदम छनोटको झोला भनेर पढ्नु नै बेमेल अदृश्य रहनुको सामान्य कारण हो।
छुट्टाछुट्टै प्रस्ताव-सूची भएका दुई वार्ता
IKEv2 ले दुई सुरक्षा संगठन बनाउँछ। पहिलो IKE SA हो, जसले नियन्त्रण आदानप्रदानलाई आफै सुरक्षित राख्छ, र दोस्रो CHILD SA हो, जसले तपाईंको ट्राफिक ESP मार्फत बोक्छ। प्रत्येकको आफ्नै प्रस्ताव-सूची छ, र पियरले एउटा स्वीकार गरी अर्को अस्वीकार गर्न सक्छ।
यो विभाजनले एउटा सामान्य अन्योल बुझाउँछ: चल्ने IKE SA ले नियन्त्रण-च्यानलका एल्गोरिदम मिले भन्ने मात्र प्रमाणित गर्छ। CHILD प्रस्ताव असफल भयो भने, पहिलो चरण पूरा भए पनि र लग माथिबाट स्वस्थ देखिए पनि टनेलले एउटै प्याकेट बोक्दैन।
प्रत्येक सूचीभित्रको क्रम पनि महत्त्वपूर्ण छ। उत्तरदाताले सुरुवातकर्ताका क्रमबद्ध अफरहरूबाट छान्छ, त्यसैले फराकिलो रूपमा संगत प्रविष्टिलाई साँघुरोभन्दा माथि सार्दा कुन सेट स्थापना हुने हो भन्ने बदलिन्छ, तर कुनै एल्गोरिदमको नाम बदलिँदैन। पूर्वनिर्धारितमा भर नपरी त्यो क्रम कन्फिगरेसनमा पिन गर्नुहोस्। स्थिर क्रमले साइटहरूबीचको लग तुलनालाई पनि अर्थपूर्ण बनाउँछ।
कुन फिल्ड कुन प्रस्तावका हुन्
फिल्डको सेट सानो छ, तर दुई वार्तामा एउटै छैन। तालिका पङ्क्ति-पङ्क्ति पढ्नुहोस्, किनकि एउटा स्तम्भको फिल्ड अर्कोमा नहुन सक्छ। वाक्य संरचना कार्यान्वयनअनुसार फरक पर्छ; strongSwan का प्रस्ताव-कागजातहरू एउटा ठोस सन्दर्भ हो।
| Field | IKE SA proposal | CHILD SA proposal |
|---|---|---|
| Encryption | Required | Required |
| Integrity | Required unless AEAD | Required unless AEAD |
| PRF | Required | Not present |
| DH group | Required | Only for PFS |
| ESN | Not present | Optional |
इन्क्रिप्सन फिल्डले साइफर र अधिकांश वाक्य संरचनामा उसको कुञ्जी-लम्बाइ बताउँछ। अखण्डता फिल्डले साइफरटेक्स्ट प्रमाणित गर्न प्रयोग हुने ह्यास बताउँछ, र PRF ले IKE SA का लागि कुञ्जी-सामग्री निकाल्ने फंक्सन बताउँछ। DH समूहले नयाँ साझा गोप्य सामग्री स्थापित गर्छ, त्यसैले यो दुवैतिर देखिन्छ तर फरक उद्देश्यका लागि।
विस्तारित अनुक्रम-संख्या डेटा-मार्गकै मात्र हुन्। तिनले अनुक्रम-स्थान फराकिलो बनाउँछन् र CHILD प्रस्तावको भागका रूपमा वार्ता हुन्छन्, त्यसैले त्यहाँको बेमेलले CHILD अफर अस्वीकार गर्छ र IKE SA अछुत रहन्छ।
एउटा पूर्ण अफर कसरी छानिन्छ
प्रत्येक प्रस्ताव एउटा सेट हो, र उत्तरदाताले प्रत्येक अनिवार्य फिल्ड स्वीकार्य हुने सेट खोज्छ। दुवै सूचीमा AES र SHA-256 हुन सक्छन् र तैपनि कुनै संगत प्रविष्टि नहुन सक्छ, किनकि कुञ्जी-लम्बाइ, PRF वा DH समूह फरक छन्। तुलना प्रत्येक एल्गोरिदममा होइन, प्रत्येक प्रस्तावमा हुन्छ।
केही पनि मिलेन भने उत्तरदाताले असफल SA प्रकारसहित NO_PROPOSAL_CHOSEN पठाउँछ। कन्फिगरेसन सम्पादन गर्नुअघि सूचना कुन प्रस्ताव-सूचीसँग सम्बन्धित छ पढ्नुहोस्; IKE प्रस्ताव अस्वीकृत भएपछि ESP एल्गोरिदम बदल्नु डिबगिङको एउटा चक्र बर्बाद गर्छ।
प्रोफाइल ट्युन गर्दा छनोट-व्यवहार जान्नु उपयोगी हुन्छ। केही कार्यान्वयनले सुरुवातकर्ताको क्रम मन पराउँछन्, अरूले स्थानीय नीतिअनुसार पुनः क्रम लगाउँछन्, त्यसैले दुई विक्रेताबीच चल्ने सेट हराउन सक्छ तपाईंले कुन पक्षले जडान सुरु गर्छ उल्टाउँदा।
AEAD ले फिल्ड थप्नुको सट्टा हटाउँछ
AES-GCM र ChaCha20-Poly1305 एउटै क्रियामा प्रमाणीकरण र इन्क्रिप्सन गर्छन्। तीमध्ये कुनै ESP का लागि छानिँदा अखण्डता एल्गोरिदम छुट्टै वार्ता हुँदैन, किनकि AEAD बनावटले यसलाई पहिल्यै ढाक्छ। त्यसैले AES-GCM लाई SHA-256 सँग जोड्ने प्रस्ताव उत्तम अवस्थामा अनावश्यक र सबैभन्दा खराब अवस्थामा अस्वीकृत हुन्छ।
PRF IKE पक्षमा अझै छुट्टै छ, किनकि यसले पेलोड सुरक्षित गर्नुको सट्टा नियन्त्रण च्यानलका लागि कुञ्जी निकाल्छ। त्यसैले IKE प्रस्तावले AEAD साइफरलाई PRF र DH समूहसँग वैध रूपमा जोड्न सक्छ, जबकि सम्बन्धित ESP प्रस्तावले AEAD साइफर र वैकल्पिक PFS समूह मात्र सूचीबद्ध गर्छ।
कुञ्जी-लम्बाइ इन्क्रिप्सन टोकनको भाग हो, त्यसैले AES-128-GCM र AES-256-GCM फरक अफर हुन्। 256-bit कुञ्जी मान्ने मार्गदर्शिकाबाट प्रतिलिपि गरिएको प्रोफाइल 128-bit का लागि कन्फिगर गरिएको एन्डप्वाइन्टसँग मिल्दैन, दुवै लाइनले AES-GCM भने पनि। दुई पियरले साइफर परिवारमा सहमति जनाए पनि ड्यासपछिको संख्याका कारण एकअर्कालाई अस्वीकार गर्न सक्छन्।
कन्फिगरेसन होइन, स्थापित SA पढ्नुहोस्
कन्फिगर गरिएको प्रस्ताव-सूची एउटा अफर हो; स्थापित SA नतिजा हो। strongSwan र Linux कर्नेलमा दुवै दृश्य उपलब्ध छन्:
sudo swanctl --list-sas
sudo ip xfrm state
sudo ip xfrm policyswanctl --list-sas प्रत्येक SA का लागि वार्ता भएका एल्गोरिदम छाप्छ, CHILD ले AEAD प्रयोग गर्छ कि भन्ने पनि समावेश गरी। ip xfrm state कर्नेलले वास्तवमै के स्थापित गर्यो देखाउँछ, र कुञ्जी-नवीकरणले तपाईंले कागजातमा राखेकोभन्दा फरक सेटमा फर्किएन भनी पुष्टि गर्ने ठाउँ त्यहीँ हो।
सुधारपछि त्यो आउटपुट कन्फिगरेसनको छेउमा सुरक्षित राख्नुहोस्। क्लाइन्ट अपडेटले आफ्ना पूर्वनिर्धारित बदल्दा, अभिलेख गरिएको सेटले तुलनाका लागि आधाररेखा दिन्छ, र तुलनाले अनुसन्धान सुरुदेखि सुरु गर्नुको सट्टा सरेको फिल्डतर्फ संकेत गर्छ।