विस्तृत IPsec सेलेक्टर म्हणजे प्रत्येक सेवेसाठी परवानगी नाही

दोन पीअर संपूर्ण सबनेट संरक्षित करण्यास सहमती देतात, आणि कोणीतरी त्या कराराला त्यातील प्रत्येक सेवेपर्यंत पोहोचण्याची परवानगी म्हणून वाचतो. तो गैरसमज आहे: सेलेक्टर सांगतो की टनेल कोणता रहदारी वाहून नेण्यास तयार आहे, आणि संस्था कोणत्या सेवांना अनुमती देते याबद्दल तो काहीही सांगत नाही. उपकरणांची जोडी विस्तृत पत्ता श्रेणीवर कायदेशीरपणे वाटाघाटी करू शकते, तर त्यातील प्रवेश धोरण दोन पोर्टना अनुमती देते, आणि दोन्ही विधाने एकाच वेळी खरी राहतात.

संरक्षित व्याप्ती म्हणजे अधिकार नाही

रहदारी सेलेक्टर हा टनेल कराराचा भाग आहे. पीअर एकमेकांमध्ये काय एन्क्रिप्ट करतील हे तो मर्यादित किंवा पुष्टी करतो, आणि दोन्ही बाजूंना अनेक प्रवाह वाहून न्यायचे असताना विस्तृत सेलेक्टर चालवणे ही बहुतेकदा सर्वात सोपी गोष्ट असते. सेवा फिल्टर मार्गातील वेगळ्या बिंदूवरील वेगळे नियंत्रण आहे, आणि पॅकेट डिक्रिप्ट झाल्यानंतर प्रत्यक्षात काय वापरता येईल हे तो ठरवतो. एक चाचणी उत्तीर्ण व्हावी म्हणून फिल्टर काढून टाकणे हे धोरणाच्या निर्णयाचे अपघातात रूपांतर करते.

रचना दस्तऐवजात दोन्ही नोंदी स्वतंत्र ठेवा, कारण फक्त सेलेक्टर पाहणारा वाचक कधीही दिले न गेलेला अधिकार गृहीत धरेल. बदल नोंदीतील दोन ओळी ते टाळतात, आणि त्यानंतरच्या वादापेक्षा त्या कमी वेळ घेतात.

एक प्रवाह दोन्ही टोकांकडून वर्णन करा

आरंभकर्ता, प्रतिसादकर्ता, स्रोत आणि गंतव्य जसे सादर केले आहेत तसे, प्रोटोकॉल आणि दोन्ही पोर्ट लिहून ठेवा. नंतर दुसऱ्या टोकासाठी ती प्रत्येक लेबल उलट करा, कारण क्लायंटचा तात्पुरता स्रोत पोर्ट प्रतिसादाचा गंतव्य पोर्ट होतो आणि दूरचे नेटवर्क स्थानिक होते. ते उलट न करता एका बाजूने दुसऱ्या बाजूला कॉपी केलेले संरचना हेच फिल्टर अगदी चुकीच्या दिशेला अनुमती देतात याचे कारण आहे. तक्ता एकदा लिहा आणि त्यावरून दोन्ही फिल्टर तयार करा.

काहीही कॉपी करण्यापूर्वी निवड मॉडेलवर सहमती द्या, कारण धोरण-आधारित रचना आणि मार्ग-आधारित रचना एकच हेतू वेगवेगळ्या वस्तूंद्वारे व्यक्त करतात. प्रवाहाच्या शेजारी मॉडेलचे नाव लिहा, अन्यथा पुढील अभियंता कधीही तुलना करता न येणाऱ्या वस्तू जुळवण्यात दुपारचा वेळ घालेल.

प्रत्यक्षात लागू होणारा फिल्टर शोधा

ASA वर, VPN फिल्टर हा ग्रुप धोरणाशी जोडलेला ACL असतो आणि डिक्रिप्टनंतरच्या व एन्क्रिप्शनपूर्वीच्या रहदारीवर लागू होतो. Cisco चे ग्रुप-धोरण दस्तऐवज वारसाहक्काचेही वर्णन करते, ज्यात ग्रुप-धोरण मूल्याची जागा घेणारे वापरकर्ता-स्तरीय मूल्य समाविष्ट आहे. त्यामुळे तुम्ही संपादित केलेला ACL तुमच्यासमोरचे सत्र चालवणारा ACL नसू शकतो. वापरकर्ता वस्तूबाबतही तेच खरे आहे, ती फारसे दृश्य पुरावे न ठेवता ग्रुपला मागे टाकू शकते.

तुम्ही बदलले असे आठवणारी वस्तू नव्हे, तर प्रभावी सत्र तपासा, आणि ते कोणती धोरण वस्तू पुरवते ते नोंदवा. हे एकच पाऊल „फिल्टर बरोबर आहे पण चालत नाही“ अशा आश्चर्यकारकपणे अनेक तक्रारी सोडवते.

दिशा, पोर्ट आणि उलट प्रकरण

नोंदवलेली प्रथा दूरचे नेटवर्क, किंवा नेमून दिलेले दूरचे क्लायंट पत्ते, स्रोत स्थानात आणि स्थानिक नेटवर्क गंतव्य स्थानात ठेवते, प्रतिसाद पत्त्यांची स्थाने बदलून व्यक्त करते. पोर्ट नियम त्या प्रथेवर आधारित आहेत आणि पत्त्यांपेक्षा अधिक काळजी घेण्यास पात्र आहेत.

नोंदवलेले मॉडेल गंतव्य-पोर्ट नियमाला त्याच स्रोत पोर्टचा वापर करणाऱ्या उलट आरंभावर परिणाम करू देऊ शकते, म्हणजे फिल्टर हा निरुपद्रवी प्रतिसादांसह फक्त एकतर्फी विनंती नियम नाही. दोन्ही आरंभ दिशांबद्दल स्पष्टपणे विचार करा, आणि तुम्ही नाकारण्याचा विचार करत असलेले प्रकरण समाविष्ट करा.

तेच दस्तऐवज फिल्टरला केवळ प्रारंभिक जोडण्यांपुरते मर्यादित करते, त्यामुळे तपासल्या जाणाऱ्या अनुप्रयोगाने उघडलेल्या प्रत्येक दुय्यम वाहिनीची ते सार्वत्रिक अंमलबजावणी नाही. संपूर्ण धोरणाला ती व्याप्ती हवी असल्यास ती त्याच्या उद्देशापलीकडे ताणलेल्या ACL मध्ये नव्हे, तर वेगळ्या सीमेवर असावी.

पूर्ण झाले असे म्हणण्यापूर्वी तीन प्रकरणे तपासा

इच्छित प्रवाह स्वीकारा, धोरणाने प्रतिबंधित केलेल्या सेवेला नकार द्या, आणि तुम्ही विचार केलेल्या उलट दिशेच्या प्रकरणाची चाचणी करा. तुम्ही उपयोजित करणार असलेल्या त्याच ओळखी आणि सेलेक्टरसह मंजूर आराखड्याखाली त्या चालवा. केवळ अनुमत सेवा चालते हे दाखवणारी चाचणी टनेल दाखवते, धोरण नाही.

वाटाघाटी केलेली व्याप्ती आणि प्रवेश निर्णय दोन नोंदी म्हणून ठेवा, कारण VPN कशाला अनुमती देते हे स्पष्ट करण्यासाठी दोन्ही आवश्यक आहेत.