افزودن یک قاعده مجاز برای RDP دسترسی VPN شما را محدود نمی‌کند

این طرح معقول به نظر می‌رسد: مجوز موجود Remote Desktop را دست‌نخورده بگذارید و مجوز کوچکی برای تنها کلاینت 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 و هم این اجازه شبکه را بردارد، وگرنه نشانی‌ای که محدود کردید روزی از کس دیگری خواهد بود.