Beku RDP lewat VPN: input masih bekerja, jadi uji transportnya

Ketika gambar berhenti diperbarui tetapi mouse masih meluncur di desktop jarak jauh, kesimpulan yang jelas adalah VPN putus. Kesimpulan itu biasanya salah. Bingkai beku dengan input yang bekerja berarti sesi dan saluran inputnya masih hidup, yang mendorong kesalahan ke arah transport grafis, bukan ke arah perutean atau kredensial. Dua pengamatan cepat memisahkan tiga kegagalan yang digambarkan pengguna dengan kata yang sama.

Apa yang tidak diberitahukan pembekuan kepada Anda

Desktop Jarak Jauh membawa input dan pembaruan layar melalui TCP 3389, dan klien Windows saat ini dapat menambahkan transport UDP untuk bagian aliran yang berat grafis. Pada terowongan yang memfragmentasi atau membuang datagram yang lebih besar, saluran andal terus membawa ketukan tombol sementara saluran grafis tersendat. Hasilnya adalah kombinasi aneh antara gambar yang macet dan papan ketik yang responsif. Ini juga menjelaskan mengapa menyambung ulang terkadang menyembuhkan gejala selama satu menit lalu mengembalikannya.

Sesi yang terputus dan menyambung kembali adalah kesalahan lain, dan sesi yang tidak pernah terbuka adalah yang ketiga. Menamai bentuknya lebih dulu mencegah Anda menguji lapisan yang salah.

Pisahkan tiga kegagalan dengan dua perintah

Menyingkirkan keterjangkauan itu murah. Uji port RDP dari klien, lalu baca status sesi di host.

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

Uji TCP yang gagal berarti sesi tidak pernah terbuka, jadi perlakukan itu sebagai masalah firewall, cakupan, atau layanan dan bukan pembekuan. Uji berhasil dengan sesi aktif memastikan saluran kontrol ada, yang persis kasus gambar beku. Jalankan kueri host dari akun yang diizinkan melihat sesi, karena kesalahan izin terlihat seperti daftar kosong. Catat ID dan status sesi, karena sesi terputus yang mempertahankan ID-nya tidak sama dengan sesi aktif.

Matikan transport UDP dan bandingkan

Jika hanya tampilan yang tersendat, bandingkan transport klien satu perubahan setiap kali. Klien bawaan dan klien Store tidak berbagi tumpukan yang sama, dan kebijakan di bawah menghapus UDP dari klien bawaan.

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

Nilai 1 berarti UDP sudah mati untuk klien itu, jadi pembekuan yang bertahan dari pengaturan itu bukan masalah jalur UDP. Jika nilainya tidak ada, aktifkan kebijakan, sambungkan ulang, dan ulangi persis tindakan yang membeku sebelumnya. Uji klien Store sebagai langkah terpisah alih-alih menggabungkan kedua perubahan, atau Anda tidak akan tahu mana yang penting. Simpan versi klien dalam catatan Anda, karena perilaku transport telah berubah di antara rilis Windows.

Ketika satu host membeku tetapi yang lain baik-baik saja

Satu host yang gagal di subnet yang sehat mengarah menjauh dari terowongan. Periksa MTU jalur dan tumpukan tampilan jarak jauh sebelum menyentuh pengaturan VPN.

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

Balasan membuktikan jalur membawa paket ukuran penuh tanpa fragmentasi pada ukuran itu, sementara kegagalan dengan tanda jangan-fragmentasi menunjukkan bahwa MTU terowongan perlu diperhatikan. Jika 1472 byte lolos dan hanya host itu yang membeku, lihat driver grafis dan bebannya, bukan jaringan. Salinan file yang cepat ke mesin yang sama mengatakan sesuatu tentang throughput, bukan tentang saluran grafis RDP. Ubah satu variabel setiap kali dan ulangi tindakan di layar yang sama agar perbandingannya berarti.

Jika sesi tidak pernah terbuka, berhenti di sini, karena itu keterjangkauan dan bukan pembekuan. Jika tidak, pertahankan pengaturan transport yang mengubah gejala dan catat bersama versi klien.