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 तैनाती हो या संचालन स्क्रिप्ट, और फिर सामान्य पुनः कनेक्शन तथा रीबूट के बाद दोबारा जाँचें: सामान्य विफलता पुराना स्थानीय रूट या एक बार लागू प्रोफ़ाइल है। प्रोफ़ाइल संस्करण जाँच परिणाम के पास रखें।