VPN पर ग्रुप पॉलिसी गायब है? टनल से पहले दायरा जाँचें
VPN रास्ता देता है, नीति नहीं। किसी गायब सेटिंग के लिए टनल को दोष देने से पहले दायरा, डोमेन का DNS रास्ता और रीफ़्रेश का नतीजा जाँचें।
ऑफ़िस नेटवर्क पर जो लागू हुआ करता था, वह उसी हफ़्ते लागू होना बंद कर देता है जब कोई उपयोगकर्ता VPN से काम शुरू करता है, और कोई रिपोर्ट खोलने से पहले ही टनल को दोष मिल जाता है। ग्रुप पॉलिसी तय करती है कि कौन-सी सेटिंग्स Windows उपयोगकर्ता और कंप्यूटर तक पहुँचती हैं, डोमेन से सामग्री लाती है और क्लाइंट पक्ष की प्रक्रिया चलाती है, और ये तीन चरण तीन अलग तरीक़ों से विफल होते हैं। टनल केवल बदलता है कि क्लाइंट के पास कौन-सा रास्ता है। जाँचों को क्रम से करने पर फ़ाइल-अनुमति की समस्या को राउटिंग समस्या मानकर पीछे नहीं भागा जाता।
सेटिंग से शुरू करें, टनल से नहीं
एक अपेक्षित GPO और उसके भीतर की एक ठोस सेटिंग लिखें, फिर तय करें कि वह सेटिंग उपयोगकर्ता कॉन्फ़िगरेशन में है या कंप्यूटर कॉन्फ़िगरेशन में। यह मानता है स्वीकृत VPN पर डोमेन से जुड़ा एक अधिकृत Windows क्लाइंट, न कि कोई अनियंत्रित या केवल क्लाउड डिवाइस जिसे डोमेन सदस्य बनाया जा रहा है। दायरे का उत्तर तय करता है कि नतीजा कौन पढ़ सकता है और क्या अनुमति बढ़ाना ज़रूरी है, इसलिए कुछ भी चलाने से पहले इसे तय कर लें।
डोमेन व्यवस्थापक से पूछें कि कौन-सा लिंक, ऑब्जेक्ट स्थान, सुरक्षा फ़िल्टर और WMI फ़िल्टर काम में होने चाहिए। परीक्षण पास कराने के लिए इन नियंत्रणों को बदलना दूसरे स्वामी वाली दूसरी परियोजना है।
रिपोर्ट उसी खाते से पढ़ें जिसका यह सेटिंग है
प्रभावित उपयोगकर्ता के अपने सत्र में whoami /user और फिर gpresult /scope user /r चलाएँ। जिस खाते ने VPN का प्रमाणन किया वह अपने आप वह Windows खाता नहीं है जिसकी नीति आप पढ़ रहे हैं, और व्यवस्थापक खाते से की गई जाँच किसी दूसरे प्रश्न का उत्तर देती है। बेसलाइन को नए फ़ाइल नाम से सहेजें, जैसे %TEMP%\vpn-policy-user-before.html. gpresult संदर्भ दायरे और आउटपुट के स्विच बताता है, और यह जानना उपयोगी है कि रिपोर्ट बनाने से कुछ भी रीफ़्रेश नहीं होता।
कंप्यूटर नीति का अपना दायरा और अनुमति संदर्भ है, इसलिए उसे ज़रूरी अनुमति बढ़ाकर अलग जाँचें। दोनों दायरों को एक रिपोर्ट में मिला देना ही वह तरीक़ा है जिससे उपयोगकर्ता सेटिंग गायब घोषित हो जाती है जबकि वह कभी उस दायरे में थी ही नहीं।
खोज पहुँच नहीं है: पहले SRV रिकॉर्ड, फिर SMB
स्वीकृत VPN जुड़ा होने पर पुष्टि करें कि क्लाइंट डोमेन नियंत्रकों को इच्छित DNS रास्ते से हल करता है; लोड होती कोई सार्वजनिक वेबसाइट नियंत्रक-खोज के बारे में कुछ नहीं बताती। उदाहरण डोमेन corp.example के लिए nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example उस प्रश्न का उत्तर देता है जो वास्तव में आपके पास है। लौटाया गया सेवा रिकॉर्ड केवल खोज का प्रमाण है, क्योंकि चुने गए नियंत्रक का पता अब भी अपेक्षित प्रमाणीकरण और अनुमत डिरेक्टरी सेवाओं के साथ पहुँचने योग्य होना चाहिए। इसके बाद नीति की सामग्री SYSVOL से आती है, जो उसी विशिष्ट नियंत्रक के विरुद्ध SMB पठन है और ICMP परीक्षण नहीं।
कमज़ोर प्रमाण को प्रमाण समझ लेना आसान है। किसी नियंत्रक का ICMP उत्तर, नीति टेम्पलेट के अस्वीकृत पठन के साथ, ऐसी रिपोर्ट बनाता है जो किसी ऐसे कारण से खाली दिखती है जिसे अभी किसी ने जोड़ा नहीं है।
तैनाती की AD सेवा अनुमतियाँ, वापसी रास्ते और समय-तुल्यकालन सुसंगत रखें, उन्हें व्यापक फ़ायरवॉल खोलने या सार्वजनिक DNS सर्वर से बदलने के बजाय। नियंत्रकों के बीच अलग होता नीति डेटा डिरेक्टरी स्वामी के लिए प्रतिकृति का प्रश्न है।
एक रीफ़्रेश, दो रिपोर्ट, एक तुलना
रास्ता सिद्ध होने पर संबंधित रीफ़्रेश gpupdate /target:user से माँगें और परिणाम मान लेने के बजाय पढ़ें। डिफ़ॉल्ट रीफ़्रेश बदली नीति लागू करता है जबकि /force पुनः लागू करने का अनुरोध करता है; इनमें से कोई DNS, फ़ाइल अनुमतियाँ या फ़िल्टरिंग ठीक नहीं करता। कुछ एक्सटेंशन केवल बाद के साइन-इन या किसी अन्य फ़ोरग्राउंड घटना पर पूरे होते हैं, इसलिए एक बार चलाना फ़ैसला नहीं है। दूरस्थ उपयोगकर्ता के सत्र में लॉगऑफ़ या रीबूट स्विच नियमित निदान के रूप में जोड़ना उसका खुला हुआ सब कुछ फेंक देता है।
दूसरे फ़ाइल नाम से दूसरी रिपोर्ट बनाएँ और प्रोसेसिंग समय, अपेक्षित GPO, उसकी लागू या अस्वीकृत स्थिति और सेटिंग की तुलना करें। पहले के सफल सत्र की रिपोर्ट इस रीफ़्रेश के बारे में कुछ सिद्ध नहीं करती। फ़िल्टर होकर बाहर हुई नीति परिवहन के बजाय लागू होने की ओर इशारा करती है, जो बदल देता है कि अगला कदम किसका है।
विफलता को एक ही गतिविधि से बाँधें
इवेंट व्यूअर में सिस्टम लॉग में ग्रुप पॉलिसी चेतावनी या त्रुटि से शुरू करें, फिर अनुप्रयोग और सेवा लॉग के अंतर्गत GroupPolicy परिचालन लॉग पर जाएँ। उस परिचालन लॉग को अभी चलाए गए रीफ़्रेश की गतिविधि पहचानकर्ता से फ़िल्टर करें, क्योंकि नया रीफ़्रेश नई पहचान प्राप्त करता है और उसे कल की घटनाओं के साथ मिलाने से आत्मविश्वासी पर ग़लत निष्कर्ष निकलता है। समय, उपयोगकर्ता या कंप्यूटर संदर्भ, चुना गया नियंत्रक, GPO, त्रुटि कोड और विफल निर्भरता दर्ज करें।
यही रिकॉर्ड वह है जिस पर नेटवर्क या डिरेक्टरी स्वामी कार्य कर सकता है। VPN से जुड़ा होना और gpupdate कई बार चलाना प्रमाण नहीं हैं, और इनमें से कोई भी हस्तांतरण में नहीं टिकता।
HTML रिपोर्ट निजी रखें, क्योंकि वे आंतरिक नाम, समूह सदस्यता और सुरक्षा कॉन्फ़िगरेशन उजागर करती हैं। सेटिंग की पुष्टि होने पर जोड़ी गई अस्थायी अनुमतियाँ यथावत रखने के बजाय हटा दें।