VPN उपयोगकर्ताओं को एक सेवा तक पहुँच दें, सबनेट तक नहीं
संकीर्ण रूट कोई प्राधिकरण नीति नहीं है। तय करें कि प्रवर्तन कहाँ है, सेवा कौन सा स्रोत देखती है, और ऐप की भूमिकाएँ कैसे अलग रहती हैं।
एक ठेकेदार को एक आंतरिक वेब ऐप्लिकेशन चाहिए और कुछ नहीं, और आसान जवाब यह है कि उसे सर्वर सबनेट में एक टनल दे दिया जाए। यह उस दिन तक चलता है जब वह इसे स्कैन करता है। संकीर्ण डिज़ाइन में अधिक सोच चाहिए, क्योंकि पहुँच, रूटिंग और ऐप्लिकेशन अनुमति तीन अलग नियंत्रण हैं जिन्हें सहमत होना है।
आवश्यकता को सबनेट के रूप में नहीं, सेवा के रूप में लिखें
गंतव्य होस्ट, प्रोटोकॉल और पोर्ट से शुरू करें, फिर वह उपयोगकर्ता या डिवाइस समूह जोड़ें जिसे वहाँ पहुँचना चाहिए। निजी DNS ज़ोन केवल तभी शामिल करें जब ऐप्लिकेशन कोई नाम हल करता हो, और पहचान प्रदाता केवल तभी शामिल करें जब साइन-इन प्रवाह को उसकी ज़रूरत हो। बाकी सब एक निर्भरता है जिसे आपने अभी तक उचित नहीं ठहराया।
सबनेट नेटवर्क टीम का कार्यान्वयन विवरण है, जबकि सेवा वह है जो व्यवसाय ने माँगा और वह इकाई जिसकी समीक्षा की जा सकती है और जिसे सेवामुक्त किया जा सकता है।
यदि निर्भरता सूची तीन मदों से आगे बढ़ती है, तो ऐप्लिकेशन को संभवतः अपनी डिज़ाइन चर्चा चाहिए।
संकीर्ण रूप से रूट करें, पर प्रवर्तन कहीं और करें
संकीर्ण रूट या चयनक टनल को बताता है कि कौन से पैकेट ले जाने हैं; यह प्राधिकरण नीति नहीं है। गेटवे फ़िल्टर, गंतव्य होस्ट का फ़ायरवॉल और ऐप्लिकेशन का अपना अनुमति मॉडल वे जगहें हैं जहाँ पहुँच तय होती है। एक पते को कवर करने वाला रूट अच्छी शुरुआत है, और यह वह नियंत्रण नहीं है जो दृढ़ उपयोगकर्ता को रोकता है। यही अलगाव आपको टनल को फिर से डिज़ाइन किए बिना फ़िल्टर बदलने देता है।
इसके विपरीत, कठोर फ़िल्टर वाला चौड़ा रूट वैध हो सकता है, पर केवल तभी जब सभी संबंधित जानते हों कि दोनों में से कौन प्रवर्तन करता है।
प्रवर्तन बिंदु को स्पष्ट रूप से दस्तावेज़ करें, अन्यथा अगला परिवर्तन उसे गलती से खिसका देगा।
जाँचें कि सेवा वास्तव में कौन सा स्रोत देखती है
लक्ष्य या तो क्लाइंट के पूल का पता देखता है या गेटवे का पता, इस पर निर्भर करता है कि आप अनुवाद करते हैं या नहीं। होस्ट फ़ायरवॉल नियमों और लॉग को वास्तविक स्रोत से मेल खाना चाहिए। यदि कई उपयोगकर्ता एक अनुवादित स्रोत साझा करते हैं, तो उस होस्ट पर कोई भी प्रति-उपयोगकर्ता नियम उन्हें अलग नहीं कर सकता, और यह डिज़ाइन बाधा है, बग नहीं।
अनुवाद जानबूझकर चुनें: यह रूटिंग सरल करता है और स्रोत की पहचान नष्ट करता है, जो ऑडिट और प्रति-उपयोगकर्ता नियमों के लिए मायने रखता है।
लिखें कि आपने दोनों में से कौन सा चुना, उस नियम के पास जो इस पर निर्भर है।
ऐप्लिकेशन प्राधिकरण वैकल्पिक नहीं है
पोर्ट तक पहुँचना भूमिका नहीं देता। ऐप्लिकेशन को अब भी अपना लॉगिन और अपनी अनुमतियाँ चाहिए, क्योंकि नेटवर्क परत यह नहीं बता सकती कि उपयोगकर्ता कौन से रिकॉर्ड संपादित कर सकता है। जो सेवा आंतरिक सबनेट से आने वाले हर अनुरोध पर भरोसा करती है, वह संकीर्ण टनल को एक समझौता किए गए क्रेडेंशियल के लिए पूर्ण पहुँच में बदल देती है। टनल तय करता है कि सॉकेट कौन खोल सकता है, और ऐप्लिकेशन तय करता है कि उसके साथ क्या किया जा सकता है।
यहीं संकीर्ण डिज़ाइन दोगुना फल देता है, क्योंकि कम पहुँच योग्य होस्ट का अर्थ है कम जगहें जहाँ ऐप्लिकेशन-स्तर की गलती का दुरुपयोग हो सकता है।
नेटवर्क नियम और ऐप्लिकेशन भूमिका को अलग सिस्टम में रखें, और उन्हें अलग-अलग सेवामुक्त करें।
अनुमत और अस्वीकृत दोनों मार्ग सिद्ध करें
अधिकृत उपयोगकर्ता के रूप में कनेक्ट करें और एक हानिरहित प्रतिनिधि क्रिया करें, फिर ऐसे गंतव्य को आज़माएँ जो पहुँच से बाहर होना चाहिए। जो डिज़ाइन केवल पहला आधा जाँचता है वह जाँचा हुआ नहीं है, और अस्वीकृति परीक्षण ही डिज़ाइन सिद्ध करता है। हर नियम परिवर्तन के बाद नया सत्र जाँचें, और यदि अनुरोध आते हैं पर उत्तर नहीं, तो वापसी मार्ग देखें।
स्वीकृति परीक्षण पास कराने के लिए फ़ॉरवर्डिंग फ़िल्टर बंद न करें, क्योंकि इससे वह चीज़ बदल जाती है जिसकी जाँच हो रही है।
जब उपयोगकर्ता को सेवा की आवश्यकता न रहे, तो दूरस्थ पहचान और ऐप्लिकेशन भूमिका को उनके संबंधित सिस्टम में सेवामुक्त करें, और दोनों दर्ज करें। strongSwan फ़ॉरवर्डिंग गाइड मार्ग के गेटवे पक्ष को कवर करता है।