وصل نشدن ریموت دسکتاپ به سرور مجازی ویندوز؛ راهنمای رفع خطای RDP

برای رفع مشکل وصل نشدن ریموت دسکتاپ به سرور مجازی ویندوز ابتدا مشخص کنید اتصال در کدام مرحله متوقف می‌شود: پیش از نمایش درخواست ورود، هنگام پذیرش نام کاربری و رمز، یا بعد از ورود با صفحهٔ سیاه. در حالت اول مسیر شبکه و پورت RDP را بررسی کنید؛ در حالت دوم حساب و مجوز ورود مهم است؛ در حالت سوم باید نشست کاربر و فرایند ورود ویندوز بررسی شود. ری‌استارت مکرر سرور این سه مسئله را از هم جدا نمی‌کند.

این راهنما برای اتصال مستقیم مدیریتی به Windows Server نوشته شده است. اگر از RD Gateway، مجموعهٔ سازمانی RDS یا احراز هویت چندمرحله‌ای استفاده می‌کنید، لایهٔ واسط هم باید توسط مدیر آن سامانه بررسی شود. نام گزینه‌ها بین نسخه‌های ویندوز کمی تفاوت دارد. پیش از تغییر تنظیمات، کنسول تحت وب یا دسترسی جایگزین پنل ارائه‌دهنده را باز نگه دارید تا در صورت قطع RDP، امکان برگشت داشته باشید.

۱. خطای اتصال RDP را دقیق دسته‌بندی کنید

متن کامل پیام، زمان وقوع، نام یا IP مقصد، پورت و آخرین تغییر را یادداشت کنید. عبارت عمومی «نمی‌وصل می‌شود» برای تشخیص کافی نیست. برای مثال، نرسیدن به پنجرهٔ ورود با رد شدن رمز تفاوت دارد؛ رسیدن به صفحهٔ سیاه پس از پذیرش حساب نیز نشان می‌دهد مسیر اتصال تا مرحله‌ای جلو رفته است. جدول زیر یک مسیر شروع است، نه تشخیص قطعی صرفاً بر اساس ظاهر خطا.

نشانه	آزمون مناسب	قدم بعدی
انتظار طولانی و خطای اتصال پیش از ورود	آزمون TCP به IP و پورت واقعی	کنسول، listener و قوانین دسترسی شبکه را بررسی کنید.
IP وصل می‌شود، نام سرور وصل نمی‌شود	مقایسهٔ IP حل‌شده با اطلاعات پنل	رکورد DNS یا نام ذخیره‌شده را اصلاح کنید.
رمز یا نام کاربری رد می‌شود	بررسی حساب محلی یا دامنه و ورود از کنسول	اطلاعات ذخیره‌شده، قفل حساب و مجوز ورود را بررسی کنید.
پیام User is not authorized	بررسی گروه کاربر و سیاست حق ورود	مدیر ویندوز مجوز همان حساب را اصلاح کند.
صفحهٔ سیاه بعد از ورود	مقایسه با کنسول و حساب مجاز دیگر	نشست، پروفایل و رویدادهای ورود را بررسی کنید.

۲. IP، پورت و مسیر دسترسی را از رایانهٔ خودتان آزمایش کنید

IP را از مشخصات فعلی سرویس بردارید؛ فایل RDP قدیمی ممکن است به مقصد یا پورت قبلی اشاره کند. اگر پورت اختصاصی تعریف شده، در کادر Computer از قالب SERVER_IP:RDP_PORT استفاده کنید. عدد 3389 پورت پیش‌فرض است و نباید بدون بررسی جایگزین پورت اعلام‌شدهٔ سرویس شود. برای سرویس‌هایی که دسترسی مدیریتی فقط از VPN مجاز است، ابتدا به همان VPN متصل شوید.

در PowerShell رایانهٔ شخصی، نمونهٔ زیر را با IP و پورت خود جایگزین کنید. نشانی 203.0.113.10 صرفاً مثال آموزشی است و سرور واقعی آفاق هاست نیست:

Test-NetConnection -ComputerName 203.0.113.10 -Port 3389 -InformationLevel Detailed

خروجی TcpTestSucceeded : True یعنی اتصال TCP به آن مقصد و پورت برقرار شده؛ درست بودن رمز یا سلامت کامل RDP را ثابت نمی‌کند. مقدار False نیز به‌تنهایی نمی‌گوید فایروال مقصر است؛ مقصد اشتباه، مسدودبودن مسیر یا نبود listener می‌تواند همین نتیجه را ایجاد کند. پاسخ‌ندادن ping هم اثبات خاموشی سرور نیست، چون ICMP ممکن است محدود باشد. جزئیات ابزار در مستند Test-NetConnection مایکروسافت آمده است.

اگر روی یک شبکه اتصال برقرار است و روی شبکهٔ دیگر برقرار نیست، نتیجهٔ هر دو آزمون را همراه IP مبدأ به پشتیبانی بدهید. این مقایسه از حدس‌زدن دربارهٔ کیفیت اینترنت مفیدتر است. در صورت استفاده از نام سرور، مقدار RemoteAddress را با IP پنل مقایسه کنید. موفقیت اتصال با IP و شکست با نام، بررسی DNS را در اولویت قرار می‌دهد.

۳. از کنسول، روشن‌بودن ویندوز و listener را بررسی کنید

کنسول پنل مستقل از RDP است. اگر همان‌جا هم ویندوز پاسخ نمی‌دهد یا در راه‌اندازی گیر کرده، موضوع فقط اتصال ریموت نیست و باید وضعیت ماشین و سیستم‌عامل بررسی شود. اگر کنسول کار می‌کند، در PowerShell سرور این فرمان‌های خواندنی را اجرا کنید:

Get-Service -Name TermService
qwinsta
Get-NetTCPConnection -State Listen -LocalPort 3389

فرمان آخر را با پورت واقعی تطبیق دهید. وضعیت Running برای TermService و وجود listener اطلاعات مهمی هستند؛ صرفاً Running بودن سرویس کافی نیست. در خروجی qwinsta وضعیت نشست‌ها و listener را ببینید. نبودن نتیجه یا پیام خطای فرمان را ثبت کنید، نه اینکه برای گرفتن خروجی دلخواه تنظیمات ناشناخته را تغییر دهید. راهنمای qwinsta معنای این فهرست را توضیح می‌دهد.

در Settings یا Server Manager بررسی کنید Remote Desktop فعال است. اگر سیاست سازمانی آن را کنترل می‌کند، تغییر محلی ممکن است پایدار نماند. برای مسیر فایروال، مدیر باید قانون مربوط به پورت واقعی، پروفایل فعال و IP مبدأ مجاز را بررسی کند؛ قانون پنل شبکهٔ ارائه‌دهنده و Windows Defender Firewall دو لایهٔ جدا هستند. دسترسی را فقط برای مبدأ مدیریتی موردنیاز یا مسیر خصوصی مصوب برقرار کنید. راهنمای تشخیص اتصال ناموفق RDP مایکروسافت همین تفکیک ماشین، listener و شبکه را مبنا قرار می‌دهد.

۴. وقتی نام کاربری و رمز پذیرفته نمی‌شود

ابتدا معلوم کنید حساب محلی سرور است یا حساب دامنه. برای حساب محلی، قالب SERVERNAME\username و برای حساب دامنه، قالب اعلام‌شده توسط مدیر دامنه را به کار ببرید. نام کاربری ویندوز رایانهٔ شخصی لزوماً حساب سرور نیست. گزینهٔ Use a different account در پنجرهٔ ورود کمک می‌کند از ارسال دوبارهٔ حساب ذخیره‌شدهٔ اشتباه جلوگیری کنید.

اگر رمز تازه تغییر کرده، ورودی ذخیره‌شدهٔ همین مقصد را در Credential Manager بررسی کنید؛ اطلاعات سایر سرویس‌ها را حذف نکنید. بعد از چند شکست پشت سر هم، به‌جای تکرار حدسی رمز، وضعیت قفل یا انقضای حساب را از کنسول یا مدیر بپرسید. رمز عبور، فایل اتصال حاوی اطلاعات حساس و کد احراز هویت را داخل تیکت عمومی یا تصویر خطا نفرستید.

ورود موفق از کنسول هنوز به معنی داشتن مجوز RDP نیست. مدیر باید عضویت کاربر در گروه مجاز Remote Desktop Users و سیاست‌های Allow log on through Remote Desktop Services و Deny log on through Remote Desktop Services را متناسب با محیط بررسی کند. سیاست دامنه می‌تواند تنظیم محلی را تغییر دهد. برای یک کاربر معمولی، دادن دسترسی کامل Administrator راه‌حل مناسبی برای هر خطای مجوز نیست. شرح خطاها در راهنمای Access denied و User not authorized آمده است.

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

۵. اتصال برقرار می‌شود اما صفحهٔ سیاه می‌بینید

اگر پس از پذیرش حساب صفحه سیاه است، ابتدا زمان شروع و مدت انتظار را ثبت کنید و از همان کنسول وضعیت ویندوز را ببینید. در نسخه‌های دارای محیط دسکتاپ، با Ctrl+Alt+End داخل نشست ریموت، امکان بازشدن منوی امنیتی و Task Manager را بررسی کنید. این آزمون فقط کمک می‌کند پاسخ‌گویی نشست را بسنجید؛ ثابت نمی‌کند مشکل حتماً از گرافیک است. روی Server Core هم انتظار دسکتاپ کامل معمول ویندوز نداشته باشید.

اگر حساب مجاز دیگری مشکل ندارد، بررسی پروفایل و فرایند ورود همان کاربر مقدم است. اگر همهٔ حساب‌ها و کنسول هم مشکل دارند، مسیر بررسی عمومی‌تر می‌شود. زمان خطا را در Event Viewer، بخش‌های Application و System و رویدادهای TerminalServices تطبیق دهید. از تغییر رجیستری Shell یا نصب درایور تصادفی شروع نکنید. راهنمای صفحهٔ سیاه پس از ورود مایکروسافت برای تفکیک مشکل shell و فرایند ورود مفید است؛ جزئیات نسخهٔ سیستم‌عامل باید رعایت شود.

قطع اتصال با Sign out تفاوت دارد: بستن پنجرهٔ ریموت معمولاً نشست را نگه می‌دارد. حذف یک نشست می‌تواند برنامه‌ها و دادهٔ ذخیره‌نشدهٔ آن را ببندد. مدیر تنها پس از شناسایی نشست، هماهنگی با صاحب آن و حفظ کارهای باز، دربارهٔ خروج تصمیم بگیرد. هشدار رسمی فرمان logoff نیز بر احتمال از دست‌رفتن داده تأکید دارد.

۶. مثال تشخیص و معیار رفع مشکل

فرض کنید بعد از تغییر اینترنت دفتر، RDP پیش از ورود متوقف شده ولی کنسول سالم است. آزمون TCP از مسیر مدیریتی قبلی موفق و از اینترنت جدید ناموفق می‌شود. این سناریوی آموزشی، بررسی فهرست IPهای مجاز و مسیر شبکه را در اولویت می‌گذارد؛ تغییر رمز حساب به این نشانه مربوط نیست. در سناریوی دیگر، TCP موفق است و فقط یک کاربر پیام عدم مجوز دارد؛ بررسی حقوق همان حساب منطقی‌تر از تغییر فایروال است.

رفع مشکل وقتی تأیید می‌شود که از مسیر مجاز، با حساب موردنظر وارد شوید، دسکتاپ یا محیط تعریف‌شده باز شود و پس از قطع و اتصال دوباره نیز ورود سالم بماند. سپس علت و تغییر انجام‌شده را ثبت کنید. برای کمک تخصصی، متن خطا، زمان، نسخهٔ ویندوز و نتیجهٔ TCP را بدون رمز برای خدمات مدیریت سرور آفاق هاست آماده کنید. اگر در انتخاب محل استقرار سرویس هستید، مشخصات سرور مجازی ایران را با نیاز برنامه و مسیر دسترسی کاربران تطبیق دهید؛ محل سرور به‌تنهایی مشکلات حساب و سیاست ویندوز را حل نمی‌کند.

پرسش‌های متداول

پینگ دارم؛ چرا ریموت دسکتاپ باز نمی‌شود؟

ping و RDP یک آزمون نیستند. پاسخ ICMP دربارهٔ دسترسی TCP به پورت ریموت، listener یا مجوز حساب نتیجهٔ قطعی نمی‌دهد. آزمون TCP را به پورت واقعی اجرا و سپس وضعیت سرور را از کنسول بررسی کنید.

آیا تغییر پورت RDP مشکل وصل نشدن را برطرف می‌کند؟

بدون تشخیص علت، خیر. تغییر پورت می‌تواند کلاینت و قوانین شبکه را ناهماهنگ کند. اول پورت فعلی، listener و مسیر مجاز را تطبیق دهید؛ تغییر طراحی دسترسی باید با برنامهٔ برگشت و کنسول انجام شود.

برای پشتیبانی چه اطلاعاتی بفرستم؟

متن دقیق خطا، زمان و منطقهٔ زمانی، مرحلهٔ توقف، پورت، نتیجهٔ آزمون TCP و وضعیت کنسول کافی است تا بررسی شروع شود. اطلاعات حساب را فقط از مسیر امن موردتوافق بدهید و رمز یا کد ورود را به تصویر خطا اضافه نکنید.