Always On VPN म्हणजे LAN प्रवेश नाही: संसाधन तपासणी यादी

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 तैनात असो किंवा ऑपरेशन स्क्रिप्ट, नंतर सामान्य पुनर्जोडणीनंतर आणि रीबूटनंतर पुन्हा चाचणी करा: नेहमीचा अपयश जुना स्थानिक मार्ग किंवा एकदाच लागू केलेले प्रोफाइल असते. प्रोफाइल आवृत्ती चाचणी निकालाजवळ ठेवा.