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 सोबत जोडणारा प्रस्ताव सर्वोत्तम स्थितीत अनावश्यक आणि सर्वात वाईट स्थितीत नाकारला जातो।
IKE बाजूला PRF अजूनही वेगळा आहे, कारण तो पेलोडचे रक्षण करण्याऐवजी नियंत्रण चॅनेलसाठी की काढतो। म्हणूनच 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 कर्नेलने प्रत्यक्षात काय स्थापित केले ते दाखवते, आणि की-नूतनीकरण तुम्ही दस्तऐवजीकृत केलेल्यापेक्षा वेगळ्या संचावर परत गेले नाही याची खात्री करण्याची जागा तिथेच आहे।
दुरुस्तीनंतर तो आउटपुट कॉन्फिगरेशनजवळ साठवा। क्लायंट अद्यतन त्याची डीफॉल्ट बदलल्यास, नोंदवलेला संच तुलनेसाठी आधाररेषा देतो, आणि तुलना तपासणी सुरुवातीपासून सुरू करण्याऐवजी सरकलेल्या फील्डकडे निर्देश करते।