RDP کے لیے اجازت کا قاعدہ شامل کرنا آپ کی VPN رسائی کو تنگ نہیں کرتا

منصوبہ معقول لگتا ہے: موجودہ ریموٹ ڈیسک ٹاپ کی اجازت کو ویسا ہی رہنے دیں اور اس واحد VPN کلائنٹ کے لیے چھوٹی اجازت شامل کریں جسے رسائی ہونی چاہیے۔ Windows Firewall اس طرح کام نہیں کرتا۔ قواعد کوئی ترتیب شدہ فہرست نہیں ہیں جس میں سب سے مخصوص اندراج جیتتا ہے، اور چوڑی اجازت کے ساتھ تنگ اجازت کچھ نہیں بدلتی، کیونکہ چوڑی اجازت اب بھی ان سب کو جانے دیتی ہے جنہیں پہلے سے جانے دیتی تھی۔ سروس کو تنگ کرنے کا مطلب وہی اجازت میں ترمیم کرنا ہے جو پہلے سے کام کر رہی ہے۔

آپ جو قاعدہ شامل کرتے ہیں وہ اہم قاعدہ نہیں ہے

Windows Firewall مشین پر لاگو ہونے والے پالیسی اسٹورز میں تمام قابلِ اطلاق اندرونی قواعد کا جائزہ لیتا ہے، پھر فیصلہ کرتا ہے کہ کوئی اجازت مطابقت رکھتی ہے یا نہیں اور کوئی بلاک اسے زیر کرتا ہے یا نہیں۔ قاعدہ شامل کرنے سے اجازت شامل ہوتی ہے؛ یہ پہلے سے موجود اجازتوں کو ہٹاتا یا محدود نہیں کرتا۔

اس لیے سوال کبھی یہ نہیں ہوتا کہ آپ نے کیا شامل کیا۔ سوال یہ ہے کہ مقامی پالیسی، ڈومین پالیسی اور پروفائل کی طے شدہ قدروں کے ضم ہونے کے بعد مؤثر پالیسی میں کیا ہے۔ ایک مقامی قاعدے والے ورک اسٹیشن کے بارے میں سوچنا آسان ہے؛ ڈومین سے منسلک سرور کے بارے میں نہیں۔

اسی لیے منتظم درست دکھنے والی تبدیلی کر سکتا ہے، اسے غلط مشین سے جانچ سکتا ہے اور یہ نتیجہ نکال سکتا ہے کہ یہ چل گئی۔ خارج کردہ ماخذ کی کبھی جانچ نہیں ہوئی۔ جو جانچ صرف کامیابی ثابت کرے وہ تبدیلی کے مقصد کے نصف سے بھی کم ثابت کرتی ہے۔

معلوم کریں کہ سرور کون سا پتہ دیکھتا ہے

کچھ بھی محدود کرنے سے پہلے Windows ہوسٹ پر ایک اجازت یافتہ سیشن کا مشاہدہ کریں اور وہ ماخذ پتہ لکھیں جو سرور بتاتا ہے۔ یہ ہمیشہ وہ پتہ نہیں ہوتا جو کلائنٹ سمجھتا ہے کہ اس کے پاس ہے۔

اگر VPN گیٹ وے کلائنٹ کے پتے محفوظ رکھتا ہے تو سرور کلائنٹ کا ٹنل پتہ دیکھتا ہے، اور پتے سے محدود قاعدہ بامعنی ہوتا ہے۔ اگر گیٹ وے ترجمہ کرتا ہے تو ہر کلائنٹ گیٹ وے کے پتے کے طور پر آتا ہے، اور اسی پتے تک محدود کرنا اس کے پیچھے کے ہر کلائنٹ کو رسائی دیتا ہے۔ تب قاعدہ غلط چیز کے بارے میں درست ہے۔

ان دونوں ڈیزائنوں کو مختلف جوابات درکار ہیں۔ پہلا فائر وال قاعدے میں بیان کیا جا سکتا ہے؛ دوسرا وہاں نافذ کرنا ہوگا جہاں شناخت اب بھی موجود ہے، یعنی خود VPN میں یا سروس کے سامنے تصدیق شدہ گیٹ وے میں۔

فائر وال فلٹر نیٹ ورک ترجمے کی پھینکی ہوئی شناخت واپس نہیں لا سکتا، پتہ کتنی احتیاط سے لکھا گیا ہو۔

مؤثر قاعدے کا مالک بدلیں

مؤثر اندرونی پالیسی کا معائنہ کریں اور ہر وہ قاعدہ تلاش کریں جو ابھی RDP ٹریفک کی اجازت دیتا ہے، ان قواعد سمیت جن کے ظاہری نام میں کبھی پورٹ 3389 کا ذکر نہیں ہوتا۔ سروس اور ایپلیکیشن سے محدود قواعد بھی گنے جاتے ہیں، اور وہ UDP منتقلی بھی جو کچھ RDP تعیناتیاں فعال کرتی ہیں۔

پھر موجودہ قواعد میں اس اسٹور کے ذریعے ترمیم کریں جو ان کا مالک ہے۔ ایسے قاعدے میں مقامی ترمیم جسے ڈومین پالیسی بھی متعین کرتی ہے، ضم ہو سکتی ہے، نظر انداز ہو سکتی ہے یا اس پر دوبارہ لکھا جا سکتا ہے، اور اس پر بھروسہ کرنے سے پہلے یہ جاننا مناسب ہے کہ ان میں سے کیا ہوتا ہے۔

یہ کمانڈز فعال قواعد تلاش کرتی ہیں، ان میں سے ایک سے منسلک پتہ فلٹر دکھاتی ہیں اور دائرے کی تبدیلی کا پیش نظارہ کرتی ہیں:

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound | Where-Object DisplayName -match RDP
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -Name Reviewed-RDP-TCP)
Set-NetFirewallRule -Name Reviewed-RDP-TCP -RemoteAddress 10.63.4.17 -WhatIf

یہاں قواعد کے نام جائزے میں ملی باتوں کے پلیس ہولڈر ہیں، اور پیش نظارہ جھنڈا اس لیے ہے کہ پتے میں ٹائپو آپ کو اس سرور سے باہر نہ کر دے جس میں آپ ترمیم کر رہے ہیں۔

پہلے بلاک پھر اجازت ایک مختلف ماڈل ہے

دوسرے فائر والز کی عادت چوڑا بلاک لکھنے اور پھر اس کے اوپر تنگ اجازت دینے کی ہے۔ Windows میں واضح بلاک عام طور پر اجازت پر غالب آتا ہے، اس لیے یہ ترتیب ایک کلائنٹ کے لیے استثنا کے بجائے ایسی سروس بناتی ہے جہاں کوئی نہیں پہنچ سکتا۔ نتیجہ وہ رکاوٹ ہے جو خراب RDP سروس جیسی دکھتی ہے۔ یہ درحقیقت ترجیح کی غلطی ہے، اور حل دوسری اجازت شامل کرنا نہیں بلکہ بلاک ہٹانا ہے۔

فعال پروفائلز پر طے شدہ اندرونی بلاک کا رویہ رکھیں اور اس کے بجائے مخصوص اجازتوں کو تنگ کریں۔ اس سے مشین دو متضاد قواعد کے بجائے ایک قابلِ فہم حالت میں رہتی ہے، جن کا باہمی عمل ترجیح کی تفصیلات پر منحصر ہے۔

دوسرے ماخذ سے اسے ثابت کریں

اجازت یافتہ کلائنٹ سے اور اس ماخذ سے جانچیں جو اب ناکام ہونا چاہیے۔ ایک کامیاب کنکشن صرف یہ ثابت کرتا ہے کہ اجازت یافتہ راستہ کام کرتا ہے؛ یہ ابھی کیے گئے اخراج کے بارے میں کچھ نہیں کہتا۔

اگر سرور پر فعال ہو تو IPv6 پر جانچ دہرائیں، کیونکہ صرف IPv4 کا ارادہ اس چوڑی IPv6 اجازت کے ساتھ موجود ہو سکتا ہے جسے کسی نے نہیں دیکھا۔

آخر میں، تصدیق کو رسائی سے الگ رکھیں۔ نیٹ ورک سطح کی تصدیق، اکاؤنٹ کے حقوق اور لاگ ان پابندیاں اب بھی طے کرتی ہیں کہ سیشن کون استعمال کر سکتا ہے، اور فائر وال صرف طے کرتا ہے کہ کون پوچھ سکتا ہے۔ بعد میں کسی ڈیوائس کو ہٹانا اس کی VPN رجسٹریشن اور یہ نیٹ ورک اجازت دونوں ہٹانا چاہیے، ورنہ آپ کا محدود کیا ہوا پتہ کسی دن کسی اور کا ہو جائے گا۔