Когато картината спре да се обновява, но мишката все още се плъзга по отдалечения работен плот, очевидният извод е, че 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. Променяйте една променлива наведнъж и повтаряйте същото действие на екрана, за да има смисъл сравнението.

Ако сесията изобщо не се отваря, спрете тук, защото това е достъпност, а не замръзване. Иначе запазете транспортната настройка, която промени симптома, и я запишете с версията на клиента.

Подобни статии