फराकिलो IPsec चयनकर्ता हरेक सेवाको अनुमति होइन

दुई पियरहरू पूरै सबनेट सुरक्षित गर्न सहमत हुन्छन्, र कसैले त्यो सम्झौतालाई त्यसभित्रको हरेक सेवासम्म पुग्ने अनुमति ठान्छ। त्यो भ्रम हो: चयनकर्ताले सुरुङ कुन ट्राफिक बोक्न तयार छ भन्ने मात्र बताउँछ, र संस्थाले कुन सेवाहरूलाई अनुमति दिन्छ भन्नेबारे केही बताउँदैन। यन्त्रहरूको जोडीले फराकिलो ठेगाना दायरामा कानुनी रूपमा सहमति गर्न सक्छ, जबकि भित्रको पहुँच नीतिले दुई पोर्टलाई अनुमति दिन्छ, र दुवै भनाइ एउटै समयमा सत्य रहन्छन्।

सुरक्षित कभरेज अधिकार होइन

ट्राफिक चयनकर्ता सुरुङ सम्झौताको भाग हो। यसले पियरहरूले आपसमा के इन्क्रिप्ट गर्नेछन् भन्ने सीमित वा पुष्टि गर्छ, र दुवै पक्षसँग धेरै प्रवाह बोक्नु पर्दा फराकिलो चयनकर्ता चलाउनु प्रायः सबैभन्दा सजिलो हुन्छ। सेवा फिल्टर मार्गको अर्को बिन्दुमा अर्को नियन्त्रण हो, र प्याकेट डिक्रिप्ट भएपछि वास्तवमा के प्रयोग गर्न सकिन्छ भन्ने यसले निर्धारण गर्छ। एउटा परीक्षण उत्तीर्ण होस् भनेर फिल्टर हटाउनु नीतिगत निर्णयलाई दुर्घटनामा बदल्नु हो।

डिजाइन कागजातमा दुवै अभिलेख छुट्टाछुट्टै राख्नुहोस्, किनकि चयनकर्ता मात्र देख्ने पाठकले कहिल्यै नदिइएको अधिकार अनुमान गर्नेछ। परिवर्तन अभिलेखका दुई हरफले त्यो रोक्छन्, र तिनले पछि आउने बहसभन्दा कम समय लिन्छन्।

एउटा प्रवाह दुवै छेउबाट वर्णन गर्नुहोस्

आरम्भकर्ता, प्रतिक्रियाकर्ता, स्रोत र गन्तव्य जस्ता प्रस्तुत छन् त्यस्तै, प्रोटोकल र दुवै पोर्ट लेख्नुहोस्। त्यसपछि अर्को छेउका लागि ती प्रत्येक लेबल उल्टाउनुहोस्, किनकि क्लाइन्टको अस्थायी स्रोत पोर्ट जवाफको गन्तव्य पोर्ट बन्छ र टाढाको सञ्जाल स्थानीय बन्छ। त्यो नउल्टाई एकतर्फबाट अर्कोतर्फ प्रतिलिपि गरिएको कन्फिगरेसनले नै फिल्टरहरू ठ्याक्कै गलत दिशालाई अनुमति दिन्छन्। तालिका एकपटक लेख्नुहोस् र त्यसबाटै दुवै फिल्टर बनाउनुहोस्।

केही पनि प्रतिलिपि गर्नुअघि छनोट मोडेलमा सहमति गर्नुहोस्, किनकि नीति-आधारित डिजाइन र मार्ग-आधारित डिजाइनले एउटै मनसायलाई फरक वस्तुहरूमार्फत व्यक्त गर्छन्। प्रवाहको छेउमा मोडेलको नाम लेख्नुहोस्, नत्र अर्को इन्जिनियरले कहिल्यै तुलना गर्न नसकिने वस्तुहरू मिलाउन दिउँसो बिताउनेछ।

वास्तवमा लागू हुने फिल्टर खोज्नुहोस्

ASA मा, VPN फिल्टर समूह नीतिमा जोडिएको ACL हो र डिक्रिप्टपछिको तथा इन्क्रिप्टअघिको ट्राफिकमा लागू हुन्छ। Cisco को समूह-नीति कागजातले वंशानुक्रम पनि वर्णन गर्छ, जसमा समूह-नीति मानलाई प्रतिस्थापन गर्ने प्रयोगकर्ता-स्तरको मान समावेश छ। त्यसैले तपाईंले सम्पादन गर्नुभएको ACL तपाईंअगाडिको सत्र नियन्त्रण गर्ने ACL नहुन सक्छ। प्रयोगकर्ता वस्तुको हकमा पनि त्यही हो, त्यसले धेरै देखिने प्रमाण नछोडी समूहलाई जित्न सक्छ।

तपाईंले परिवर्तन गरेको सम्झनुभएको वस्तु होइन, प्रभावकारी सत्र जाँच्नुहोस्, र त्यो कुन नीति वस्तुले दिन्छ भन्ने टिपोट गर्नुहोस्। त्यो एउटै कदमले „फिल्टर ठीक छ तर चल्दैन“ भन्ने अचम्मलाग्दो धेरै रिपोर्ट समाधान गर्छ।

दिशा, पोर्ट र उल्टो अवस्था

अभिलेखित परम्पराले टाढाको सञ्जाल, वा तोकिएका टाढाका क्लाइन्ट ठेगानाहरूलाई स्रोत स्थानमा र स्थानीय सञ्जाललाई गन्तव्य स्थानमा राख्छ, जवाफहरू ठेगानाका स्थानहरू साटेर व्यक्त गरिन्छ। पोर्ट नियमहरू त्यो परम्परामाथि बस्छन् र ठेगानाभन्दा बढी ध्यान दिन योग्य छन्।

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

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

सकियो भन्नुअघि तीन अवस्था परीक्षण गर्नुहोस्

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

वार्ता गरिएको कभरेज र पहुँच निर्णयलाई दुई अभिलेखका रूपमा राख्नुहोस्, किनकि VPN ले के अनुमति दिन्छ भन्ने व्याख्या गर्न दुवै आवश्यक छन्।