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
}دو تفصیلیں چھوٹ جانا آسان ہے۔ پہلے دوبارہ نشر: وہ رپورٹ جو مشین کے صحت مند ہونے کے دوران لی گئی، اُسی ڈیوائس پر بعد کے سیشن کے لیے قبول نہیں کی جانی چاہیے، اس لیے موجودہ کنکشن سے بندھی وقت کی مہر تلاش کریں۔ پھر ہٹانا: ایجنٹ اَن انسٹال کرنے پر پرانی رپورٹ جیسا ہی انکار آنا چاہیے، صاف گزر نہیں، اور یہی وہ کیس ہے جو اکثر کبھی جانچا ہی نہیں جاتا۔
جب میٹرکس جدول سے مطابقت کرے، تو تین چیزیں اُسے سونپیں جو آگے گیٹ وے چلائے گا: حکم، حد اور متوقع چار نتائج۔ یہی حوالگی اصل ڈیلیوریبل ہے، کیونکہ صرف پالیسی دستاویز میں جینے والا حالت کا ڈیزائن اینڈ پوائنٹ اوزار کے اپنا رپورٹنگ خانہ بدلنے پر پہلی بار بھٹک جاتا ہے۔