เมื่อภาพหยุดอัปเดตแต่เมาส์ยังเลื่อนไปทั่วเดสก์ท็อประยะไกล ข้อสรุปที่ชัดเจนคือ 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 เปลี่ยนตัวแปรทีละตัวและทำซ้ำการกระทำบนหน้าจอเดิมเพื่อให้การเปรียบเทียบมีความหมาย

หากเซสชันไม่เคยเปิดเลย ให้หยุดตรงนี้ เพราะนั่นคือการเข้าถึงไม่ใช่อาการค้าง มิฉะนั้นให้เก็บการตั้งค่าการรับส่งที่เปลี่ยนอาการและบันทึกพร้อมเวอร์ชันไคลเอนต์

บทความที่เกี่ยวข้อง