एन्क्रिप्टेड ट्रांज़िट कैरियर तक पहुँच नहीं देता

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

नीचे दिए गए चरण क्रम से पूरे करें, और किसी भी चरण की विफलता को कॉन्फ़िगरेशन में बदलाव नहीं, डिज़ाइन में बदलाव मानें।

किसी कॉन्फ़िग को छूने से पहले दोनों सीमाएँ तय करें

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

दोनों को पतों, पोर्टों और दिशाओं की सूचियों के रूप में लिखें। अगर सूची लिखी नहीं जा सकती, तो सीमा अभी तय नहीं हुई है।

चरण 1: बाहरी सुरंग को सीमित करें

कैरियर की ओर वाले इंटरफ़ेस पर केवल वही अनुमति दें जो सुरंग को चाहिए: दो गेटवे पतों के बीच UDP 500 और 4500 पर IKE, और जहाँ NAT ट्रैवर्सल का उपयोग नहीं होता वहाँ ESP। उस इंटरफ़ेस पर आने वाली बाकी हर चीज़ को अस्वीकार करें, जिसमें प्रबंधन प्रोटोकॉल शामिल हैं। ESP विनिर्देश सुरक्षा सेवाओं को कवर करता है; यह नहीं बताता कि गेटवे कैरियर की किन अपनी सेवाओं का उपयोग कर सकते हैं। इसे स्पष्ट अनुमति-सूची के रूप में व्यक्त करें, ताकि नई प्रकाशित कैरियर सेवा डिफ़ॉल्ट रूप से पहुँच योग्य न हो जाए।

यही नियम-समूह डिज़ाइन को पीयरिंग व्यवस्था नहीं, ट्रांज़िट डिज़ाइन बनाता है।

इसे गेटवे कंसोल से नहीं, कम भरोसे वाले पक्ष से जाँचें। वहाँ के होस्ट को सुरंग बनने से पहले भी कैरियर के DNS सर्वर तक पहुँचने में विफल होना चाहिए।

चरण 2: तय करें कि दूर का गेटवे क्या पहुँचाता है

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

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

चरण 3: हर परत के लिए स्वामित्व रखें

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

हर परत को एक स्वामी दें। बिना स्वामी वाली परतें ही भटकती हैं।

चरण 4: सत्यापित करें, फिर इसे प्राधिकरण को सौंपें

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

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