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-17disable असलेली फाइल त्या क्लायंटला पूर्णपणे तोडते, तर 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
}दोन तपशील चुकवणे सोपे आहे। प्रथम पुनःप्रक्षेपण: मशीन निरोगी असताना घेतलेला अहवाल त्याच उपकरणावरील नंतरच्या सत्रासाठी स्वीकारू नये, म्हणून सध्याच्या कनेक्शनशी बांधलेली वेळमुद्रा शोधा। नंतर काढणे: एजंट काढल्यावर जुन्या अहवालासारखाच नकार यायला हवा, स्वच्छ उत्तीर्ण नाही, आणि हेच प्रकरण सर्वाधिक वेळा कधीच तपासले जात नाही।
मॅट्रिक्स तक्त्याशी जुळल्यावर, पुढे गेटवे चालवणाऱ्या व्यक्तीला तीन गोष्टी सुपूर्द करा: आदेश, उंबरठा आणि अपेक्षित चार निकाल। हेच सुपूर्द करणे खरे डिलिव्हरेबल आहे, कारण केवळ धोरण दस्तऐवजात जगणारी स्थिती-रचना एंडपॉइंट साधन त्याचे अहवाल क्षेत्र बदलते तेव्हा पहिल्यांदा भरकटते।