तुमचा VPN अ‍ॅडॉप्टर सार्वजनिक फायरवॉल प्रोफाइलवर का राहतो
डोमेनमध्ये साइन-इन केल्याने नेटवर्क डोमेन म्हणून वर्गीकृत होत नाही, आणि खाजगी हा पर्याय नाही। आधी नियमाचे प्रोफाइल वाचा, नंतर तो लागू करणारे मशीन।
टनेल सुरू आहे, खाते डोमेनविरुद्ध प्रमाणित झाले आहे, तरीही Windows कनेक्शनला सार्वजनिक असे लेबल करते। त्यामुळे डोमेन प्रोफाइलसाठी लिहिलेला फायरवॉल नियम लागू होत नाही, आणि फाइल शेअर पोहोचाच्या बाहेर राहतो। सुधारणेचा नेहमीचा प्रयत्न अ‍ॅडॉप्टर खाजगी वर सेट करणे हा आहे, ज्यामुळे कोणते नियम लागू होतात ते बदलते पण प्रमाणीकरणात काहीच बदलत नाही। लेबल आणि सुधारणा दोन्ही व्यापकपणे चुकीच्या पद्धतीने समजली जातात, आणि त्या वेगळे करण्यासाठी तीन आदेश लागतात।
कनेक्ट झालेले खाते नेटवर्कची श्रेणी नाही
VPN कनेक्शन दरम्यान दोन वेगळे निर्णय घेतले जातात आणि ते गोंधळवणे सोपे आहे। गेटवे खाते कनेक्ट होऊ शकते का हे ठरवते। Windows परिणामी नेटवर्कचे वर्गीकरण कसे करायचे हे ठरवते, आणि तेच वर्गीकरण इंटरफेसवर कोणते फायरवॉल नियम लागू होतील हे निर्धारित करते।
गेटवेवर यशस्वी डोमेन प्रमाणीकरण हे खात्याबद्दलचा पुरावा आहे। एंडपॉइंटने नेटवर्क डोमेन कंट्रोलरविरुद्ध प्रमाणित केले असा पुरावा नाही, आणि डोमेन श्रेणी नेमके तेच दर्शवते।
म्हणूनच मशीन डोमेन-जॉइंड असू शकते, डोमेन खात्याने कनेक्ट होऊ शकते आणि तरीही सार्वजनिक दाखवू शकते। वर्गीकरण हे नेटवर्कबद्दलचे स्थानिक निर्धारण आहे, टनेल उघडणाऱ्या क्रेडेन्शियल्सबद्दलचे विधान नाही। खाते पूर्णपणे वैध असू शकते आणि लेबल जिथे सुरू झाले तिथेच राहू शकते।
तीन श्रेणी, त्यातील एक तुम्ही सेट करू शकत नाही
Windows तीन श्रेणी दाखवते आणि त्यातील फक्त दोनच प्रशासक नियुक्त करू शकतो। तिसरी ऑपरेटिंग सिस्टम नेटवर्क डोमेन कंट्रोलरविरुद्ध यशस्वीपणे प्रमाणित केल्यानंतर ठरवते।
| Category | How it is assigned | What it affects |
|---|---|---|
| Public | Default for unidentified networks, or set manually | Rules scoped to the public profile |
| Private | Set manually, or by the user on a trusted network | Rules scoped to the private profile |
| DomainAuthenticated | Determined by Windows after domain authentication | Rules 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ते तीन एंडपॉइंट नेटवर्कला प्रमाणित करू शकला असता का याचे उत्तर देतात। जर तो कंट्रोलरपर्यंत पोहोचू शकत नसेल, तर डोमेन श्रेणी कधीच नियुक्त होणार नाही, अ‍ॅडॉप्टर कितीही वेळा रीसेट केला तरी। ज्या फायरवॉल नियमाचा आपण पाठलाग करत होते तो कधीच खरी समस्या नव्हता, आणि लेबल कारण नव्हते तर तुटलेल्या मार्गाचे लक्षण होते।