VPN क्लायंट आणि LAN: वेगळा झोन कधी वापरावा

टनेल इंटरफेस LAN झोनमध्ये ठेवणे हा कार्यरत VPN पर्यंतचा सर्वात लहान मार्ग आहे, आणि सामान्यतः तो चुकीचा डीफॉल्ट असतो। ते दूरस्थ क्लायंटला वायर्ड LAN प्रमाणेच विश्वास देते, जे कामाला क्वचितच आवश्यक असतो। वेगळ्या झोनसाठी काही नियमांची किंमत मोजावी लागते आणि सीमा दिसू लागते। निर्णय झोन चांगले आहेत की नाही हा नाही; तुमच्या नेटवर्कला कोणत्या तीन अटी लागू होतात हा आहे।

झोनचे नाव काहीही एन्क्रिप्ट करत नाही किंवा वापरकर्त्याची प्रमाणितता तपासत नाही। ते फक्त फायरवॉलच्या धोरण मॉडेलसाठी इंटरफेस एकत्र करते।

झोन सदस्यत्व प्रत्यक्षात काय नियंत्रित करते

झोन फायरवॉलच्या मॉडेलमध्ये इंटरफेस किंवा रहदारी एकत्र करते। त्यानंतर त्याची इनपुट, आउटपुट आणि फॉरवर्डिंग सेटिंग्ज वेगवेगळ्या भूमिका सांभाळतात। इनपुट म्हणजे राउटरकडेच जाणारी रहदारी; फॉरवर्डिंग म्हणजे त्यातून दुसऱ्या होस्टकडे जाणारी रहदारी। OpenWrtचे झोन दस्तऐवज याच कारणामुळे इनपुट, आउटपुट आणि फॉरवर्डिंग वेगवेगळ्या सेटिंग्ज मानते।

VPN झोनमधून LAN झोनला दिलेली परवानगी आपोआप उलटी परवानगी नसते। फॉरवर्डिंग नियम दिशात्मक असतात, आणि क्लायंटकडून सर्व्हरकडे रहदारीला परवानगी देणारा नियम सर्व्हरकडून क्लायंटकडे सत्रांना परवानगी देत नाही। सर्व्हरशी कनेक्शन उघडू शकणारा क्लायंट हा असा क्लायंट नाही ज्याच्याकडे सर्व्हर परतीचे कनेक्शन उघडू शकेल।

हाच फरक वेगळा झोन उपयुक्त ठरण्याचे कारण आहे: तुम्ही प्रत्येक दिशा आणि प्रत्येक भूमिका स्पष्टपणे सांगू शकता। प्रत्येक नियमाच्या शेजारी दिशा लिहा।

पहिला निर्णय: इनपुट, फॉरवर्ड की दोन्ही

दूरस्थ क्लायंटना राउटरकडून DNS हवे असल्यास फक्त त्या सेवेसाठी इनपुटला परवानगी द्या। त्यांना फाइल सर्व्हरपर्यंत पोहोचायचे असल्यास त्या गंतव्याकडे फॉरवर्डला परवानगी द्या। बहुतेक VPN रचनांना दोन्ही हवे असते, पण वेगवेगळ्या सेवांसाठी।

प्रत्येक स्थानिक सेवेसाठी विस्तृत इनपुट प्रवेश जवळपास कधीच आवश्यक नसतो। राउटर व्यवस्थापन हा अनुप्रयोग प्रवेशापेक्षा वेगळा निर्णय माना। राउटरला फक्त DNS ला उत्तर द्यायचे असल्यास ती एकच परवानगी लिहा आणि बाकी बंद ठेवा।

दुसरा निर्णय: दूरस्थ क्लायंटना कोणती संसाधने हवीत

नियम लिहिण्यापूर्वी क्लायंट श्रेणी, गंतव्ये आणि VPNने पुरवावयाच्या सेवा यादी करा। गंतव्यांची यादी विश्वासाच्या लेबलपेक्षा उपयुक्त असते, कारण ती फायरवॉल स्थलांतरात टिकते।

व्यवस्थापन इंटरफेस सामान्य अनुप्रयोग प्रवेशापासून वेगळे ठेवा। विकीपर्यंत पोहोचणाऱ्या दूरस्थ क्लायंटला त्यामुळे राउटरचे प्रशासकीय पान किंवा हायपरव्हायझर कन्सोलची गरज नसते।

परवानगी दिलेल्या गंतव्याला पुढे फॉरवर्ड करता येत असल्यास झोनची सीमा फायरवॉलवरच थांबते, गंतव्य पुढे काय करते तिथे नाही।

तिसरा निर्णय: सीमा कशी सिद्ध कराल

प्रत्येक बदलानंतर परवानगी दिलेला प्रवाह आणि जाणूनबुजून नाकारलेला प्रवाह तपासा। एक संकेतस्थळ लोड होते हे सिद्ध करणे अनपेक्षित विस्तृत परवानगी उघड करत नाही। VPN क्लायंटच्या पत्ता श्रेणीतून तपासा, LANमधून नाही, आणि अपयश अपेक्षित असलेली दिशाही समाविष्ट करा। दोन्ही निकाल नियमाच्या शेजारी नोंदवा।

दूरस्थ झोनचे धोरण बदलण्यापूर्वी गेटवेचा पुनर्प्राप्ती प्रवेश जपून ठेवा। रनटाइम संपादनांऐवजी टिकाऊ व्यवस्थापित कॉन्फिगरेशन वापरा, अन्यथा पुढील रीबूट जुना विश्वास पुनर्संचयित करेल। मागील कॉन्फिगरेशनची उपकरणाबाहेर ठेवलेली प्रत हा तुम्हाला मिळणारा सर्वात स्वस्त रोलबॅक आहे।

नेटवर्क वाढताच सदस्यत्व आणि नियमांचा हेतू दस्तऐवजीत करा। नव्याने जोडलेल्या इंटरफेसला कुणी सोयीचे झोन नाव दिले म्हणून विशेषाधिकार वारसाहक्काने मिळू नयेत।