Замрзнување на 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. Менувајте една променлива одеднаш и повторувајте ја истата постапка на екранот за споредбата да има смисла.

Ако сесијата воопшто не се отвора, застанете тука, бидејќи тоа е достапност, а не замрзнување. Инаку задржете ја поставката за транспорт што го смени симптомот и запишете ја со верзијата на клиентот.