दोन होस्टांमधील IPsec: संरक्षण कुठे सुरू होते आणि कुठे थांबते
होस्टांची जोडी गेटवेवशिवाय निवडलेल्या प्रवाहांचे संरक्षण करू शकते. टोकाचे बिंदू, रहदारी निवडणारे धोरण आणि वेगळी राहणारी परवानगी निश्चित करा.
होस्टांच्या जोडीवरील संरक्षण तिथे सुरू होते जिथे सुरक्षा सहयोग संपतो, आणि हीच ती वस्तुस्थिती आहे जी गेटवेच्या आकाराची अंतःप्रेरणा सर्वाधिक चुकवते। एक उपयोजन सर्व्हर आणि त्याचा डेटाबेस सर्व्हर त्यांचा स्वतःचा संवाद थेट संरक्षित करू शकतात, मार्गात कोणत्याही दूरस्थ प्रवेश केंद्रकाशिवाय, आणि संरक्षणाची सीमा मग फायरवॉलमध्ये नसून प्रत्येक होस्टच्या आत असते। यामुळे तुम्हाला निवडलेल्या प्रवाहांसाठी टोकापासून टोकापर्यंत व्याप्ती मिळते। यामुळे तुम्हाला कोण कोणती ओळ वाचू शकतो याचा निर्णय मिळत नाही।
सीमा तिथे आहे जिथे SA संपतो
RFC 4301 ट्रान्सपोर्ट मोडमधील सुरक्षा सहयोगांचे वर्णन अशा रचनेप्रमाणे करते जी सामान्यतः होस्टांच्या जोडीमध्ये टोकापासून टोकापर्यंत संरक्षणासाठी वापरली जाते। ते दोन्ही होस्ट किल्ल्या ठेवतात, आणि प्रत्येकजण ठरवतो की त्याच्या स्वतःच्या कोणत्या पॅकेट्स सहयोगात प्रवेश करतील। गेटवे बोगदा पूर्णपणे दुसरीकडे संपतो आणि अतिरिक्त अंतर्गत खंडातून होस्टपर्यंत पोहोचतो, ही वेगळी विश्वास सीमा आहे, तेव्हाही जेव्हा पॅकेट त्याच्या प्रवासाच्या बहुतांश भागात कूटबद्ध असते।
होस्ट-ते-होस्ट आणि ट्रान्सपोर्ट मोड तथापि समानार्थी नाहीत। दोन होस्ट आपापसात त्याचप्रमाणे योग्यरीत्या बोगदा मोडचा सहयोग बनवू शकतात, म्हणून आधी मोड निवडा आणि नंतर टोकाच्या बिंदूंचे वर्णन करा। दोन्ही डिझाइन टिप्पणीत सहकाऱ्यांच्या पत्त्यांजवळ लिहा, कारण केवळ मोड जाणणारा समीक्षक दुसरा गृहीत धरेल।
SPD संरक्षणाचा आणि मार्ग दिशेचा निर्णय घेतो
मार्गनिर्देश तक्ता पॅकेट कुठे जाते हे सांगतो। सुरक्षा धोरणाचा डेटाबेस निवडलेली रहदारी संरक्षण सीमा कशी ओलांडते हे सांगतो, आणि ते प्रत्येक दिशेसाठी स्वतःच्या निवडकांसह करतो। हेच विभाजन कारण आहे की डेटाबेसपर्यंत कार्यरत मार्ग विनंती संरक्षित होती की नाही यावर काहीही सिद्ध करत नाही, आणि हे की प्रस्थापित वाटाघाटी काहीही सिद्ध करत नाही की हे विशिष्ट उपयोजन तिच्याशी जुळले होते की नाही। मोजण्यांची तुलना करण्यापूर्वी निवडकांची तुलना करा, कारण मोजण्या केवळ तिथपर्यंत पोहोचलेल्या प्रवाहांचे वर्णन करतात।
Linux मध्ये, ip xfrm policy त्या नोंदी त्यांच्या दिशेसह, प्राधान्यासह, निवडकासह आणि परवानगी, अडवणूक किंवा सापळा या क्रियेसह छापतो, तर ip xfrm state परिणामी सहयोग आणि त्यांची मोजण्या दाखवतो। दोन्ही एकत्र वाचणे हाच तो मार्ग आहे ज्याने तुम्हाला तो प्रवाह सापडतो ज्याने बोगद्याला शांतपणे बगल दिली कारण एक व्यापक परवानगी नोंद आधी जुळली।
प्राधान्यक्रम धोरणाचा भाग आहे, अंमलबजावणीचा तपशील नाही। डेटाबेस पोर्टचे संरक्षण करायला हवे असलेली अरुंद नोंद उच्च प्राधान्याच्या व्यापक नोंदीकडून हरते, आणि अपयश असे दिसते जसे धोरणाला कधीही विचारलेच गेले नाही।
ट्रान्सपोर्ट मोड पुढील स्तर झाकतो, IP शीर्षलेख नाही
| Transport mode | Tunnel mode | |
|---|---|---|
| Original IP header | kept for routing the flow | replaced by an outer header |
| What ESP protects | the carried next-layer payload | the whole inner IP packet |
| Where it terminates | commonly the two hosts | gateway pair, or a host pair |
ट्रान्सपोर्ट मोडमध्ये ESP शीर्षलेख IP शीर्षलेख आणि पेलोडमध्ये बसतो, आणि त्या शीर्षलेखातील पत्ता क्षेत्रे मार्गावरील प्रत्येक उपकरणाला दिसत राहतात। पत्ते रहस्य नसतील आणि पेलोड रहस्य असेल तेव्हा हे ठीक आहे। तुम्हाला अंतर्गत स्थळरचनाही लपवायची असेल तर ही चुकीची निवड आहे, कारण केवळ बोगदा मोड मूळ शीर्षलेख नव्यामध्ये गुंडाळतो।
दोन्ही मोड पुढील स्तराचे अनेक प्रोटोकॉल वाहू शकतात, आणि ESP निवडकाशी जुळणारे संरक्षित करेल, होस्ट पाठवतो ते सर्व नाही।
निवड जोडणीपेक्षा अरुंद आहे
एक सहयोग अनेक प्रवाह वाहू शकतो, पण केवळ ते जे धोरण निवडते। सहकाऱ्यांच्या ओळखी, स्रोत आणि गंतव्य पत्ते, प्रोटोकॉल आणि तुमच्या मनातील संबंधाचा सेवा व्याप्ती नोंदवा, नंतर वेगळे ठरवा की न जुळणारी रहदारी उघड्या रूपात जाऊ शकते, तिचे संरक्षण झालेच पाहिजे, किंवा सहयोग उपलब्ध नसताना ती टाकून द्यायला हवी। हाच शेवटचा निर्णय आश्चर्य निर्माण करतो, कारण चुकीच्या स्रोतासाठी संरक्षण मागणारा नियम तुमच्या स्वतःच्या व्यवस्थापन प्रवेशास तितक्याच परिणामकारकपणे अडवू शकतो जितक्या परिणामकारकपणे तो घुसखोराला अडवतो।
अंमलबजावणी बदलत असताना मंजूर बाह्य-पट्टा मार्ग ठेवा, आणि दोन्ही होस्ट अगम्य होण्यापूर्वीच त्याची चाचणी करा, नंतर नाही।
यंत्राची ओळख उपयोजनाची परवानगी नाही
IPsec संरचित सहकाऱ्याचे प्रमाणीकरण करतो आणि निवडलेले पॅकेट संरक्षित करतो। तो कोणता डेटाबेस रेकॉर्ड व्यक्ती संपादित करू शकते हे ठरवत नाही, आणि विश्वासार्ह सर्व्हर ओळखीचे प्रत्येक उपयोजन विशेषाधिकाराच्या दानात रूपांतर करत नाही। उपयोजन खाती, भूमिका आणि अधिकृतता जिथे होती तिथेच राहतात, आणि उपयोजन स्तरावरील TLS आवश्यकता जाळ्याचा मार्ग आधीच संरक्षित असतानाही आपला हेतू टिकवून ठेवते।
रचना इच्छित स्रोताकडून एक क्रिया आणि नाकारली पाहिजे अशा एका क्रियेसह स्वीकारा, आणि आवश्यक सहयोग प्रस्थापित होऊ शकत नाही तेव्हा काय होते तेही समाविष्ट करा। सामान्य प्रवेशचाचणी तुम्हाला सांगते की पॅकेट हलत आहेत; ती सांगत नाही की ते तुम्ही लिहिलेल्या धोरणाखाली हलत होते।