चौड़ा IPsec चयनकर्ता हर सेवा की अनुमति नहीं है

दो सहकर्मी एक पूरे सबनेट की रक्षा करने पर सहमत होते हैं, और कोई उस समझौते को उसके भीतर की हर सेवा तक पहुँचने की अनुमति के रूप में पढ़ता है। यही भ्रांति है: चयनकर्ता बताता है कि सुरंग कौन-सा ट्रैफ़िक ले जाने को तैयार है, और यह नहीं बताता कि संगठन किन सेवाओं की अनुमति देता है। दो उपकरण वैध रूप से एक चौड़ी पता-श्रेणी पर सहमत हो सकते हैं, जबकि उसके भीतर की पहुँच नीति दो पोर्ट की अनुमति देती है, और दोनों कथन एक ही समय सत्य रहते हैं।

संरक्षित कवरेज अधिकृति नहीं है

ट्रैफ़िक चयनकर्ता सुरंग समझौते का हिस्सा है। यह सीमित या पुष्ट करता है कि सहकर्मी आपस में क्या एन्क्रिप्ट करेंगे, और जब दोनों पक्षों को बहुत सारे प्रवाह ले जाने हों तो चौड़ा चयनकर्ता अक्सर चलाने की सबसे सरल चीज़ होती है। सेवा फ़िल्टर पथ में किसी दूसरे बिंदु पर एक और नियंत्रण है, और यह तय करता है कि पैकेट डिक्रिप्ट होने के बाद वास्तव में क्या उपयोग किया जा सकता है। एक परीक्षण पास कराने के लिए फ़िल्टर हटाना नीति-निर्णय को दुर्घटना में बदल देता है।

डिज़ाइन दस्तावेज़ में दोनों अभिलेख अलग रखें, क्योंकि जो केवल चयनकर्ता देखता है वह ऐसी अधिकृति मान लेगा जो कभी दी ही नहीं गई। परिवर्तन अभिलेख में दो पंक्तियाँ इसे रोकती हैं, और वे आगे आने वाली बहस से कम समय लेती हैं।

दोनों सिरों से एक प्रवाह का वर्णन करें

आरंभकर्ता, उत्तरदाता, जैसे प्रस्तुत हैं वैसे स्रोत और गंतव्य, प्रोटोकॉल और दोनों पोर्ट लिखें। फिर दूसरे सिरे के लिए इनमें से हर लेबल उलट दें, क्योंकि क्लाइंट का क्षणिक स्रोत पोर्ट उत्तर का गंतव्य पोर्ट बन जाता है और दूरस्थ नेटवर्क स्थानीय बन जाता है। उस उलटाव के बिना एक पक्ष से दूसरे पक्ष में कॉपी किया गया विन्यास ही वह कारण है कि फ़िल्टर अंततः ठीक ग़लत दिशा की अनुमति देते हैं। तालिका एक बार लिखें और उसी से दोनों फ़िल्टर बनाएँ।

कुछ भी कॉपी करने से पहले चयन मॉडल पर सहमत हों, क्योंकि नीति-आधारित डिज़ाइन और मार्ग-आधारित डिज़ाइन एक ही इरादे को अलग-अलग ऑब्जेक्ट के माध्यम से व्यक्त करते हैं। प्रवाह के पास मॉडल का नाम लिखें, नहीं तो अगला अभियंता ऐसी वस्तुओं को मिलाने में दोपहर बिताएगा जो कभी तुलनीय नहीं थीं।

वह फ़िल्टर खोजें जो वास्तव में लागू होता है

ASA पर, VPN फ़िल्टर एक ACL है जो समूह नीति से जुड़ा होता है और डिक्रिप्शन के बाद तथा एन्क्रिप्शन से पहले के ट्रैफ़िक पर लागू होता है। Cisco का समूह-नीति दस्तावेज़ीकरण विरासत भी बताता है, जिसमें उपयोगकर्ता-स्तर का मान शामिल है जो समूह नीति के मान को प्रतिस्थापित करता है। इसलिए जो ACL आपने संपादित किया वह शायद वह ACL न हो जो आपके सामने का सत्र संभालता है। यही बात उपयोगकर्ता ऑब्जेक्ट पर भी लागू होती है, जो बहुत दृश्य प्रमाण छोड़े बिना समूह को पीछे छोड़ सकता है।

जिस ऑब्जेक्ट को आपने बदला है वैसा याद है उसके बजाय प्रभावी सत्र की जाँच करें, और नोट करें कि कौन-सा नीति ऑब्जेक्ट उसे देता है। यह एक कदम फ़िल्टर सही है पर काम नहीं कर रहा प्रकार की आश्चर्यजनक रूप से कई रिपोर्टें सुलझाता है।

दिशा, पोर्ट और उलटा मामला

प्रलेखित परिपाटी दूरस्थ नेटवर्क, या दिए गए दूरस्थ क्लाइंट पते, को स्रोत की स्थिति में और स्थानीय नेटवर्क को गंतव्य की स्थिति में रखती है, और उत्तर पतों की स्थिति बदलकर व्यक्त किए जाते हैं। पोर्ट नियम इस परिपाटी के ऊपर बैठते हैं और पतों से अधिक देखभाल के हक़दार हैं।

प्रलेखित मॉडल गंतव्य-पोर्ट नियम को उसी स्रोत पोर्ट का उपयोग करने वाले उलटे आरंभ पर प्रभाव डालने दे सकता है, जिसका अर्थ है कि फ़िल्टर केवल हानिरहित उत्तरों वाला एकतरफ़ा अनुरोध-नियम नहीं है। आरंभ की दोनों दिशाओं पर स्पष्ट रूप से विचार करें, और वह मामला भी शामिल करें जिसे आप अस्वीकार करना चाहते हैं।

वही दस्तावेज़ फ़िल्टर को प्रारंभिक संबंधों तक सीमित करता है, इसलिए यह निरीक्षित अनुप्रयोग द्वारा खोले जाने वाले हर द्वितीयक चैनल का सार्वभौमिक प्रवर्तन नहीं है। जहाँ पूरी नीति को वह कवरेज चाहिए, वह अलग सीमा पर होनी चाहिए, न कि अपने उद्देश्य से आगे खींचे गए ACL में।

समाप्त कहने से पहले तीन मामले जाँचें

इच्छित प्रवाह स्वीकार करें, नीति जिस सेवा को मना करती है उसे अस्वीकार करें, और उस उलटी दिशा के मामले का अभ्यास करें जिस पर आपने विचार किया। उन्हें स्वीकृत योजना के अंतर्गत उन्हीं पहचानों और चयनकर्ताओं के साथ चलाएँ जिन्हें आप तैनात करेंगे। जो परीक्षण केवल यह दिखाता है कि अनुमत सेवा काम कर रही है, वह सुरंग सिद्ध करता है, नीति नहीं।

सहमत कवरेज और पहुँच निर्णय को दो अभिलेखों के रूप में रखें, क्योंकि VPN क्या अनुमति देता है यह समझाने के लिए दोनों चाहिए।