اَبرِ دیجیتال، مرکز تخصصی ارائه سرویس های ابری، سرور مجازی/اختصاصی، هاست و دامنه

اَبرِ دیجیتال، مرکز تخصصی ارائه سرویس های ابری

دریافت مشاوره رایگان

رفع خطاها و مشکلات اتصال Remote Desktop

مقدمه

 

اتصال از راه دور با پروتکل Remote Desktop Protocol (RDP) یکی از رایج‌ترین روش‌ها برای مدیریت سرور مجازی  یا اختصاصی ها و دسکتاپ‌های ویندوزی است. با وجود کارآمدی، خطاها و مشکلات متعددی ممکن است تجربهٔ اتصال را مختل کنند. این راهنمای به شما کمک می‌کند ریشه‌یابی، تشخیص و رفع بیش‌تر مشکلات رایج RDP را با گام‌های عملی، دستورالعمل‌های فنی و چک‌لیست‌های کاربردی انجام دهید. متن طوری سازمان‌دهی شده که هم تکنسین‌های سیستم و هم مدیران شبکه بتوانند از آن استفاده کنند.

 

فصل 1 — مفاهیم پایه و عناصر دخیل در اتصال RDP

 

– RDP چیست: پروتکلی که نمایش گرافیکی دسکتاپ، ورودی کاربر و انتقال برخی دستگاه‌های محلی را بر بستر شبکه فراهم می‌کند. معمولاً سرویس Terminal Services یا Remote Desktop Services در ویندوز پیاده‌سازی می‌شود.

– مؤلفه‌ها: کلاینت RDP، سرور RDP، شبکه داخلی، اینترنت یا VPN (در صورت دسترسی از راه دور)، سرویس‌های احراز هویت (Local/AD)، فایروال‌ها، و در برخی موارد لودبالانسر یا Gateway (RD Gateway).

– پورت و پروتکل: پیش‌فرض TCP 3389؛ می‌تواند تغییر کند. همچنین TLS برای رمزنگاری کانال استفاده می‌شود و NLA (Network Level Authentication) قبل از ایجاد جلسه، هویت را اعتبارسنجی می‌کند.

– انواع خطاها: شبکه‌ای (عدم دسترسی، تأخیر، از دست رفتن بسته)، احراز هویت (نام کاربری/رمز، سیاست‌های امنیتی)، پیکربندی سرویس (غیرفعال بودن RDP، محدودیت نشست‌ها)، فایروال/مسیر (NAT، Port Forwarding)، گواهی‌نامه‌ها (TLS)، مشکلات نمایش و عملکرد (رزولوشن، GPU) و مسائل سطح سیستم‌عامل (قفل حساب، سرویس متوقف).

 

فصل 2 — آماده‌سازی و بررسی اولیه (پیش از عیب‌یابی عمیق)

 

بررسی دسترسی فیزیکی و شبکه‌ای

– از کلاینت به سرور ping بزنید: ping server_ip

– اگر پاسخ نیست، بررسی کنید سرور روشن است و کارت شبکه فعال.

– بررسی اتصال میان سوئیچ‌ها/روترها، کابل‌ها و وضعیت لینک فیزیکی.

 

اطمینان از فعال بودن RDP در سرور

– در ویندوز 10/11/Server: Settings > System > Remote Desktop > Remote Desktop را فعال کنید یا Control Panel > System and Security > System > Remote settings.

– در ویندوز سرورهای قدیمی‌تر: Server Manager > Remote Desktop Services یا Remote tab در System Properties.

 

بررسی حساب و مجوزها

– کاربر باید عضو گروه Remote Desktop Users یا Administrator باشد.

– مطمئن شوید حساب غیرفعال یا قفل نشده و پسورد منقضی نشده است.

– در محیط AD، بررسی کنید سیاست‌های گروهی (GPO) مانع دسترسی نیستند.

 

بررسی فایروال محلی و شبکه

– در ویندوز: Windows Defender Firewall > Advanced settings > Inbound Rules — قانون Remote Desktop (TCP 3389) باید فعال باشد.

– در فایروال شبکه/روتر، پورت 3389 یا پورت تخصیص‌یافته باز و به IP مقصد فوروارد شده باشد.

 

ثبت لاگ‌ها (ابتدایی)

– Event Viewer: System, Security, Applications and Services Logs > Microsoft > Windows > TerminalServices-LocalSessionManager و TerminalServices-RemoteConnectionManager.

– یادداشت خطاها، زمان و Event IDها برای تحلیل.

 

فصل 3 — دسته‌بندی و تحلیل خطاهای رایج با راه‌حل‌های گام‌به‌گام

 

خطاها را در چند دسته اصلی آورده‌ام. برای هر خطا، علل احتمالی و راه‌حل عملی و دقیق نوشته شده است.

 

خطاهای اتصال عمومی (Cannot connect / Connection timed out)

– علل رایج:

– سرور در دسترس نیست یا خاموش است.

– آدرس IP یا نام میزبان اشتباه است.

– فایروال محلی یا شبکه پورت را مسدود کرده.

– NAT/Port forwarding درست پیکربندی نشده.

– سرویس Remote Desktop در سرور اجرا نمی‌شود.

– گام‌های رفع:

بررسی در دسترس بودن سرور با ping server_ip. اگر ping بسته می‌شود، روی سرور لاگ‌های شبکه و وضعیت NIC را چک کنید.

تست پورت: از کلاینت اجرای telnet server_ip 3389 یا استفاده از ابزارهای مشابه (Test-NetConnection در PowerShell: Test-NetConnection -ComputerName server_ip -Port 3389).

مطمئن شوید سرویس Remote Desktop Services فعال و در حال اجرا است: services.msc -> Remote Desktop Services.

بررسی قوانین فایروال محلی: netsh advfirewall firewall show rule name=all | find “3389” یا در PowerShell: Get-NetFirewallRule -DisplayName “*Remote*”.

اگر دسترسی از اینترنت است، در روتر NAT تنظیمات Port Forwarding را بررسی کنید. IP داخلی سرور ممکن است تغییر کرده باشد؛ از DHCP به Static تبدیل کنید یا رزرو DHCP تنظیم کنید.

بررسی رکورد DNS: nslookup servername و مقایسه با IP مورد انتظار.

 

خطاهای احراز هویت و پیام‌های مربوط به NLA / CredSSP

– شایع: “An authentication error has occurred. The function requested is not supported” یا پیام‌های مشابه CredSSP.

– دلایل:

– ناسازگاری نسخه‌های به‌روزرسانی امنیتی بین کلاینت و سرور (بخصوص به‌روز‌رسانی‌های CredSSP مایکروسافت).

– پیکربندی NLA در سرور روشن است اما کلاینت از NLA پشتیبانی یا به‌روز نیست.

– سیاست‌های گروهی (GPO) مربوط به Credentials Delegation یا Encryption level ناسازگارند.

– راه‌حل:

اطمینان از به‌روزرسانی سیستم‌عامل‌ها: هر دو طرف آخرین Patchها را دریافت کنند.

در صورت نیاز موقت، در کلاینت mstsc > show options > Advanced > uncheck “Require server authentication (Use NLA)” یا در سرور NLA را غیرفعال نکنید مگر اینکه مطمئن باشید. بهتر است نسخه‌ها را هماهنگ کنید.

بررسی Group Policy: Computer Configuration > Administrative Templates > System > Credentials Delegation > Encryption Oracle Remediation را بررسی کنید و روی “Vulnerable” یا “Mitigated” فقط با آگاهی تنظیم شود.

اگر خطا پس از به‌روزرسانی ظاهر شد، به‌روزرسانی‌های CredSSP را در هر دو طرف نصب یا policy را مطابق مستندات مایکروسافت هماهنگ کنید.

 

 

خطاهای نام کاربری/رمز عبور یا حساب مسدود

– پیام‌ها: “The user name or password is incorrect” یا “This account has been disabled”.

– دلایل:

– وارد کردن نام کاربری/رمز اشتباه.

– حساب قفل، غیرفعال یا رمز منقضی.

– سیاست‌های لاگین از راه دور محدود شده (مثلاً Logon locally only).

– راه‌حل:

بررسی صحیح بودن فرمت نام کاربری: DOMAIN\username یا username@domain.com در صورت AD.

با دسترسی فیزیکی یا کنسول مدیریتی وارد سرور شوید و وضعیت حساب را چک کنید (Local Users and Groups یا Active Directory Users and Computers).

چک کردن Password Policies و Account Lockout Policy: ممکن است تعداد تلاش‌های ناموفق زیاد باعث قفل شده باشد؛ بازنشانی یا افزایش آستانه در صورت نیاز.

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

 

 

خطاهای مربوط به گواهی‌نامه و TLS

– پیام‌ها: هشدار certificate mismatch یا cannot verify identity of remote computer.

– علل:

– گواهی‌نامه خودامضا یا CN/SAN با نام میزبان مطابقت ندارد.

– گواهی منقضی شده یا ناامن.

– زمان سیستم‌ها متفاوت است (اختلاف زیاد باعث رد گواهی می‌شود).

– راه‌حل:

بررسی تاریخ و زمان کلاینت و سرور؛ لازم است هر دو با NTP هماهنگ باشند.

استفاده از گواهی‌نامه‌ای که توسط CA قابل اعتماد صادر شده و CN یا SAN آن با نام میزبان یا FQDN سرور مطابقت داشته باشد؛ در محیط‌های سازمانی از CA داخلی استفاده کنید.

اگر گواهی خودامضا به‌کار می‌رود، نصب گواهی در Trusted Root Certificates Authorities کلاینت برای حذف هشدار (فقط در شبکه کنترل‌شده).

بررسی تنظیمات در Remote Desktop Session Host Configuration یا Group Policy برای TLS/SSL bindings.

 

 

قطع اتصال ناگهانی یا زمان‌های تأخیر/Idle timeouts

– دلایل:

– تنظیمات Session Time Limits در RDSH یا Group Policy.

– مشکلات شبکه یا ناپایداری لینک.

– سیاست‌های NAT/load balancer یا تجهیزات میانی که جلسات TCP را قطع می‌کنند.

– اقدامات:

بررسی Session Time Limits: Server Manager > Remote Desktop Services > Collections > Session limits یا Group Policy > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits.

بررسی پایداری شبکه: استفاده از continuous ping، MTR یا pathping برای ردیابی از دست دادن بسته یا نوسان.

در صورت وجود load balancer یا NAT، بررسی تنظیمات TCP idle timeout و افزایش مقدار آن.

بررسی منابع سرور: استفادهٔ زیاد از CPU، RAM یا IO می‌تواند باعث تأخیر و قطع ارتباط شود؛ Performance Monitor را بررسی کنید.

 

مشکلات نمایش، رنگ، و عملکرد گرافیکی

– علل:

– پهنای باند محدود.

– تنظیمات تجربهٔ کاربری RDP (color depth، visual experience) روی کیفیت بالا تنظیم شده.

– درایور گرافیکی یا مشکلات با GPU virtualization.

– راه‌حل:

در کلاینت RDP، Experience tab را باز کنید و مواردی مانند Desktop background, Font smoothing, Visual styles، و Bitmap caching را غیرفعال کنید یا کیفیت رنگ را کاهش دهید.

فعال‌سازی/پیکربندی RemoteFX یا GPU pass-through در سرورهای مجازی در صورت نیاز به گرافیک سنگین.

استفاده از فشرده‌سازی یا پروتکل‌هایی مانند UDP-enabled RDP (در صورت پشتیبانی) که عملکرد تعاملی را بهتر می‌کنند.

 

 

عدم انتقال صدا، چاپگر یا درایوها

– دلایل:

– ریدایرکت دستگاه‌ها در کلاینت غیرفعال است.

– نیاز به نصب درایورهای پرینتر روی سرور.

– سیاست‌های امنیتی سرور جلوی redirection را گرفته‌اند.

– راه‌حل:

در کلاینت RDP > Local Resources، تنظیمات Audio, Printers, Clipboard, Drives را فعال کنید.

در سرور، اطمینان از نصب درایورهای مورد نیاز و فعال بودن Remote Desktop Easy Print (برای پرینترها).

بررسی Group Policy: Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Device and Resource Redirection.

 

مشکلات مربوط به نسخه‌ها و هماهنگی پچ‌ها

– توضیح:

– به‌روزرسانی‌های امنیتی گاهی باعث تغییر رفتار گردیده و نیاز به هماهنگی نسخه‌ها دارد.

– راه‌حل:

زمان‌بندی به‌روزرسانی هم‌زمان برای کلاینت‌ها و سرورها در شبکه کنترل‌شده.

خواندن release notes از مایکروسافت درباره تغییرات امنیتی مرتبط با RDP/CredSSP و اعمال تنظیمات پیشنهادی.

 

فصل 4 — ابزارها و تکنیک‌های تشخیصی (با مثال‌ها و دستورات)

 

دستورات پایه:

– ping server_ip — بررسی لایهٔ شبکه.

– tracert server_ip یا pathping server_ip — شناسایی نقطهٔ قطعی در مسیر.

– telnet server_ip 3389 — بررسی اینکه پورت شنونده است یا نه (اگر telnet نصب باشد).

– PowerShell: Test-NetConnection -ComputerName server_ip -Port 3389 -InformationLevel Detailed

– PowerShell برای بررسی سرویس: Get-Service -Name TermService

– netstat -an | find “3389” — بررسی اینکه سرویس روی پورت مورد نظر listening است.

بررسی فایروال:

– Windows: Get-NetFirewallRule | Where-Object {$_.DisplayName -like “*Remote*”}

– netsh advfirewall firewall show rule name=”Remote Desktop – User Mode (TCP-In)”

Event Viewer:

– کلیدهای مفید: Event IDs مربوط به RemoteConnectionManager (1149)، TerminalServices-LocalSessionManager (e.g., 21, 23)، و System برای hatched network adapter errors.

ابزارهای شبکه‌ای:

– Wireshark: گرفتن ترافیک روی پورت 3389 برای مشاهده سه‌راهه TCP، RST یا رفتار TLS.

– MTR: بررسی پکت لاس و latency روی مسیر.

ابزارهای مدیریت RDS:

– Remote Desktop Services Manager، Remote Desktop Session Host Configuration، RD Gateway Manager در صورتی که زیرساخت RDS پیچیده باشد.

بررسی پیکربندی NAT/Router:

– در روترهای مصرفی و سازمانی، بررسی Port Forwarding و همچنین Public IP و mapping به IP داخلی.

– Reserve آدرس در DHCP برای جلوگیری از تغییر IP سرور.

 

فصل 5 — سناریوهای عملی و نمونه‌های عیب‌یابی مرحله‌به‌مرحله

 

نمونه 1 — سناریوی “Cannot connect from خارج شبکه”

– علائم: داخل شبکه وصل می‌شوید اما از اینترنت نمی‌توانید، پیام زمان‌انتظار یا اتصال ممکن نیست.

– گام‌ها:

بررسی Public IP: از سرور یا دستگاه داخل شبکه، whatismyip یا روتر را چک کنید.

از بیرون شبکه (مثلاً از یک موبایل در اینترنت همراه) با telnet public_ip 3389 تست کنید.

اگر بسته است، وارد روتر شوید و Port Forwarding برای TCP port 3389 به IP داخلی سرور اضافه کنید.

بررسی کنید ISP پورت 3389 را بلوک نکرده باشد؛ برخی ISPها پورت‌های ریموت را فیلتر می‌کنند. در این صورت از پورت غیرمتعارف یا VPN استفاده کنید.

اطمینان از Security Groups در Cloud (مثلاً AWS Security Group، Azure NSG) که پورت را باز کرده‌اند.

در نهایت، برای امنیت بهتر، توصیه شود به‌جای باز کردن مستقیم 3389 روی اینترنت از VPN یا RD Gateway استفاده کنید.

 

نمونه 2 — سناریوی CredSSP پس از به‌روزرسانی

– علائم: پس از نصب به‌روزرسانی امنیتی روی کلاینت یا سرور، اتصال با خطای CredSSP رد می‌شود.

– گام‌ها:

بررسی نسخه‌های به‌روزرسانی نصب‌شده روی کلاینت و سرور.

Policy مربوط به Encryption Oracle Remediation را در Group Policy یا رجیستری مقایسه کرده و یکی‌سازی کنید.

اگر امکان دارد، هر دو طرف را به آخرین به‌روزرسانی‌ها برسانید.

به‌عنوان راه‌حل موقت و تنها در شبکه مطمئن، می‌توانید Encryption Oracle Remediation را به “Vulnerable” تغییر دهید اما این کار ریسک امنیتی دارد و نباید پایدار بماند.

 

نمونه 3 — سناریوی قطع ناگهانی پس از چند دقیقه

– علائم: نشست ایجاد می‌شود ولی پس از چند دقیقه قطع می‌گردد.

– گام‌ها:

بررسی Session Time Limits در RDSH یا GPO و افزایش زمان‌های timeout.

بررسی لاگ‌های Event Viewer در زمان قطع برای یافتن Event ID و پیام.

تست شبکه با continuous ping و بررسی packet loss.

اگر سرور مجازی است، بررسی host node برای بار زیاد یا migration که ممکن است جلسه را قطع کند.

در صورت وجود load balancer، بررسی health check interval و session persistence (stickiness).

 

فصل 6 — امنیت و بهترین شیوه‌ها برای RDP

 

از VPN یا RD Gateway استفاده کنید

– باز کردن RDP مستقیم روی اینترنت خطرناک است؛ VPN یا RD Gateway لایهٔ اضافهٔ احراز هویت و تونل‌سازی فراهم می‌کند.

تغییر پورت پیش‌فرض (با احتیاط)

– تغییر پورت 3389 به پورت غیرمتعارف می‌تواند حملات اسکریپتی را کاهش دهد اما امنیت بنیادی را افزایش نمی‌دهد. هنوز باید فایروال/IDS فعال باشد.

استفاده از MFA و سیاست‌های قوی رمز عبور

– اعمال احراز هویت چندعاملی برای حساب‌های مدیریتی و کاربران با دسترسی از راه دور.

محدود کردن دسترسی با IP whitelisting

– قوانین فایروال که فقط IPهای مشخص را مجاز می‌کنند.

نظارت و لاگ‌برداری مداوم

– فعال کردن auditing برای Logon events و مانیتورینگ تلاش‌های ناموفق، و استفاده از SIEM برای تحلیل.

به‌کارگیری least privilege

– ارائهٔ حداقل مجوزهای لازم برای انجام کارها؛ استفاده از حساب‌های مدیریتی فقط برای وظایف مدیریتی.

به‌روزرسانی منظم

– Patch management برای رفع آسیب‌پذیری‌ها و هماهنگی نسخه‌ها.

جلوگیری از ریدایرکت‌های غیرضروری

– به‌خصوص در محیط‌های حساس، device redirection ممکن است استفاده شود تا بدافزار به سرور منتقل شود؛ سیاست‌ها را متناسب تنظیم کنید.

 

فصل 7 — چک‌لیست عملی نهایی

 

شبکه و دسترسی

– **Ping** به آدرس سرور موفق باشد.

– **Test-NetConnection/Telnet** روی پورت RDP (پیش‌فرض 3389) موفق باشد.

– در صورت دسترسی از خارج، Public IP و Port Forwarding بررسی و صحیح باشد.

سرویس و پیکربندی محلی

– سرویس Remote Desktop (TermService) در وضعیت Running باشد.

– RDP در Settings یا System Properties فعال باشد.

– آدرس IP سرور ثابت یا رزرو DHCP شده باشد.

حساب‌ها و اجازه‌ها

– کاربر عضو Remote Desktop Users یا Administrator باشد.

– حساب قفل یا منقضی نباشد.

– فرمت نام کاربری (DOMAIN\user یا user@domain) درست باشد.

فایروال و امنیت شبکه

– قانون inbound فایروال برای پورت RDP فعال باشد.

– تجهیزات میانی (روتر/فایروال/Cloud NSG) پورت را باز کرده و به IP درست فوروارد کنند.

– از باز کردن مستقیم 3389 به اینترنت پرهیز شده یا با VPN/RD Gateway محافظت شده باشد.

احراز هویت و گواهی

– NLA تنظیمات سازگار بین کلاینت و سرور دارد.

– گواهی‌نامه TLS معتبر یا CA داخلی نصب شده و تاریخ/ساعت هماهنگ است.

پایداری و عملکرد

– بررسی مصرف CPU/RAM/IO روی سرور؛ شواهد Resource exhaustion وجود نداشته باشد.

– Session Time Limits و Idle timeouts متناسب تنظیم شده باشند.

لاگ‌ها و اطلاعات عیب‌یابی

– Event Viewer پیام‌های مرتبط ثبت شده و یادداشت شوند (Event ID و متن).

– خروجی Test-NetConnection، netstat، و دستورات بررسی فایروال ذخیره شود.

اقدامات اضطراری

– دسترسی کنسول (KVM/Hypervisor) یا اینترانت برای بازیابی رمز یا تنظیمات داشته باشید.

– برنامه پشتیبان‌گیری از پیکربندی‌ها و تصاویر سیستم موجود باشد.

 

فصل 8 — سناریوهای پیشرفته و نکات راهکارمحور

 

استفاده از RD Gateway برای دسترسی امن‌تر

– RD Gateway ترافیک RDP را روی HTTPS (پورت 443) تونل می‌کند؛ این روش امکان عبور از فایروال‌های شرکتی را فراهم و لایهٔ رمزنگاری/احراز هویت اضافی می‌سازد.

– پیکربندی شامل نصب گواهی معتبر روی Gateway، تعریف Authorization Policies و Resource Policies و اتصال با استفاده از Gateway در کلاینت است.

 

برخورد با حملات Brute-force و Ransomware

– فعال کردن account lockout policy با محدودیت مناسب.

– مانیتور کردن تلاش‌های ناموفق و استفاده از IPS/IDS برای بلاک خودکار IPهای مهاجم.

– جداسازی سرورهای حساس از شبکه عمومی و عدم استفاده از ریدایرکت‌های غیرضروری.

 

مقیاس‌پذیری در محیط‌های بزرگ (RDS Farm)

– استفاده از Connection Broker برای توزیع نشست‌ها.

– Load balancing و Session Host Pools برای مدیریت بار.

– Monitoring مرکزی برای health و performance هر Session Host.

 

تجربه کاربری گرافیکی پیشرفته

– برای برنامه‌های گرافیکی سنگین، استفاده از GPU passthrough یا vGPU و تکنیک‌های بهینه‌سازی RDP (RemoteFX / GPU acceleration) مفید است.

– بررسی سازگاری با نسخه‌های ویندوز و درایورهای GPU، و توجه به محدودیت‌های RemoteFX (که در بعضی نسخه‌ها منسوخ شده).

 

استفاده از لاگ‌ها برای تحلیل حملات یا خطاهای مکرر

– جمع‌آوری لاگ‌های Logon/Logoff، RemoteConnectionManager و Security به SIEM.

– ساخت هشدارهای اتوماتیک برای الگوهای غیرعادی (تلاش‌های زیاد از IPهای مختلف، لاگین‌های در ساعات غیرمعمول).

 

فصل 9 — منابع و فرمت‌های دستوری مفید

 

– PowerShell: Test-NetConnection -ComputerName <IP_or_FQDN> -Port 3389 -InformationLevel Detailed

– بررسی سرویس: Get-Service -Name TermService

– بررسی فایروال: Get-NetFirewallRule | Where-Object {$_.DisplayName -like “*Remote*”}

– netstat: netstat -an | find “3389”

– بررسی لاگ‌ها: eventvwr.msc -> Applications and Services Logs -> Microsoft -> Windows -> TerminalServices-*

– بررسی پورت از ماشین محلی: telnet <server_ip> 3389 (یا استفاده از Test-NetConnection)

– بررسی DNS: nslookup <hostname>

 

فصل 10 — جمع‌بندی و توصیه‌های اجرایی کوتاه

 

– روند عیب‌یابی مؤثر: ابتدا لایهٔ شبکه (پینگ، پورت)، سپس سرویس/مجوزها، بعد فایروال/مسیر، و نهایتاً لاگ‌ها و تنظیمات امنیتی.

– به‌روزرسانی همگانی و هماهنگی پچ‌ها بین کلاینت و سرور احتمال خطاهای ناشی از ناسازگاری را کاهش می‌دهد.

– برای دسترسی از اینترنت از VPN یا RD Gateway استفاده کنید؛ باز کردن مستقیم 3389 ریسک‌پذیر است.

– لاگ‌گیری و مانیتورینگ فعال را فراموش نکنید — بسیاری از مشکلات با تحلیل Event ID و زمان رخداد قابل ردیابی‌اند.

4.6/5 - (3388 امتیاز)

ارسال دیدگاه

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *


5 - 8

قوانین

قوانین ارسال دیدگاه

لطفاً در ارسال دیدگاه از کلمات مناسب استفاده کنید. ارسال اسپم ممنوع است.