Zawieszanie RDP przez VPN: wejście wciąż działa, więc testuj transport

Gdy obraz przestaje się odświeżać, ale mysz nadal ślizga się po zdalnym pulpicie, oczywisty wniosek jest taki, że VPN padł. Ten wniosek zwykle jest błędny. Zamrożona klatka z działającym wejściem oznacza, że sesja i jej kanał wejściowy żyją, co kieruje usterkę ku transportowi grafiki, a nie ku routingowi czy danym logowania. Dwie szybkie obserwacje rozdzielają trzy usterki, które użytkownicy opisują tym samym słowem.

Czego zawieszenie ci nie mówi

Zdalny pulpit przenosi wejście i aktualizacje ekranu przez TCP 3389, a obecne klienty Windows mogą dodać transport UDP dla obciążonej graficznie części strumienia. W tunelu, który fragmentuje lub odrzuca większe datagramy, niezawodny kanał nadal przenosi naciśnięcia klawiszy, podczas gdy kanał grafiki się zatrzymuje. Wynikiem jest dziwne połączenie zablokowanego obrazu i reagującej klawiatury. To wyjaśnia też, dlaczego ponowne połączenie czasem leczy objaw na minutę, a potem go przywraca.

Sesja, która się rozłącza i łączy ponownie, to inna usterka, a ta, która w ogóle się nie otwiera, to trzecia. Nazwanie kształtu najpierw chroni przed testowaniem niewłaściwej warstwy.

Rozdziel trzy usterki dwoma poleceniami

Wykluczenie osiągalności jest tanie. Przetestuj port RDP z klienta, a potem odczytaj stan sesji na hoście.

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

Nieudany test TCP oznacza, że sesja nigdy się nie otworzyła, więc traktuj to jako problem zapory, zakresu lub usługi, a nie zawieszenie. Udany test z aktywną sesją potwierdza, że kanał sterowania istnieje, co jest dokładnie przypadkiem zamrożonego obrazu. Uruchom zapytanie do hosta z konta, które ma prawo widzieć sesje, bo błąd uprawnień wygląda jak pusta lista. Zapisz ID i stan sesji, ponieważ rozłączona sesja trzymająca swoje ID nie jest tym samym co aktywna.

Wyłącz transport UDP i porównaj

Jeśli zacina się tylko ekran, porównuj transporty klienta po jednej zmianie. Klient wbudowany i klient ze Store nie dzielą tego samego stosu, a polityka poniżej usuwa UDP z klienta wbudowanego.

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

Wartość 1 oznacza, że UDP jest już wyłączone dla tego klienta, więc zawieszenie, które przetrwa to ustawienie, nie jest problemem ścieżki UDP. Gdy wartości brakuje, włącz politykę, połącz się ponownie i powtórz dokładnie tę czynność, która wcześniej zamarzła. Testuj klienta ze Store jako osobny krok, zamiast łączyć obie zmiany, inaczej nie będziesz wiedzieć, która miała znaczenie. Zapisuj wersję klienta w notatkach, bo zachowanie transportu zmieniało się między wydaniami Windows.

Gdy jeden host zamarza, a pozostałe są w porządku

Pojedynczy uszkodzony host w poza tym zdrowiej podsieci wskazuje z dala od tunelu. Sprawdź MTU ścieżki i stos zdalnego wyświetlania, zanim dotkniesz ustawień VPN.

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

Odpowiedź dowodzi, że ścieżka przenosi pełnowymiarowy pakiet bez fragmentacji przy tym rozmiarze, a niepowodzenie z flagą zakazu fragmentacji sugeruje, że MTU tunelu wymaga uwagi. Jeśli 1472 bajty przechodzą i zawiesza się tylko ten host, patrz na jego sterownik grafiki i obciążenie, a nie na sieć. Szybkie kopiowanie pliku na tę samą maszynę mówi coś o przepustowości, a nie o kanale grafiki RDP. Zmieniaj jedną zmienną naraz i powtarzaj tę samą czynność na ekranie, żeby porównanie coś znaczyło.

Jeśli sesja w ogóle się nie otwiera, zatrzymaj się tutaj, bo to osiągalność, a nie zawieszenie. W przeciwnym razie zachowaj ustawienie transportu, które zmieniło objaw, i zapisz je wraz z wersją klienta.