इन्क्रिप्टेड ट्रान्जिटले क्यारियरमा पहुँच दिँदैन

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

तलका चरणहरू क्रममा पूरा गर्नुहोस्, र कुनै पनि चरणको असफलतालाई कन्फिगरेसनको समायोजन नभई डिजाइन परिवर्तन मान्नुहोस्।

कन्फिगमा छुनुअघि दुवै सीमा परिभाषित गर्नुहोस्

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

दुवैलाई ठेगाना, पोर्ट र दिशाहरूको सूचीका रूपमा लेख्नुहोस्। सूची लेख्न सकिँदैन भने सीमा अझै परिभाषित भएको छैन।

चरण 1: बाहिरी टनेल सीमित गर्नुहोस्

क्यारियरतर्फ फर्किएको इन्टरफेसमा टनेललाई आवश्यक पर्ने मात्र अनुमति दिनुहोस्: दुई गेटवे ठेगानाबीच UDP 500 र 4500 मा IKE, र NAT ट्राभर्सल प्रयोग नगरिएको ठाउँमा ESP. त्यो इन्टरफेसमा आउने बाँकी सबै, व्यवस्थापन प्रोटोकलहरूसमेत, अस्वीकार गर्नुहोस्। ESP विशिष्टता ले सुरक्षा सेवाहरू समेट्छ; गेटवेहरूले क्यारियरका कुन आफ्नै सेवाहरू प्रयोग गर्न सक्छन् भन्नेबारे यसले केही भन्दैन। यसलाई स्पष्ट अनुमति सूचीका रूपमा व्यक्त गर्नुहोस्, ताकि नयाँ प्रकाशित क्यारियर सेवा पूर्वनिर्धारित रूपमा पहुँचयोग्य नहोस्।

यही नियम समूहले डिजाइनलाई पियरिङ व्यवस्था नभई ट्रान्जिट डिजाइन बनाउँछ।

यसलाई गेटवे कन्सोलबाट नभई कम विश्वास भएको पक्षबाट जाँच्नुहोस्। त्यहाँको होस्टले टनेल उठ्नुअघि नै क्यारियरको DNS सर्भरमा पुग्न असफल हुनुपर्छ।

चरण 2: टाढाको गेटवेले के पुर्‍याउँछ भनी निर्णय गर्नुहोस्

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

सफल डिक्रिप्शनमा रोकिने रेखाचित्रले सबैभन्दा महत्त्वपूर्ण निर्णय छोडेको छ।

चरण 3: प्रत्येक तहको स्वामित्व राख्नुहोस्

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

प्रत्येक तहलाई मालिक तोक्नुहोस्। मालिक नभएका तहहरू नै बहकिन्छन्।

चरण 4: प्रमाणित गर्नुहोस्, त्यसपछि अधिकारीकहाँ बुझाउनुहोस्

टनेल उठेको र क्यारियरका नियम लागू भएको अवस्थामा बाहिरी मार्ग प्रमाणित गर्नुहोस्। त्यसपछि कम विश्वास भएको पक्षले पुग्न नहुने प्रत्येक स्रोत प्रयास गर्नुहोस् र असफलता अस्वीकृति हो, मार्ग लुकाउने समयसमाप्ति होइन भनी पुष्टि गर्नुहोस्। उपलब्धता र स्रोत सीमाहरू पनि जाँच्नुहोस्, किनकि इन्क्रिप्टेड लिङ्क पनि सन्तृप्त हुन सक्छ।

नियमन गरिएको वा वर्गीकृत वातावरणका लागि डिजाइन जिम्मेवार सुरक्षा अधिकारीकहाँ लैजानुहोस् र त्यसको स्वीकृत पृथकीकरण वास्तुकला प्रयोग गर्नुहोस्। VPN कन्फिगरेसन र अवधारणात्मक व्याख्याले मान्यता स्थापित गर्दैन। त्यो चरण कागजी काम होइन; डिजाइन अस्तित्वमा रहन अनुमति छ कि छैन त्यसले निर्धारण गर्छ।