تجمّد RDP عبر VPN: الإدخال ما زال يعمل، فاختبر النقل

عندما تتوقف الصورة عن التحديث بينما يظل المؤشر ينزلق عبر سطح المكتب البعيد، فالاستنتاج البديهي أن الشبكة الخاصة الافتراضية سقطت. هذا الاستنتاج خاطئ في الغالب. إطار متجمّد مع إدخال يعمل يعني أن الجلسة وقناة إدخالها ما زالتا حيّتين، وهذا يدفع العطل نحو نقل الرسوميات لا نحو التوجيه أو بيانات الاعتماد. ملاحظتان سريعتان تفصلان الأعطال الثلاثة التي يصفها المستخدمون بالكلمة نفسها.

ما لا يخبرك به التجمّد

ينقل سطح المكتب البعيد الإدخال وتحديثات الشاشة عبر TCP 3389، ويمكن لعملاء Windows الحاليين إضافة نقل UDP للجزء الكثيف من البث الرسومي. على نفق يجزّئ أو يُسقط مخططات بيانات أكبر، تواصل القناة الموثوقة حمل ضغطات المفاتيح بينما تتعطّل قناة الرسوميات. والنتيجة هي المزيج الغريب بين صورة عالقة ولوحة مفاتيح مستجيبة. وهذا يفسّر أيضًا لماذا يعالج إعادة الاتصال العرض أحيانًا لدقيقة ثم يعيده.

الجلسة التي تنقطع ثم تعود للاتصال عطل مختلف، والجلسة التي لا تُفتح إطلاقًا عطل ثالث. تسمية الشكل أولًا تمنعك من اختبار الطبقة الخطأ.

افصل الأعطال الثلاثة بأمرين

التحقق من إمكانية الوصول غير مكلف. اختبر منفذ RDP من العميل، ثم اقرأ حالة الجلسة على المضيف.

Test-NetConnection rdp-host.example.com -Port 3389
query user /server:rdp-host

اختبار TCP فاشل يعني أن الجلسة لم تُفتح قط، فتعامل معه كمشكلة جدار حماية أو نطاق أو خدمة لا كتجمّد. الاختبار الناجح مع جلسة نشطة يؤكد وجود قناة التحكم، وهي حالة الصورة المتجمّدة بالضبط. شغّل استعلام المضيف من حساب مسموح له برؤية الجلسات، لأن خطأ الأذونات يبدو كقائمة فارغة. سجّل معرّف الجلسة وحالتها، لأن جلسة منقطعة تحتفظ بمعرّفها ليست كجلسة نشطة.

أوقف نقل UDP وقارن

إن كانت الشاشة وحدها هي التي تتعطّل، فقارن نقل العملاء تغييرًا واحدًا في كل مرة. العميل المدمج وعميل Store لا يتشاركان حزمة واحدة، والسياسة أدناه تزيل UDP من العميل المدمج.

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDP

القيمة 1 تعني أن UDP متوقف بالفعل لذلك العميل، فتجمّد يصمد أمام الإعداد ليس مشكلة مسار UDP. عندما تكون القيمة مفقودة، فعّل السياسة وأعد الاتصال وكرر الإجراء نفسه الذي تجمّد سابقًا. اختبر عميل Store كخطوة منفصلة بدلًا من دمج التغييرين، وإلا فلن تعرف أيهما كان مهمًا. احتفظ بإصدار العميل في ملاحظاتك، لأن سلوك النقل تغيّر عبر إصدارات Windows.

عندما يتجمّد مضيف واحد بينما البقية بخير

مضيف واحد فاشل في شبكة فرعية سليمة يشير بعيدًا عن النفق. تحقق من MTU المسار ومكدس العرض البعيد قبل لمس إعدادات VPN.

ping -f -l 1472 rdp-host.example.com

الرد يثبت أن المسار يحمل حزمة كاملة الحجم دون تجزئة بذلك الحجم، بينما الفشل مع علامة عدم التجزئة يشير إلى أن MTU النفق يحتاج إلى انتباه. إذا مرّت 1472 بايت وتجمّد ذلك المضيف وحده، فانظر إلى برنامج تشغيل الرسوميات والحمل لديه لا إلى الشبكة. نسخ ملف سريع إلى الجهاز نفسه يقول شيئًا عن الإنتاجية لا عن قناة رسوميات RDP. غيّر متغيرًا واحدًا في كل مرة وكرر الإجراء نفسه على الشاشة ليكون للمقارنة معنى.

إذا لم تُفتح الجلسة إطلاقًا، فتوقف هنا، لأن ذلك إمكانية وصول لا تجمّد. وإلا فأبقِ إعداد النقل الذي غيّر العرض وسجّله مع إصدار العميل.