رفع خطای RDP سرور مجازی
از تست شبکه تا ورود کاربر

۱) متن خطا را به یک لایه مشخص نسبت دهید

ابتدا IP، نام کاربری، پورت و زمان وقوع خطا را ثبت کنید. روی Windows کلاینت، PowerShell را باز کنید و دسترسی TCP به پورت را بسنجید. اگر پورت RDP را تغییر نداده‌اید مقدار پیش‌فرض 3389 است؛ در غیر این صورت عدد واقعی را جایگزین کنید.

Test-NetConnection SERVER_IP -Port 3389
mstsc /v:SERVER_IP:3389

TcpTestSucceeded : False یعنی هنوز به مرحله‌ی نام کاربری و رمز نرسیده‌اید؛ مسیر اینترنت، IP، فایروال یا listener را بررسی کنید. True همراه با خطای ورود، تمرکز را به مجوز حساب، رمز، NLA یا گواهی می‌برد. پاسخ‌ندادن ping به‌تنهایی اثبات نمی‌کند سرور خاموش است، چون ICMP ممکن است مسدود باشد.

آزمون را در صورت امکان از یک اینترنت دیگر نیز تکرار کنید. اگر فقط یک شبکه شکست می‌خورد، پراکسی، VPN، فایروال سازمانی یا اپراتور همان مسیر محتمل‌تر است. اگر هر دو مسیر شکست می‌خورند، از کنسول سرور ادامه دهید.

۲) از کنسول، IP، سرویس و listener را فقط مشاهده کنید

این مرحله را داخل کنسول وب یا دسترسی خارج از RDP انجام دهید. ابتدا مطمئن شوید ماشین روشن است، IP مورد استفاده همان IP فعلی سرور است و Windows شبکه را شناخته است. سپس PowerShell را با دسترسی Administrator باز کنید:

Get-NetIPConfiguration
Get-Service TermService
Get-NetTCPConnection -State Listen -LocalPort 3389 -ErrorAction SilentlyContinue
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber

خروجی سرویس باید وضعیت Running و خروجی اتصال باید listener روی پورت واقعی نشان دهد. مقدار PortNumber را با پورتی که در کلاینت زده‌اید مقایسه کنید. اگر پورت سفارشی است، همان عدد باید در listener، فایروال و فرمان اتصال یکسان باشد.

۳) Remote Desktop و فایروال Windows را بدون خاموش‌کردن امنیت بررسی کنید

در Windows Server از Server Manager → Local Server → Remote Desktop یا صفحه‌ی Remote Desktop در Settings مطمئن شوید اتصال از راه دور فعال است. مقدار رجیستری زیر فقط برای مشاهده است؛ مقدار صفر یعنی اتصال RDP در سطح سیستم مجاز شده است:

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction
Get-NetFirewallRule -PolicyStore ActiveStore | Where-Object Enabled -eq 'True' | Where-Object DisplayGroup -Match 'Remote Desktop' | Select-Object DisplayName, Profile, Direction, Action

نام نمایشی ruleها در Windows غیرانگلیسی ممکن است ترجمه شده باشد؛ در آن حالت بخش Windows Defender Firewall with Advanced Security → Inbound Rules را باز و ruleهای داخلی Remote Desktop را برای پروفایل شبکه‌ی فعال بررسی کنید. راه درست، فعال‌کردن rule محدود و مرتبط با RDP است؛ خاموش‌کردن کامل firewall یا قراردادن یک rule عمومی برای همه‌ی پورت‌ها راه‌حل امنی نیست.

اگر پورت سفارشی دارید، rule ورودی باید دقیقاً TCP همان پورت را پوشش دهد. UDP می‌تواند تجربه RDP را بهتر کند، اما اتصال پایه باید روی TCP کار کند. پس از هر تغییر، همان Test-NetConnection را از بیرون تکرار کنید.

۴) وقتی پورت باز است، حساب کاربری و NLA را بررسی کنید

اگر تست TCP موفق است اما پیام‌هایی مانند «credentials did not work» یا «user account is not authorized» می‌بینید، IP و فایروال احتمالاً مشکل اصلی نیستند. قالب نام کاربری را درست وارد کنید: برای حساب محلی می‌توانید از .\USERNAME یا SERVERNAME\USERNAME و برای دامنه از DOMAIN\USERNAME استفاده کنید. وضعیت حساب، انقضای رمز، قفل‌شدن و عضویت در گروه مجاز RDP را از Computer Management → Local Users and Groups بررسی کنید.

whoami
hostname
net user USERNAME
net localgroup

خروجی net localgroup نام محلی گروه‌ها را نشان می‌دهد؛ سپس گروه متناظر با Remote Desktop Users را در همان زبان بررسی کنید. اعضای Administrators معمولاً حق ورود دارند، اما policy دامنه یا Local Security Policy می‌تواند این حق را رد کند. بخش‌های Allow log on through Remote Desktop Services و Deny log on through Remote Desktop Services را با احتیاط و با توجه به Group Policy بررسی کنید.

NLA را صرفاً برای دورزدن خطا خاموش نکنید. ابتدا ساعت کلاینت و سرور، اعتبار رمز، وضعیت دامنه و پشتیبانی کلاینت از NLA را کنترل کنید. کاهش سطح احراز هویت باید فقط یک آزمون محدود، مستند و دارای برنامه‌ی بازگردانی باشد.

۵) فایروال بالادستی، NAT و تداخل پورت را جدا کنید

ممکن است Windows کاملاً درست باشد اما پورت پیش از رسیدن به ماشین مسدود شود. در پنل شبکه یا روتر، security group، ACL، NAT و port-forward را بررسی کنید. آدرس عمومی باید به IP خصوصی همان ماشین و پورت بیرونی باید به پورت listener درست نگاشت شود. برای کاهش سطح حمله بهتر است دسترسی مدیریتی فقط از IPهای مورداعتماد یا از مسیر VPN مجاز باشد، نه از کل اینترنت.

اگر listener وجود دارد اما رفتار غیرعادی است، PID سرویس و پردازش گوش‌دهنده را مقایسه کنید:

tasklist /svc | findstr TermService
netstat -anob | findstr 3389

طبق راهنمای Microsoft، PID گوش‌دهنده باید با TermService سازگار باشد. توقف یک پردازش ناشناس یا آزادکردن پورت اقدام پرریسکی است؛ نام فایل، مسیر، امضا و وابستگی سرویس را در کنسول بررسی کنید و تغییر را به پنجره‌ی نگهداری منتقل کنید. اگر با یک نام دامنه وصل می‌شوید، یک بار IP مستقیم را آزمایش و رکورد DNS را نیز کنترل کنید.

۶) لاگ‌ها و چک‌لیست بازیابی امن

برای خطای احراز هویت یا ساخت session، Event Viewer را باز کنید. رویدادهای Windows Logs → Security/System و شاخه‌های Applications and Services Logs → Microsoft → Windows → TerminalServices-* زمان دقیق و کد خطا را نشان می‌دهند. ساعت رخداد را با تست کلاینت تطبیق دهید؛ انبوه رویدادهای قدیمی را به‌جای خطای فعلی دنبال نکنید.

1. نتیجه‌ی تست TCP و متن کامل خطای کلاینت را ثبت کنید.
2. از کنسول، IP، پورت رجیستری، وضعیت TermService و listener را کنترل کنید.
3. فقط rule مرتبط با همان پورت و پروفایل شبکه را بررسی کنید.
4. مجوز و وضعیت حساب را بدون خاموش‌کردن NLA اصلاح کنید.
5. پس از هر تغییر، یک آزمون بیرونی انجام دهید و تغییر موفق را مستند کنید.

اگر برای اعمال یک اصلاح مجبور به restart سرویس یا ماشین هستید، ابتدا از بسته‌بودن کارهای کاربران و دسترسی سالم کنسول مطمئن شوید. تغییر هم‌زمان چند policy تشخیص علت را از بین می‌برد.