सानो कार्यालयको VPN: यसलाई डोमेन कन्ट्रोलरबाट टाढा राख्नुहोस्

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

डोमेनको हरेक मेसिनले डोमेन कन्ट्रोलरमा भरोसा गर्छ; VPN गेटवेमा इन्टरनेटमा जो कोही पुग्न सक्छ। त्यो असमानता नै सम्पूर्ण तर्क हो।

दुई फरक एक्सपोजर प्रोफाइल भएका दुई काम

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

भूमिकाहरू अलग गर्नाले निर्भरताहरू हट्दैनन्। टाढाका प्रयोगकर्ताहरूलाई अझै प्रमाणीकरण, मार्ग, DNS र पहुँच नियम चाहिन्छ, र ती छोड्ने गेटवे बढी सुरक्षित होइन, केवल कम उपयोगी।

डाइरेक्टरी भूमिकाबिना प्रमाणीकरण

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

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

एउटा होस्ट अझै एउटा असफलता डोमेन हो

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

त्यसैले सुरुङमा निर्भर नहुने स्वतन्त्र व्यवस्थापन मार्ग योजना गर्नुहोस्, र मर्मतका क्रममा के उपलब्ध रहन्छ लेख्नुहोस्। गेटवे अद्यावधिक र डाइरेक्टरी मर्मत छुट्टाछुट्टै तालिका बनाउनुहोस्, प्रत्येक अवरोधले कुन प्रयोगकर्ता वा अनुप्रयोगलाई छुन्छ भनी टिप्नुहोस्।

VPN मर्मत गर्न VPN सक्रिय हुनुपर्ने मर्मत विन्डो मर्मत विन्डो होइन।

बाहिर ताला नलगाई यसलाई सार्नुहोस्

यदि भूमिकाहरूले पहिल्यै एउटा इन्स्टलेसन साझा गर्छन् भने हतारको टाढा माइग्रेसनबाट बच्नुहोस्। गेटवेसँग आज के छ सूची बनाउनुहोस्: ठेगाना, फर्वार्डिङ नियम, NAT, DNS सेटिङ, प्रमाणीकरण कन्फिगरेसन र प्रकाशित सेवाहरू। श्रोता सार्नु वा पूर्वनिर्धारित मार्ग बदल्नुअघि प्रतिस्थापन र फर्कने बाटो दुवै तयार गर्नुहोस्। त्यसपछि नयाँ सीमाबाट साधारण टाढाको प्रयोगकर्ताको वास्तविक काम परीक्षण गर्नुहोस्, र अनावश्यक प्रशासनिक पहुँच अझै असफल हुन्छ भनी पुष्टि गर्नुहोस्।

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

निर्णय जसरी पनि अभिलेख गर्नुहोस्, यसलाई फेरि खोल्न सक्ने सर्तहरू सहित। सानो कार्यालय बढ्छ, र एउटा सर्भरमा मिलेको उत्तर अर्कोमा नमिल्न सक्छ।