VPN क्लाइन्ट र LAN: कहिले छुट्टै जोन प्रयोग गर्ने

टनेल इन्टरफेसलाई LAN जोनमा राख्नु काम गर्ने VPN सम्मको सबैभन्दा छोटो बाटो हो, र सामान्यतया यो गलत पूर्वनिर्धारित हो। यसले टाढाको क्लाइन्टलाई तारयुक्त LAN सँग भएको जत्तिकै विश्वास दिन्छ, जुन कामले विरलै माग्छ। छुट्टै जोनमा केही नियमहरूको लागत पर्छ र सीमा देखिने बनाउँछ। निर्णय जोन राम्रा छन् कि छैनन् भन्ने होइन; तपाईंको नेटवर्कमा कुन तीन सर्तहरू लागू हुन्छन् भन्ने हो।

जोनको नामले केही पनि इन्क्रिप्ट गर्दैन र प्रयोगकर्तालाई प्रमाणित गर्दैन। यसले फायरवालको नीति मोडेलका लागि इन्टरफेसहरू मात्र समूहबद्ध गर्छ।

जोन सदस्यताले वास्तवमा के नियन्त्रण गर्छ

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

VPN जोनबाट LAN जोनमा दिइएको अनुमति स्वतः उल्टो अनुमति होइन। फर्वार्डिङ नियमहरू दिशात्मक हुन्छन्, र क्लाइन्टदेखि सर्भरतर्फको ट्राफिकलाई अनुमति दिने नियमले सर्भरदेखि क्लाइन्टतर्फका सत्रहरूलाई अनुमति दिँदैन। सर्भरसँग जडान खोल्न सक्ने क्लाइन्ट त्यस्तो क्लाइन्ट होइन जसतर्फ सर्भरले फर्केर जडान खोल्न सक्छ।

यही भिन्नता छुट्टै जोन उपयोगी हुनुको कारण हो: तपाईं हरेक दिशा र हरेक भूमिका स्पष्ट रूपमा भन्न सक्नुहुन्छ। हरेक नियमको छेउमा दिशा लेख्नुहोस्।

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

यदि टाढाका क्लाइन्टलाई राउटरबाट DNS चाहिन्छ भने त्यो सेवाका लागि मात्र इनपुट अनुमति दिनुहोस्। यदि उनीहरूले फाइल सर्भरसम्म पुग्नुपर्छ भने त्यो गन्तव्यतर्फ फर्वार्ड अनुमति दिनुहोस्। अधिकांश VPN डिजाइनलाई दुवै चाहिन्छ, तर फरक-फरक सेवाका लागि।

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

दोस्रो निर्णय: टाढाका क्लाइन्टलाई कुन स्रोत चाहिन्छ

नियम लेख्नु अघि क्लाइन्ट दायराहरू, गन्तव्यहरू र VPN ले दिनुपर्ने सेवाहरू सूचीबद्ध गर्नुहोस्। गन्तव्यको सूची विश्वासको लेबलभन्दा उपयोगी हुन्छ, किनभने यो फायरवाल स्थानान्तरणमा टिकिरहन्छ।

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

यदि अनुमति दिइएको गन्तव्यले अगाडि फर्वार्ड गर्न सक्छ भने जोनको सीमा फायरवालमै रोकिन्छ, गन्तव्यले त्यसपछि के गर्छ त्यहाँ होइन।

तेस्रो निर्णय: सीमा कसरी प्रमाणित गर्नुहुनेछ

हरेक परिवर्तनपछि अनुमति दिइएको प्रवाह र जानाजान अस्वीकृत प्रवाह परीक्षण गर्नुहोस्। एउटा वेबसाइट लोड हुन्छ भनी प्रमाणित गर्नाले अनायासै फराकिलो अनुमति खुलासा गर्दैन। VPN क्लाइन्टको ठेगाना दायराबाट परीक्षण गर्नुहोस्, LAN बाट होइन, र असफल हुने अपेक्षा गरिएको दिशा पनि समावेश गर्नुहोस्। दुवै नतिजा नियमको छेउमा लेख्नुहोस्।

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

नेटवर्क बढ्दै जाँदा सदस्यता र नियमहरूको उद्देश्य कागजातमा उतार्नुहोस्। नयाँ जोडिएको इन्टरफेसले कसैले सुविधाजनक जोन नाम दियो भनेर मात्र विशेषाधिकार वंशानुगत रूपमा पाउनु हुँदैन।