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