Заморозка RDP через VPN: введення ще працює, тому перевірте транспорт

Коли зображення перестає оновлюватися, але миша все ще ковзає віддаленим робочим столом, очевидний висновок — VPN впав. Цей висновок зазвичай хибний. Застиглий кадр із робочим введенням означає, що сеанс і його канал введення живі, і це зсуває несправність у бік транспорту графіки, а не маршрутизації чи облікових даних. Два швидкі спостереження розділяють три несправності, які користувачі описують одним словом.

Чого заморозка вам не каже

Віддалений робочий стіл передає введення й оновлення екрана через TCP 3389, а сучасні клієнти Windows можуть додати транспорт UDP для графічно важкої частини потоку. У тунелі, який фрагментує або відкидає більші дейтаграми, надійний канал далі несе натискання клавіш, поки графічний канал застрягає. Результат — дивне поєднання застиглого зображення й чутливої клавіатури. Це також пояснює, чому повторне підключення іноді лікує симптом на хвилину, а потім повертає його.

Сеанс, який від'єднується й під'єднується знову, — це інша несправність, а той, що взагалі не відкривається, — третя. Якщо спершу назвати форму, ви не перевірятимете не той рівень.

Розділіть три несправності двома командами

Виключити доступність дешево. Перевірте порт RDP з клієнта, потім прочитайте стан сеансу на хості.

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

Невдалий тест TCP означає, що сеанс так і не відкрився, тому розглядайте це як проблему брандмауера, області або служби, а не як заморозку. Успішний тест з активним сеансом підтверджує, що канал керування існує, і це саме випадок застиглого зображення. Запускайте запит до хоста з облікового запису, якому дозволено бачити сеанси, бо помилка прав виглядає як порожній список. Запишіть ID і стан сеансу, оскільки від'єднаний сеанс, що зберігає свій ID, не те саме, що активний.

Вимкніть транспорт 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. Змінюйте по одній змінній і повторюйте ту саму дію на екрані, щоб порівняння щось означало.

Якщо сеанс узагалі не відкривається, зупиніться тут, бо це доступність, а не заморозка. Інакше збережіть налаштування транспорту, яке змінило симптом, і запишіть його разом з версією клієнта.