VPN डिवाइस स्थिति जाँच ब्लॉक नहीं कर रही? पहले रिपोर्ट देखें
आपका एंडपॉइंट एजेंट स्वस्थ स्थिति बताता है, फिर भी आंतरिक ऐप खुलता है। संग्राहक, फ़ैसले और ब्लॉक से गुज़रें, फिर एक अनुरोध से इनकार साबित करें।
अगर ऐसा लैपटॉप जिसके एंटीवायरस हस्ताक्षर हफ़्तों पहले अपडेट होना बंद हो चुके हैं, अब भी आपका आंतरिक ऐप खोल सकता है, तो नीति दस्तावेज़ ही ग़लत चीज़ होता है, ऐसा कम ही होता है। पहुँच अस्वीकार होने से पहले तीन अलग सिस्टमों को सहमत होना पड़ता है: कोई एंडपॉइंट को मापता है, कोई उस माप को अनुमति या इनकार का फ़ैसला बनाता है, और कोई वास्तव में ट्रैफ़िक गिरा देता है। जब गैर-अनुरूप डिवाइस फिर भी अंदर आ जाता है, तो ठीक उनमें से एक कड़ी गायब होती है या ऐसे सबूत पर भरोसा कर रही होती है जिस पर नहीं करना चाहिए। नीचे दी गई जाँचें उसी क्रम में चलती हैं, और हर एक का एक रुकने का बिंदु है।
ब्लॉक आख़िरी कदम है, पहला नहीं
प्रमाणीकरण और डिवाइस की स्थिति अलग-अलग सवालों के जवाब देते हैं। सफल लॉगिन साबित करता है कि कोई क्रेडेंशियल पेश किया गया था; यह उस मशीन पर चल रहे सॉफ़्टवेयर के बारे में कुछ नहीं कहता जिसने उसे पेश किया। इसी खाई की वजह से कॉपी किया गया क्लाइंट प्रोफ़ाइल एक स्वस्थ दिखने वाला सत्र अस्वस्थ होस्ट तक ले जा सकता है।
एंडपॉइंट अनुपालन कार्य के पास इस श्रृंखला के लिए शब्दावली पहले से है। RFC 5209 में सूचनात्मक NEA संदर्भ मॉडल काम को एक संग्राहक, एक मूल्यांकन चरण और एक प्रवर्तन बिंदु में बाँटता है, और साफ़ कहता है कि जो क्लाइंट अपनी स्थिति के बारे में झूठ बोलता है वह मॉडल से बाहर है। यह चेतावनी आरेख से ज़्यादा मायने रखती है: भरोसेमंद प्लेटफ़ॉर्म मॉड्यूल स्वयं बताए गए माप को तथ्य नहीं बना देता।
संग्राहक को दायरे के बारे में ईमानदार रखें। उसे वही विशेषताएँ बतानी चाहिए जिनके नाम आपकी नीति में हैं, उस डिवाइस पर जो पहुँच माँग रहा है, और बहुत कम और कुछ। हर इंस्टॉल किए गए पैकेज की सूची बनाने वाला इन्वेंटरी एजेंट डिवाइस-स्थिति संग्राहक से अलग औज़ार है, और यह अंतर एक साथ अवधारण और सटीकता की समस्या है। अगर रिपोर्ट को एक डिवाइस पहचान से नहीं जोड़ा जा सकता, तो मूल्यांकनकर्ता अंदाज़ा लगा रहा है कि उसने अभी किस मशीन को मंज़ूरी दी।
लाल स्थिति दिखाने वाला डैशबोर्ड नियंत्रण नहीं है। पूछें कि इनकार किया गया उपयोगकर्ता अब भी कहाँ पहुँच सकता है: विकी, फ़ाइल शेयर, डेटाबेस पोर्ट? सुधार के लिए एक संकरी सतह चाहिए, और बाक़ी सब ब्लॉक के पीछे होना चाहिए।
नियम पढ़ने से पहले रिपोर्ट पढ़ें
क्लाइंट के हरे टिक से नहीं, स्रोत से शुरू करें। Windows पर स्थानीय माप Defender से आता है या उस उत्पाद से जिसने ख़ुद को Security Center में पंजीकृत किया है, और दोनों वेंडर कंसोल के बिना पढ़े जा सकते हैं:
Get-MpComputerStatus | Select-Object AMServiceEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated
Get-CimInstance -Namespace root/SecurityCenter2 -ClassName AntiVirusProduct | Select-Object displayName, productStateदूसरा कमांड productState नाम का पूर्णांक लौटाता है। इसके बिट्स ढीले ढाले तरीके से प्रलेखित हैं और वेंडर सक्रियण और ताज़गी के फ़्लैग अलग तरह से पैक करते हैं, इसलिए इसे पार्स करने के बजाय सत्यापित करें। तीसरे पक्ष के सूट अनइंस्टॉल के बाद भी Security Center प्रविष्टि छोड़ जाते हैं, और वह ऐसे सॉफ़्टवेयर की रिपोर्ट करती है जो अब डिस्क पर नहीं है।
उम्र वह क्षेत्र है जिसे लोग छोड़ देते हैं। हस्ताक्षर का टाइमस्टैम्प केवल मूल्यांकन करने वाली मशीन की घड़ी के मुक़ाबले मायने रखता है, इसलिए इसे आँख से आँकने के बजाय अंतराल में बदलें:
$sig = (Get-MpComputerStatus).AntivirusSignatureLastUpdated
[int](New-TimeSpan -Start $sig -End (Get-Date)).TotalHoursअब नीति के पास पढ़ने के लिए एक संख्या है। अगर आपका नियम 72 घंटे कहता है, तो यही वह संख्या है जो वह इस्तेमाल करती है, और एक हफ़्ता सोया लैपटॉप बिना किसी के लेबल की व्याख्या किए फ़ेल हो जाता है। कमांड के बगल में सीमा लिख लें, क्योंकि एंडपॉइंट औज़ार बदलने पर दोनों अलग हो जाते हैं।
हर डिवाइस स्थिति को लिखित फ़ैसले में बदलें
स्थिति पर ज़्यादातर विवाद असल में अज्ञात पंक्ति पर विवाद होते हैं। पहली घटना से पहले ही यह तय कर लें, ऐसी तालिका में जो सबूत, फ़ैसला और मालिक बताती है, ताकि गेटवे कंसोल पर कोई तुरंत कुछ न गढ़े।
| Evidence the assessor has | Verdict | What it protects against |
|---|---|---|
| Timestamp inside the policy window, protective service running | Admit to normal applications | Nothing yet; the other checks still apply |
| Timestamp older than the window | Deny, admit remediation page only | Signature rollback and dormant laptops |
| Service disabled or reporting off | Deny, escalate to the endpoint owner | An agent reporting stale success |
| No report at all for this session | Treat as deny, never as healthy | Agents that fail open under load |
नीचे की पंक्ति ही वह जगह है जहाँ उत्पाद अलग होते हैं। कुछ गेटवे कनेक्शन इनकार करते हैं और कारण बताते हैं; अन्य टनल को ऊपर आने देते हैं और सीमित नीति लागू करते हैं; कुछ गिने-चुने अंतिम ज्ञात अच्छी रिपोर्ट पर लौट जाते हैं। केवल पहले दो ही तर्कसंगत हैं, और यह जाँचना उचित है कि आपका कौन-सा करता है।
पहचान और अनुमति को भी उनकी अपनी लेन में रखें। हर स्थिति परीक्षा पास करने वाले लैपटॉप को ऐप के लिए सही मानव प्राधिकरण की फिर भी ज़रूरत होती है, और डिवाइस प्रमाणपत्र कुंजी के कब्ज़े को साबित करता है, फ़ाइल सिस्टम की स्थिति को नहीं। तीनों को एक बूलियन में निचोड़ना वही तरीका है जिससे हेल्पडेस्क खाते को प्रोडक्शन तक स्थायी पहुँच मिल जाती है।
प्रवर्तन पथ को अनुरोध से जाँचें, डैशबोर्ड से नहीं
प्रवर्तन अनुरोध की विशेषता है, इसलिए इसे एक अनुरोध से मापें। गैर-अनुरूप मशीन को टनल पर रखें और वह कॉल करें जो असली उपयोगकर्ता करता:
curl -sS -o /dev/null -w '%{http_code}
' --max-time 5 https://app.internal.example/healthजिस डिवाइस को ब्लॉक होना चाहिए उससे 200 आने का मतलब है कि फ़ैसला कभी डेटा पथ तक नहीं पहुँचा। दो आम कारण: नीति ऐसे समूह से जुड़ी है जिसमें परीक्षण खाता कभी शामिल नहीं हुआ, या ऐप ऐसे रूट से पहुँच योग्य है जिसका स्वामी VPN नहीं है।
पहले रूटिंग की धारणा जाँचें। अगर आंतरिक नाम ऐसे पते पर हल होता है जहाँ क्लाइंट स्थानीय LAN से पहले ही पहुँचता है, तो टनल अप्रासंगिक है और कोई नीति लागू नहीं होगी। उस पते की तुलना उस रूट से करें जिसे गेटवे धकेलता है। OpenVPN पर प्रति-क्लाइंट नीति आम नाम से कुंजीबद्ध फ़ाइलों में रहती है, इसलिए इसे जाँचना आसान है:
ls /etc/openvpn/ccd/
cat /etc/openvpn/ccd/laptop-17जिस फ़ाइल में disable है वह उस क्लाइंट को पूरी तरह काट देती है, जबकि push "route ..." पंक्ति संकरा करती है कि वह कहाँ पहुँच सकता है। दोनों प्रवर्तन हैं, और दोनों रिपोर्ट डीबग करने वाले को दिखते हैं।
एक ही परीक्षण खाते पर चारों मामले जाँचें
आख़िरी जाँच एक छोटा मैट्रिक्स है, कोई सुखद मार्ग नहीं। एक परीक्षण खाते को चार स्थितियों से चलाएँ: वर्तमान, समाप्त हस्ताक्षर, सुरक्षा बंद, एजेंट इंस्टॉल नहीं। हर एक के लिए मूल्यांकन लॉग में फ़ैसला, ऐप जो HTTP स्थिति लौटाता है, और यह कि सुधार पृष्ठ लोड हुआ या नहीं, दर्ज करें।
foreach ($case in 'current', 'stale', 'disabled', 'absent') {
Get-MpComputerStatus | Select-Object AMServiceEnabled, AntivirusSignatureLastUpdated
curl.exe -sS -o NUL -w "%{http_code}
" --max-time 5 https://app.internal.example/health
}दो ब्यौरे छूट जाना आसान है। पहले पुनःप्रसारण: जो रिपोर्ट तब ली गई जब मशीन स्वस्थ थी, वह उसी डिवाइस पर बाद के सत्र के लिए स्वीकार नहीं की जानी चाहिए, इसलिए मौजूदा कनेक्शन से बँधा टाइमस्टैम्प खोजें। फिर हटाना: एजेंट अनइंस्टॉल करने पर पुरानी रिपोर्ट जैसा ही इनकार आना चाहिए, साफ़ पास नहीं, और यही वह मामला है जो सबसे अधिक कभी जाँचा ही नहीं जाता।
जब मैट्रिक्स तालिका से मेल खाए, तो तीन चीज़ें उसे सौंपें जो आगे गेटवे चलाएगा: कमांड, सीमा और चार अपेक्षित नतीजे। यही हस्तांतरण असली डिलीवरेबल है, क्योंकि केवल नीति दस्तावेज़ में जीने वाला स्थिति-डिज़ाइन पहली बार तब भटकता है जब एंडपॉइंट औज़ार अपना रिपोर्टिंग क्षेत्र बदलता है।