VPN प्रयोगकर्ताहरूलाई सबनेटमा होइन, एउटा सेवामा पहुँच दिनुहोस्

एक ठेकेदारलाई एउटा आन्तरिक वेब अनुप्रयोग चाहिन्छ र अरू केही होइन, र सजिलो उत्तर उसलाई सर्भर सबनेटमा एउटा सुरुङ दिनु हो। त्यो उसले यसलाई स्क्यान गर्ने दिनसम्म काम गर्छ। साँघुरो डिजाइनले बढी सोच चाहन्छ, किनकि पहुँच, राउटिङ र अनुप्रयोग अनुमति तीन अलग नियन्त्रण हुन् जुन मिल्नुपर्छ।

आवश्यकता सबनेटको रूपमा होइन, सेवाको रूपमा लेख्नुहोस्

गन्तव्य होस्ट, प्रोटोकल र पोर्टबाट सुरु गर्नुहोस्, त्यसपछि त्यहाँ पुग्नुपर्ने प्रयोगकर्ता वा यन्त्र समूह थप्नुहोस्। निजी DNS क्षेत्र अनुप्रयोगले नाम समाधान गर्छ भने मात्र समावेश गर्नुहोस्, र पहिचान प्रदायक साइन-इन प्रवाहलाई आवश्यक भए मात्र समावेश गर्नुहोस्। बाँकी सबै तपाईंले अझै न्यायोचित नठहराउनुभएको निर्भरता हो।

सबनेट नेटवर्क टोलीको कार्यान्वयन विवरण हो, जबकि सेवा व्यवसायले मागेको कुरा र समीक्षा गरी बन्द गर्न सकिने इकाई हो।

यदि निर्भरता सूची तीन वस्तुभन्दा बढी हुन्छ भने, अनुप्रयोगलाई सम्भवतः आफ्नै डिजाइन छलफल चाहिन्छ।

साँघुरो रूपमा राउट गर्नुहोस्, तर कार्यान्वयन अन्तै गर्नुहोस्

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

यसको विपरीत, कडा फिल्टरसहितको फराकिलो मार्ग वैध हुन सक्छ, तर सम्बद्ध सबैले दुईमध्ये कुनले कार्यान्वयन गर्छ भन्ने थाहा पाए मात्र।

कार्यान्वयन बिन्दु स्पष्ट रूपमा अभिलेख गर्नुहोस्, नत्र अर्को परिवर्तनले यसलाई दुर्घटनावश सार्नेछ।

सेवाले वास्तवमा कुन स्रोत देख्छ त्यो जाँच्नुहोस्

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

अनुवाद जानाजान छान्नुहोस्: यसले राउटिङ सरल बनाउँछ र स्रोतको पहिचान नष्ट गर्छ, जुन लेखापरीक्षण र प्रति-प्रयोगकर्ता नियमका लागि महत्त्वपूर्ण छ।

दुईमध्ये कुन छान्नुभयो त्यो यसमा निर्भर नियमको छेउमा लेख्नुहोस्।

अनुप्रयोग अनुमति वैकल्पिक होइन

पोर्टमा पुग्नुले भूमिका दिँदैन। अनुप्रयोगलाई अझै आफ्नै लगइन र आफ्नै अनुमति चाहिन्छ, किनकि नेटवर्क तहले प्रयोगकर्ताले कुन रेकर्ड सम्पादन गर्न सक्छ भन्ने व्यक्त गर्न सक्दैन। आन्तरिक सबनेटबाट आउने हरेक अनुरोधमा भरोसा गर्ने सेवाले साँघुरो सुरुङलाई एक सम्झौता भएको प्रमाणपत्रका लागि पूर्ण पहुँचमा बदल्छ। सुरुङले को सकेट खोल्न सक्छ भनेर निर्धारण गर्छ, र अनुप्रयोगले त्यससँग के गर्न सकिन्छ भनेर निर्धारण गर्छ।

यहीँ साँघुरो डिजाइन दोब्बर फल दिन्छ, किनकि कम पहुँचयोग्य होस्ट भनेको अनुप्रयोग-स्तरको गल्ती दुरुपयोग गर्न सकिने कम ठाउँ।

नेटवर्क नियम र अनुप्रयोग भूमिका अलग प्रणालीमा राख्नुहोस्, र तिनलाई अलग बन्द गर्नुहोस्।

अनुमत र अस्वीकृत दुवै मार्ग प्रमाणित गर्नुहोस्

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

स्वीकृति परीक्षण पास गराउन फर्वार्डिङ फिल्टर बन्द नगर्नुहोस्, किनकि त्यसले परीक्षण गरिँदै गरेको कुरा नै बदल्छ।

प्रयोगकर्तालाई सेवाको आवश्यकता नरहेपछि, दूरस्थ पहिचान र अनुप्रयोग भूमिका तिनका सम्बन्धित प्रणालीमा बन्द गर्नुहोस्, र दुवै अभिलेख गर्नुहोस्। strongSwan फर्वार्डिङ गाइड मार्गको गेटवे पक्ष समेट्छ।