Visual Studio सिर्फ़ VPN पर धीमा? CRL और OCSP जाँचें

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

लॉन्च नहीं, फ़ेच का समय मापें

एक WDAC नीति, जो हस्ताक्षरित SiPolicy.p7b के रूप में तैनात होती है, तय करती है कि मशीन पर कौन-सी इमेज चल सकती हैं। कोड अखंडता निष्पादन से पहले इमेज की हस्ताक्षर श्रृंखला का सत्यापन करती है, और उस सत्यापन में निरसन का प्रश्न शामिल हो सकता है। उत्तर CRL वितरण बिंदु या उस OCSP प्रतिवादी पर निर्भर करता है जिसका नाम प्रमाणपत्र अपने भीतर देता है।

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

हर हस्ताक्षरित इमेज नेटवर्क कॉल शुरू कर सकती है

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

certutil -verify -urlfetch C:\Tools\Contoso.Editor.dll
nslookup ocsp.contoso.example
Test-NetConnection ocsp.contoso.example -Port 80

आउटपुट श्रृंखला, CRL और OCSP पते और यह सूचीबद्ध करता है कि हर फ़ेच सफल हुआ या नहीं। जो प्रतिवादी टनल पर समय समाप्त करता है और उसके बाहर उत्तर देता है, वही वह सबूत है जिसकी आपको आवश्यकता है, और यह धीमेपन के अनुभव से कहीं अधिक महत्व रखता है। यदि फ़ेच धीरे-धीरे सफल होता है, तो पता नोट करें ताकि अगला चरण उस होस्ट को सीधे परख सके।

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

नियंत्रण हटाए बिना देरी कम करें

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

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

परिवर्तन के बाद कोल्ड स्टार्ट सत्यापित करें

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

Get-WinEvent -LogName Microsoft-Windows-CodeIntegrity/Operational -MaxEvents 40 |
  Where-Object { $_.TimeCreated -gt (Get-Date).AddMinutes(-10) }
Get-ChildItem C:\Windows\System32\CodeIntegrity\CiPolicies\Active
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

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