VPN क्लाइंट और LAN: अलग ज़ोन कब इस्तेमाल करें

टनल इंटरफ़ेस को LAN ज़ोन में रखना काम करने वाले VPN तक सबसे छोटा रास्ता है, और आम तौर पर यह ग़लत डिफ़ॉल्ट है। यह दूरस्थ क्लाइंट को वही भरोसा देता है जो वायर्ड LAN के पास है, जबकि काम को ऐसा शायद ही चाहिए होता है। अलग ज़ोन में कुछ नियमों की क़ीमत लगती है और सीमा दिखाई देने लगती है। फ़ैसला यह नहीं है कि ज़ोन बेहतर हैं या नहीं; फ़ैसला यह है कि आपके नेटवर्क पर कौन-सी तीन शर्तें लागू होती हैं।

ज़ोन का नाम कुछ भी एन्क्रिप्ट नहीं करता और किसी उपयोगकर्ता को प्रमाणित नहीं करता। यह सिर्फ़ फ़ायरवॉल के नीति मॉडल के लिए इंटरफ़ेस को समूहित करता है।

ज़ोन सदस्यता वास्तव में क्या नियंत्रित करती है

ज़ोन फ़ायरवॉल के मॉडल के अंतर्गत इंटरफ़ेस या ट्रैफ़िक को समूहित करता है। उसके बाद उसकी इनपुट, आउटपुट और फ़ॉरवर्डिंग सेटिंग्स अलग-अलग भूमिकाएँ संभालती हैं। इनपुट राउटर तक ही जाने वाला ट्रैफ़िक है; फ़ॉरवर्डिंग उसके ज़रिए किसी दूसरे होस्ट तक जाने वाला ट्रैफ़िक है। OpenWrt का ज़ोन दस्तावेज़ ठीक इसी कारण इनपुट, आउटपुट और फ़ॉरवर्डिंग को अलग सेटिंग्स मानता है।

VPN ज़ोन से LAN ज़ोन तक की अनुमति अपने-आप उलटी अनुमति नहीं होती। फ़ॉरवर्डिंग नियम दिशात्मक होते हैं, और क्लाइंट से सर्वर तक ट्रैफ़िक की अनुमति देने वाला नियम सर्वर से क्लाइंट तक सत्रों की अनुमति नहीं देता। जो क्लाइंट सर्वर से कनेक्शन खोल सकता है, वह ऐसा क्लाइंट नहीं है जिसकी ओर सर्वर वापस कनेक्शन खोल सके।

यही अंतर अलग ज़ोन के उपयोगी होने का कारण है: आप हर दिशा और हर भूमिका स्पष्ट रूप से लिख सकते हैं। हर नियम के बग़ल में दिशा लिखें।

पहला फ़ैसला: इनपुट, फ़ॉरवर्ड या दोनों

अगर दूरस्थ क्लाइंट को राउटर से DNS चाहिए, तो सिर्फ़ उस सेवा के लिए इनपुट की अनुमति दें। अगर उन्हें फ़ाइल सर्वर तक पहुँचना है, तो उस गंतव्य तक फ़ॉरवर्ड की अनुमति दें। ज़्यादातर VPN डिज़ाइनों को दोनों चाहिए, पर अलग-अलग सेवाओं के लिए।

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

दूसरा फ़ैसला: दूरस्थ क्लाइंट को कौन-से संसाधन चाहिए

नियम लिखने से पहले क्लाइंट श्रेणियाँ, गंतव्य और वे सेवाएँ सूचीबद्ध करें जो VPN को देनी चाहिए। गंतव्यों की सूची भरोसे के लेबल से ज़्यादा उपयोगी है, क्योंकि वह फ़ायरवॉल माइग्रेशन में टिकी रहती है।

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

अगर अनुमत गंतव्य आगे फ़ॉरवर्ड कर सकता है, तो ज़ोन की सीमा फ़ायरवॉल पर ही रुकती है, गंतव्य आगे क्या करता है वहाँ नहीं।

तीसरा फ़ैसला: आप सीमा कैसे सिद्ध करेंगे

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

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

जैसे-जैसे नेटवर्क बढ़े, सदस्यता और नियमों का उद्देश्य दस्तावेज़ित करें। नया जुड़ा इंटरफ़ेस सिर्फ़ इसलिए विशेषाधिकार विरासत में न ले कि किसी ने उसे सुविधाजनक ज़ोन नाम दे दिया है।