Always On VPN ल्यान पहुँच होइन: स्रोत जाँचसूची

Always On जडानको जीवनचक्र हो: प्रोफाइल साइन-इनको समयमा वा त्यसअघि जोडिन्छ र प्रयोगकर्ताले केही नथिचीकनै फेरि जोडिन्छ। यसको अर्थ हरेक निजी गन्तव्य, प्रोटोकल र प्रयोगकर्तालाई अनुमति छ भन्ने होइन। वास्तविक प्रश्न यो हो कि तैनाथ प्रोफाइलले साँच्चै कुन स्रोतहरू पुर्‍याउँछ, र त्यो उत्तरका लागि Connected ब्याज हेर्नुको सट्टा हरेक स्रोतको छुट्टै जाँच चाहिन्छ।

चरण 1: जाँच्नुअघि स्रोत लेख्नुहोस्

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

Name: portal.corp.example
Destination: 10.20.5.0/24
Service: HTTPS 443
Tunnel role: user access after sign-in
Identity: assigned employee group
Resolver: corporate private DNS

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

चरण 2: कुन टनेलले बोक्नुपर्ने निर्धारण गर्नुहोस्

Windows Always On VPN मा यन्त्र टनेल र प्रयोगकर्ता टनेल छन्, जुन छुट्टै प्रमाणपत्र र दायरासहित छुट्टै प्रोफाइलका रूपमा कन्फिगर हुन्छन्। यन्त्र टनेलले सामान्यतया साइन-इनअघि आवश्यक पूर्वाधार मात्र बोक्छ, जस्तै व्यवस्थापन र डोमेन सेवाहरू; कर्मचारीको फराकिलो एप पहुँच प्रयोगकर्ता टनेलमा पर्छ।

ट्राफिक फिल्टर यन्त्र टनेलको विशेषता हो, त्यसैले Microsoft को उदाहरणले तिनीहरूलाई व्यवस्थापन ट्राफिकमा प्रयोग गर्छ। त्यो उदाहरण सामान्य स्रोत प्रोफाइलमा प्रतिलिपि गर्दा जोडिने तर गलत समूह बोक्ने टनेल पाइन्छ। Get-VpnConnection ले सक्रिय जडान पुष्टि गर्नुहोस् र त्यही जडानमुनि जाँच गर्नुहोस्।

चरण 3: वास्तविक ठेगानाका लागि मार्ग प्रमाणित गर्नुहोस्

नाम एकचोटि समाधान गर्नुहोस्, त्यसपछि मार्ग हेर्नुहोस्: Find-NetRoute -RemoteIPAddress 10.20.5.10 ले छानिएको इन्टरफेस, अर्को हप र स्रोत ठेगाना देखाउँछ। इन्टरफेस भौतिक एडाप्टर भएमा प्रिफिक्स टनेलको मार्ग समूहमा छैन वा क्लाइन्टले विभाजित टनेलमार्फत हटाएको छ। स्थानीय मार्ग थप्नुको सट्टा प्रोफाइल परिभाषासँग तुलना गर्नुहोस्।

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

चरण 4: निजी नामको समाधान छुट्टै जाँच्नुहोस्

निजी नामका आफ्नै नीति मार्ग हुन्छन्। प्रोफाइलले NRPT नियम र DNS प्रत्यय खोज सूची दिन सक्छ, जुन टनेल खुला रहेसम्म मान्य हुन्छ। क्लाइन्टले साँच्चै के पायो Get-DnsClientNrptPolicy ले पढ्नुहोस्, त्यसपछि त्यही सत्रमा नाम र ठेगाना जाँच्नुहोस्। ठेगाना चल्ने तर नाम फेल हुने रिजोल्भरतिर संकेत गर्छ; दुवै फेल हुने मार्गतिर।

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

चरण 5: फिल्टर, पहिचान र एपकै ढोका जाँच्नुहोस्

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

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