टनल चालू है, खाता डोमेन के विरुद्ध प्रमाणित हो चुका है, और Windows अब भी कनेक्शन को सार्वजनिक के रूप में लेबल करता है। इसलिए डोमेन प्रोफ़ाइल के लिए लिखा गया फ़ायरवॉल नियम लागू नहीं होता, और फ़ाइल शेयर पहुँच से बाहर रहता है। सुधार का सामान्य प्रयास अडैप्टर को निजी पर सेट करना है, जो यह बदलता है कि कौन-से नियम लागू होंगे, पर प्रमाणन में कुछ नहीं बदलता। लेबल और सुधार दोनों को व्यापक रूप से गलत समझा जाता है, और उन्हें अलग करने के लिए तीन कमांड चाहिए।

जो खाता कनेक्ट हुआ वह नेटवर्क की श्रेणी नहीं है

VPN कनेक्शन के दौरान दो अलग निर्णय होते हैं और उन्हें मिलाना आसान है। गेटवे तय करता है कि खाता कनेक्ट हो सकता है या नहीं। Windows तय करता है कि परिणामी नेटवर्क को कैसे वर्गीकृत किया जाए, और यही वर्गीकरण तय करता है कि इंटरफ़ेस पर कौन-से फ़ायरवॉल नियम लागू होंगे।

गेटवे पर सफल डोमेन प्रमाणन खाते के बारे में साक्ष्य है। यह इस बात का साक्ष्य नहीं है कि एंडपॉइंट ने नेटवर्क को डोमेन नियंत्रक के विरुद्ध प्रमाणित किया है, और डोमेन श्रेणी ठीक यही दर्शाती है।

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

तीन श्रेणियाँ, जिनमें से एक आप सेट नहीं कर सकते

Windows तीन श्रेणियाँ दिखाता है और उनमें से केवल दो ही व्यवस्थापक द्वारा निर्धारित की जा सकती हैं। तीसरी ऑपरेटिंग सिस्टम तय करता है, नेटवर्क को डोमेन नियंत्रक के विरुद्ध सफलतापूर्वक प्रमाणित करने के बाद।

CategoryHow it is assignedWhat it affects
PublicDefault for unidentified networks, or set manuallyRules scoped to the public profile
PrivateSet manually, or by the user on a trusted networkRules scoped to the private profile
DomainAuthenticatedDetermined by Windows after domain authenticationRules scoped to the domain profile
Get-NetConnectionProfile | Select-Object Name,InterfaceAlias,NetworkCategory,IPv4Connectivity
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory Private
Set-NetConnectionProfile -InterfaceAlias 'Corp VPN' -NetworkCategory DomainAuthenticated

तीसरा कमांड विफल होता है, और यह प्रलेखित व्यवहार है, अनुमति की समस्या नहीं। कमांड का संदर्भ स्वयं कहता है कि डोमेन श्रेणी इस तरह निर्धारित नहीं की जा सकती, क्योंकि Windows इसे डोमेन प्रमाणन से निकालता है। त्रुटि देखना इस बात की उपयोगी पुष्टि है कि श्रेणी परिणाम है, सेटिंग नहीं।

पहला कमांड उस एंडपॉइंट पर पढ़ें जिसका ट्रैफ़िक अवरुद्ध है। गेटवे के अपने इंटरफ़ेस का वर्गीकरण आपको इस बारे में कुछ नहीं बताता कि हर कनेक्ट होने वाला वर्कस्टेशन अपनी टनल को कैसे वर्गीकृत करता है।

नियम उस प्रोफ़ाइल का पालन करते हैं जिसके लिए लिखे गए

श्रेणी जानने के बाद, अनुपस्थित पहुँच प्रायः स्वयं स्पष्ट हो जाती है। हर Windows Firewall नियम एक प्रोफ़ाइल-परिसर रखता है, और डोमेन पर सीमित नियम तब लागू नहीं होता जब इंटरफ़ेस सार्वजनिक हो। तीन कमांड इसे सिद्धांत के बजाय उत्तर बनाते हैं, और तीसरा वह स्थिति पकड़ता है जहाँ प्रोफ़ाइल कभी समस्या नहीं थी:

(Get-NetFirewallRule -DisplayName 'Allow File Share').Profile
Get-NetFirewallRule -DisplayName 'Allow File Share' | Get-NetFirewallAddressFilter
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

दूसरा कमांड वह है जो अस्पष्ट रिपोर्ट को समाधान में बदलता है। यदि नियम दूरस्थ पतों की ऐसी श्रेणी पर सीमित है जिसमें VPN पूल शामिल नहीं है, तो प्रोफ़ाइल बदलने से भी मदद नहीं मिलेगी।

डिफ़ॉल्ट इनबाउंड क्रिया भी जाँचें। ऐसी मशीन पर जहाँ इनबाउंड डिफ़ॉल्ट रूप से अवरुद्ध है, अनुपस्थित अनुमति नियम अस्वीकृति के बजाय मौन उत्पन्न करता है। क्लाइंट की ओर से यह रूटिंग विफलता जैसा ही दिखता है, और इसीलिए इनमें से कई टिकट गलत अनुमान से शुरू होते हैं।

निर्धारित करें कौन-सी मशीन नियम लागू करती है

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

क्लाइंट से विशिष्ट पोर्ट तक जाँचें, फिर उसी VPN पर किसी अन्य होस्ट से जाँच से तुलना करें। यदि दोनों विफल हों, समस्या गंतव्य पर या मार्ग पर है। यदि केवल एक विफल हो, अंतर उस मशीन के लिए स्थानीय है, और प्रोफ़ाइल श्रेणी संभावित कारण बन जाती है।

दिशा भी ध्यान में रखें। इनबाउंड SMB की अनुमति देने वाला नियम ऐसे क्लाइंट के लिए कुछ नहीं करता जिसका अपना आउटबाउंड नियम वही ट्रैफ़िक अवरुद्ध करता है। फ़ाइल एक्सप्लोरर विंडो से दोनों विफलताएँ अलग नहीं की जा सकतीं, इसलिए कुछ भी संपादित करने से पहले हर दिशा की अलग जाँच करें।

सब कुछ फिर से लेबल करने के बजाय क्या करें

विस्तृत नियम को संतुष्ट करने के लिए किसी अपरिचित नेटवर्क को निजी बनाना वास्तविक परिणामों वाला वास्तविक परिवर्तन है। निजी प्रोफ़ाइल आमतौर पर सार्वजनिक से अधिक खोज और अधिक इनबाउंड ट्रैफ़िक की अनुमति देती है।

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

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

Get-CimInstance Win32_ComputerSystem | Select-Object PartOfDomain,Domain
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.com

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

संबंधित लेख