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 कर्नेल ने वास्तव में क्या इंस्टॉल किया, यह दिखाता है, और यहीं यह पुष्टि की जाती है कि कुंजी-नवीनीकरण आपके दस्तावेज़ीकृत सेट से भिन्न किसी सेट पर नहीं लौटा है।
सुधार के बाद उस आउटपुट को कॉन्फ़िगरेशन के साथ सहेजें। जब क्लाइंट अद्यतन अपने डिफ़ॉल्ट बदलता है, तो दर्ज सेट आपको तुलना के लिए आधाररेखा देता है, और तुलना जाँच को शुरू से शुरू करने के बजाय खिसके फ़ील्ड की ओर संकेत करती है।