जब रिमोट-पहुँच ग्राहकले शाखा गेटवेको भूमिका खेल्नुपर्छ

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

प्रोटोकल लेबलले तपाईंलाई के बताउँदैन

OpenVPN कनेक्टरले पूरै सबनेट फर्वार्ड गर्ने साइट-देखि-साइट डिजाइनको दस्तावेजीकरण गर्छ, र Access Server ले त्यसलाई गेटवे भूमिका र स्पष्ट राउटिङसहित लागू गर्छ। SSL VPN का रूपमा बेचिएको अर्को उत्पादनले ग्राहकको पछाडिको नेटवर्क घोषणा गर्ने समर्थित तरिका बिना मात्र रिमोट-प्रयोगकर्ता कार्यहरू दिन सक्छ। संस्करण पनि महत्त्वपूर्ण छ, किनकि एउटा संस्करणको सुविधा अर्कोको बारेमा वाचा होइन। तपाईंले वास्तवमै चलाउनुहुने कार्यान्वयन पढ्नुहोस्, र अर्को उत्पादनका लागि लेखिएको विधिलाई डिजाइन नभई संकेत मान्नुहोस्।

पहिले टुंगो लगाउनुपर्ने प्रश्न यो हो कि VPN को मालिकले फर्वार्डिङ भूमिका नै समर्थन गर्छ कि गर्दैन। नगरेमा, ग्राहक-पक्षको कुनै पनि राउटिङले यसलाई समर्थित बनाउँदैन।

सम्झौताका दुई पक्ष छन्: शाखा र मुख्य कार्यालय

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

फर्कने मार्ग त्यो भाग हो जुन छोडिन्छ। ग्राहकका लागि सुरुङ ठेगानाले यसको पछाडिको सबनेट घोषणा गर्दैन, त्यसैले मुख्य कार्यालयका राउटरहरूलाई त्यो प्रिफिक्सका लागि VPN गेटवेतर्फ देखाउने मार्ग चाहिन्छ।

राउट गरिएको डिजाइनमा, केन्द्रकले शाखा प्रिफिक्सका प्याकेट फर्वार्ड गर्छ र माथिल्लो LAN को राउटिङलाई जवाफ कसरी फर्काउने भन्ने थाहा हुन्छ। अनुवादित डिजाइनमा, मुख्य कार्यालयले देख्ने स्रोत पुनःलेखिन्छ, जसले एउटा फर्कने मार्गको आवश्यकता हटाउन सक्छ तर कुन शाखा मेसिनले ट्राफिक पठायो भन्ने लुकाउँछ। त्यो सम्झौता डिजाइन कागजातमा पर्छ, किनकि अनुवाद सुरु हुनासाथ अनुप्रयोग लग र पहुँच नियमहरूले प्रति-उपकरण पहिचान गुमाउँछन्।

राउट गरिएको वा अनुवादित: फर्कने मार्ग सचेत रूपमा छान्नुहोस्

प्रति-उपकरण पहिचान र प्रति-होस्ट नीति महत्त्वपूर्ण हुँदा र प्रत्येक सान्दर्भिक राउटरमा फर्कने मार्ग कायम राख्न सक्दा राउट गरिएको छान्नुहोस्।

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

उपयोगी जाँच असममित हुन्छ: शाखा उपकरणबाट स्रोत माग्नुहोस्, त्यसपछि जवाफ मुख्य कार्यालय छोडेर शाखा प्रिफिक्सतर्फ जान्छ भनी पुष्टि गर्नुहोस्। traceroute -n 10.60.4.20 मुख्य कार्यालयको होस्टबाट त्यो मार्ग VPN गेटवेबाट जान्छ कि जाँदैन देखाउँछ।

यसलाई लगइनजस्तो नभई पूर्वाधारजस्तो चलाउनुहोस्

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

यो व्यवस्थालाई समर्थित साइट गेटवेसँग समान आवश्यकतामा तुलना गर्नुहोस्, त्यसपछि प्रतिबद्ध हुनुहोस्। पुरानो डेस्कटप पुनःप्रयोग गर्दा मर्मत वा पुनःप्राप्तिको काम हट्दैन, र दोस्रो हातको मूल्यले परिचालन लागत वर्णन गर्दैन।

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