วิธีการระบุและแก้ไขนโยบายเครือข่ายที่บล็อก RDP ใน Windows

หากการเชื่อมต่อเดสก์ท็อประยะไกลของคุณหยุดทำงานกะทันหัน คุณอาจคิดว่าเป็นไฟร์วอลล์หรือเครื่องถูกปิดอยู่ แต่สำหรับ RDP สาเหตุที่แท้จริงมักจะเป็น... นโยบายเครือข่าย GPO หรือบริการที่บล็อกพอร์ต 3389 โดยไม่มีการแจ้งเตือน ข่าวดี: ด้วยลำดับการตรวจสอบที่เป็นระเบียบ คุณสามารถแยกแยะข้อผิดพลาดได้ภายในไม่กี่นาที

ในคู่มือนี้ คุณจะพบกับขั้นตอนปฏิบัติและได้รับการพิสูจน์แล้วสำหรับการวินิจฉัยและแก้ไข นโยบาย กฎ และการกำหนดค่าที่ป้องกัน RDP ใน Windowsทั้งบนอุปกรณ์ในพื้นที่และระยะไกล บนเครือข่ายองค์กร VPN และแม้กระทั่งในเมฆเช่น Google คลาวด์ คุณยังจะได้เห็นวิธีจัดการกับข้อผิดพลาดในการรับรองความถูกต้อง (CredSSP), ใบรับรอง, ความขัดแย้งของพอร์ต, DNS และประสิทธิภาพ รวมถึงทางเลือกอื่นๆ เมื่อคุณต้องการบางอย่างที่ใช้งานได้จริงโดยไม่ต้องเปิดพอร์ต

วิธีตรวจจับว่านโยบายหรือเครือข่ายกำลังบล็อก RDP หรือไม่

ก่อนที่จะแตะรีจิสทรีหรือไฟร์วอลล์ ควรตรวจสอบให้แน่ใจว่าปัญหาอยู่ที่ การเข้าถึงเครือข่าย การกรอง หรือความอิ่มตัวทางลัดที่เป็นประโยชน์จากคอมพิวเตอร์เครื่องอื่นคือการทดสอบการเข้าถึงพอร์ตโดยใช้ยูทิลิตี้เช่น psping: psping -accepteula <IP-equipo>:3389. ถ้าคุณเห็น กำลังเชื่อมต่อกับ … ด้วยความพยายามที่ไม่ประสบผลสำเร็จหรือ คอมพิวเตอร์ระยะไกลปฏิเสธการเชื่อมต่อเครือข่าย, บ่งชี้ถึงการบล็อคกลางหรือการหยุดให้บริการ

ทดสอบจากหลายแหล่ง (ซับเน็ตอื่น VPN อื่น เครือข่ายภายในบ้าน หรือ 4G) เพื่อดูว่ามีการบล็อกหรือไม่ เลือกตามส่วนหรือตามแหล่งกำเนิดหากล้มเหลวจากทุกด้าน แสดงว่าอาจถูกบล็อกโดยไฟร์วอลล์รอบนอกหรือตัว Windows เอง หากล้มเหลวเพียงด้านเดียว ให้ตรวจสอบรายการอนุญาต ACL และกฎไฟร์วอลล์ ระดับกลาง.

ตรวจสอบสถานะของ RDP และบริการต่างๆ ได้อย่างรวดเร็ว

เริ่มต้นด้วยการตรวจสอบว่าระบบระยะไกลอนุญาตการเชื่อมต่อเดสก์ท็อประยะไกลและบริการกำลังทำงานอยู่หรือไม่ ซึ่งจะตัดพื้นฐานออกไปด้วย สองหรือสาม คำสั่ง.

ในเครื่องท้องถิ่น การเปิดใช้งาน RDP นั้นง่ายดายเพียงแค่เปิดการตั้งค่าและเปิดใช้งาน เดสก์ท็อประยะไกล (ดู การใช้เดสก์ท็อประยะไกล Windows 11หากต้องการควบคุมที่ละเอียดยิ่งขึ้น (หรือหาก UI ไม่ตอบสนอง) ให้ตรวจสอบบันทึกที่: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server y HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services. มูลค่า fDenyTSConnections จะต้องเป็น 0 (ค่า 1 หมายถึง RDP ถูกปิดใช้งาน)

เชื่อมต่อกับรีจิสทรีเครือข่ายจาก Registry Editor (ไฟล์ > เชื่อมต่อกับรีจิสทรีเครือข่าย) นำทางไปยังเส้นทางเดียวกัน และยืนยันว่าไม่มีนโยบายบังคับให้บล็อก หากปรากฏ fDenyTSConnections=1, เปลี่ยนเป็น 0 และสังเกตว่า ผ่านไปไม่กี่นาทีก็กลับมาเป็น 1 (สัญลักษณ์ของ GPO ที่แพร่หลาย)

นอกจากนี้ ตรวจสอบว่าบริการที่จำเป็นกำลังทำงานอยู่ที่ทั้งสองด้าน: บริการเดสก์ท็อประยะไกล (TermService) y ตัวเปลี่ยนเส้นทางพอร์ตโหมดผู้ใช้ของบริการเดสก์ท็อประยะไกล (UmRdpService)คุณสามารถทำได้ใน services.msc หรือด้วย PowerShellหากคุณต้องการคำแนะนำสำหรับบริการแก้ไข โปรดดู ปรับเปลี่ยนบริการใน Windows 11หากใครถูกกักตัว เริ่มมันและลองอีกครั้ง.

วัตถุนโยบายกลุ่ม (GPO): วิธีการบล็อกและวิธีปลดบล็อก

หากไม่สามารถเปิดใช้งาน RDP ผ่านอินเทอร์เฟซได้ หรือค่ารีจิสทรีถูกย้อนกลับ มีแนวโน้มสูงว่านโยบายจะถูกบังคับใช้ หากต้องการระบุนโยบายนี้บนเครื่องที่ได้รับผลกระทบ ให้รันคำสั่งต่อไปนี้บน CMD สูง gpresult /H c:\gpresult.html และเปิดรายงานภายใต้ การกำหนดค่าคอมพิวเตอร์ > เทมเพลตการดูแลระบบ > ส่วนประกอบ Windows > บริการเดสก์ท็อประยะไกล > โฮสต์เซสชันเดสก์ท็อประยะไกล > การเชื่อมต่อ คำสั่งกำลังมองหา อนุญาตให้ผู้ใช้เชื่อมต่อจากระยะไกลโดยใช้บริการเดสก์ท็อประยะไกล.

หากคุณมองเห็นมันเป็น ปิดการใช้งานศึกษารายงานเพื่อดูว่า GPO ที่ชนะ และใช้ในขอบเขตใด (ไซต์ โดเมน หรือ OU) และตรวจสอบด้วยว่า การเข้าร่วมโดเมนใน Windows หากคุณสงสัยว่ามีปัญหากับโดเมน ให้เปลี่ยนนโยบายนั้นจาก Group Policy Object Editor (GPE) ในระดับที่เหมาะสม เปิดใช้งานหรือไม่ได้กำหนดค่าและในทีมที่เกี่ยวข้องก็บังคับให้มีการใช้งานด้วย gpupdate /force.

หากคุณจัดการผ่าน GPMC คุณยังสามารถลบลิงก์จาก GPO นั้นใน หน่วยองค์กร ซึ่งใช้กับอุปกรณ์ที่ได้รับผลกระทบ โปรดจำไว้ว่าหากบล็อกมาจาก ซอฟต์แวร์\นโยบายGPO จะเขียนรีจิสทรีใหม่จนกว่าคุณจะลบหรือแก้ไขนโยบาย

สำหรับเครื่องระยะไกล ให้สร้างรายงานแบบเดียวกับที่ใช้ในเครื่องในพื้นที่ โดยเพิ่มพารามิเตอร์คอมพิวเตอร์: gpresult /S <nombre-equipo> /H c:\gpresult-<nombre-equipo>.htmlซึ่งจะให้โครงสร้างข้อมูลเดียวกันแก่คุณเพื่อตรวจสอบ GPO ที่เป็นสาเหตุ

ผู้ฟัง พอร์ต และความขัดแย้งบน 3389

แม้ว่าคำสั่งจะถูกต้อง แต่หากตัวรับฟัง RDP ไม่ได้รับฟัง ก็จะไม่มีเซสชันเกิดขึ้น ใน PowerShell ที่ได้รับการยกระดับ (แบบโลคัลหรือแบบรีโมตด้วย Enter-PSSession -ComputerName <equipo>), ดำเนินการ qwinsta และตรวจสอบว่ารายการมีอยู่ rdp-tcp กับรัฐ ฟังหากไม่ปรากฏขึ้นผู้ฟังอาจเสียหายได้

วิธีการที่เชื่อถือได้เกี่ยวข้องกับการส่งออกคีย์ตัวรับฟังจากเครื่องที่มีสุขภาพดีที่มี Windows เวอร์ชันเดียวกัน: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcpบนคอมพิวเตอร์ที่ได้รับผลกระทบ ให้บันทึกสำเนาของสถานะปัจจุบันด้วย reg export "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-tcp" C:\Rdp-tcp-backup.reg, ลบคีย์ออก (Remove-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-tcp' -Recurse -Force) ไฟล์ .reg ที่ดีมีความสำคัญและ เริ่ม TermService ใหม่.

หลังจากนั้นให้ตรวจสอบพอร์ต RDP ควรรับฟังอยู่ 3389. เช็คเอาท์ HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\<listener> และมูลค่า PortNumberหากไม่ใช่ 3389 และคุณไม่มีเหตุผลด้านความปลอดภัยที่จะต้องเปลี่ยนแปลง ให้ย้อนกลับไปเป็น 3389 และเริ่มบริการใหม่

เพื่อตรวจจับความขัดแย้ง ให้รัน cmd /c 'netstat -ano | find "3389"' และจดบันทึก PID ที่อยู่ในสถานะ ฟังแล้วด้วย cmd /c 'tasklist /svc | find "<PID>"' ระบุกระบวนการ หากไม่ใช่ TermServiceกำหนดค่าบริการนั้นใหม่ไปยังพอร์ตอื่น ถอนการติดตั้งหากไม่จำเป็น หรือเป็นทางเลือกสุดท้าย เปลี่ยนพอร์ต RDP และเชื่อมต่อโดยระบุ IP:พอร์ต (ไม่เหมาะสำหรับการดูแลระบบมาตรฐาน)

ใบรับรอง RDP และสิทธิ์ MachineKeys

สาเหตุทั่วไปอีกประการหนึ่งของการเชื่อมต่อที่ไม่สมบูรณ์คือ ใบรับรอง RDP ที่เสียหายหรือไม่ได้สร้างขึ้นใหม่เปิดใบรับรอง MMC สำหรับบัญชีทีม ไปที่ เดสก์ท็อประยะไกล > ใบรับรอง และลบใบรับรอง RDP ที่ลงนามด้วยตนเอง รีสตาร์ทบริการเดสก์ท็อประยะไกลและรีเฟรช: บริการใหม่จะถูกสร้างขึ้นโดยอัตโนมัติ

หากไม่ปรากฏให้ตรวจสอบสิทธิ์ของ C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys. ทำให้เเน่นอน BUILTIN\ผู้ดูแลระบบ มีการควบคุมทั้งหมดและ ทุกคน เชื่อใจได้ การอ่านและการเขียนหากไม่มี ACL เหล่านี้ Windows จะไม่สามารถสร้างคีย์และใบรับรองที่จำเป็นสำหรับ RDP ได้

การทดสอบไฟร์วอลล์และช่วงของ Windows

บนระบบไคลเอนต์และเซิร์ฟเวอร์ windows Defender ไฟร์วอลล์ต้องการกฎขาเข้าแบบเปิดสำหรับ RDP ตรวจสอบกฎในตัว “เดสก์ท็อประยะไกล – โหมดผู้ใช้ (TCP-In)"กับ netsh advfirewall firewall show rule name="Remote Desktop - User Mode (TCP-In)"จะต้องเปิดใช้งานและใช้กับโปรไฟล์ โปรโตคอล TCP และพอร์ตท้องถิ่น 3389 ที่เหมาะสม

หากคุณจัดการผ่านอินเทอร์เฟซ ให้ไปที่ไฟร์วอลล์ Windows Defender > อนุญาตแอปหรือคุณสมบัติ และเลือก “เดสก์ท็อประยะไกล” ใน ส่วนตัว (และในที่สาธารณะก็ต่อเมื่อคุณมีเหตุผลที่ชัดเจน) ใน "การตั้งค่าขั้นสูง" ให้ตรวจสอบว่ากฎขาเข้าสำหรับ TCP 3389 ทำงานอยู่ ในขั้นตอนการแก้ไขปัญหา (ไม่ใช่บนเครือข่ายสาธารณะ) คุณสามารถปิดใช้งานไฟร์วอลล์ชั่วคราวเพื่อตรวจสอบว่าการเชื่อมต่อผ่านหรือไม่ แล้วเปิดใช้งานใหม่ทันที

จากภายนอก วิธีที่ชัดเจนที่สุดในการยืนยันการมาถึงที่ท่าเรือคือ psping: psping -accepteula <IP>:3389หากคุณได้รับ การสูญเสีย% 0สแต็กเครือข่ายและไฟร์วอลล์อนุญาตให้เชื่อมต่อได้ หากทุกอย่างเป็น การสูญเสีย% 100 o ปฏิเสธถึงเวลาที่จะยกระดับเป็นเครือข่าย/ไฟร์วอลล์ระดับกลางหรือตรวจสอบ NAT, VPN และ ตัวกรองระหว่างส่วนต่างๆ.

การตรวจสอบสิทธิ์: ข้อมูลประจำตัว CredSSP และการอนุญาต

ข้อผิดพลาดประเภทข้อมูลประจำตัวของคุณใช้ไม่ได้"หรือ"บัญชีนี้ไม่ได้รับอนุญาตสำหรับการเข้าสู่ระบบระยะไกล"โดยปกติแล้วการแก้ไขจะง่ายดาย: ตรวจสอบว่าชื่อผู้ใช้/รหัสผ่านมีรูปแบบที่ถูกต้อง (ตัวอย่างเช่น DOMINIO\usuario) ลบข้อมูลประจำตัวที่ล้าสมัยใน ผู้จัดการข้อมูลรับรอง และยืนยันว่าบัญชีไม่ได้ถูกบล็อค

ด้วย CredSSP หากอุปกรณ์ไม่ได้รับการอัปเดต จะเกิดความล้มเหลวในการยืนยันตัวตนที่ยากต่อการตีความ ตรวจสอบให้แน่ใจว่าคุณมี อัพเดตวินโดว์แล้ว ทั้งบนไคลเอนต์และโฮสต์ ในสภาพแวดล้อมรุ่นเก่า คุณสามารถเปิดใช้งานทางลัดใน GPO ได้ด้วย "อนุญาตการมอบหมายข้อมูลประจำตัวที่บันทึกไว้ด้วยการตรวจสอบสิทธิ์เซิร์ฟเวอร์แบบ NTLM เท่านั้น" หรือตั้งค่าผ่านรีจิสทรี AllowEncryptionOracle a 2 en HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System.

อย่าลืมการเป็นสมาชิกกลุ่ม: ในทีมที่ไม่ใช่โดเมน ให้เพิ่มบัญชีลงใน ผู้ใช้เดสก์ท็อประยะไกล จากการจัดการคอมพิวเตอร์ > ผู้ใช้และกลุ่มภายใน ในโดเมน ให้ตรวจสอบว่าสมาชิกภาพเป็นไปตามข้อกำหนด นโยบาย Active Directory มีผลก่อนที่จะสัมผัสสิ่งใดๆ

DNS, VPN และตัวแปรเครือข่ายอื่น ๆ

หากคุณเชื่อมต่อโดยใช้ชื่อและที่อยู่ IP ของโฮสต์มีการเปลี่ยนแปลง ไคลเอนต์อาจยังคงชี้ไปยังที่อยู่เดิมเนื่องจากการแคช ทำความสะอาดด้วย ipconfig /flushdns และหากยังคงเกิดอาการดังกล่าว ให้ใช้ IP โดยตรง เพื่อตัดปัญหาเรื่องความละเอียด ให้ตรวจสอบว่าอะแดปเตอร์ใช้ เซิร์ฟเวอร์ DNS ที่ถูกต้อง ในแผงควบคุม > ศูนย์เครือข่าย > เปลี่ยนการตั้งค่าอะแดปเตอร์

เมื่อใช้ VPN ผู้ให้บริการบางรายจะบล็อกหรือเปลี่ยนเส้นทางพอร์ต 3389 หรือห่อหุ้มพอร์ตในลักษณะที่ขัดแย้งกับการเข้ารหัส RDP ให้ยกเลิกการเชื่อมต่อ VPN แล้วทดสอบ หรือปรับนโยบายเพื่ออนุญาต RDP อุโมงค์แยก หรือ "อนุญาตแอป" หากคุณตรวจพบการรบกวนหรือหน้าจอดำ ให้ลด MTU ลงหนึ่งจุด: netsh interface ipv4 show subinterfaces เพื่อดูมันและ netsh interface ipv4 set subinterface "Ethernet" mtu=1458 store=persistent เพื่อปรับแต่งมัน

หากไคลเอนต์ดูเหมือนไม่ตอบสนองแต่เซสชันยังคงอยู่ อาจเป็นปัญหาที่ ความละเอียดหรือขนาดหน้าต่างในไคลเอนต์การเชื่อมต่อเดสก์ท็อประยะไกล (mstsc) ให้คลิก "แสดงตัวเลือก" และบนแท็บการแสดงผล ให้เลื่อนแถบเลื่อนความละเอียดหรือเปิดใช้งานเต็มหน้าจอ ปัญหา "การเชื่อมต่อที่ไม่ทำงาน" หลายรายการได้รับการแก้ไขแล้ว การปรับหน้าต่าง.

ปัญหาที่ทราบและบริการคลาวด์: Windows 11 24H2 และ Google Cloud

มีรายงานกรณีที่เชื่อมต่อผ่าน RDP หน้าต่าง 11 24H2 เซสชั่นหยุดนิ่งเมื่อเริ่มต้น โดยเฉพาะใน เครื่องเสมือน เกี่ยวกับไฮเปอร์ไวเซอร์ แพตช์ชั่วคราวบางรายการยังไม่สามารถแก้ไขปัญหาได้ ควรอัปเดตระบบของคุณให้สมบูรณ์อยู่เสมอ และทดสอบไดรเวอร์วิดีโอ/vGPU ของไฮเปอร์ไวเซอร์ เนื่องจากบางครั้งปัญหาอาจเกิดจากไฮเปอร์ไวเซอร์ แผนภูมิหรือสแต็ก RDPการรีสตาร์ทโฮสต์จะช่วยคืนการเชื่อมต่อชั่วคราว แต่ทางแก้ไขก็คือต้องมีการอัปเดตสะสมและไดรเวอร์/เฟิร์มแวร์

ใน Google Compute Engine นอกเหนือจากรหัสผ่าน Windows ในเครื่อง (รีเซ็ตจาก จีคลาวด์ หรือคอนโซล) ตรวจสอบกฎ default-allow-rdpรายการกฎพร้อม gcloud compute firewall-rules list และถ้าขาดหายไปให้สร้างอันใหม่ด้วย gcloud compute firewall-rules create allow-rdp --allow tcp:3389. ตรวจสอบว่าคุณกำลังใช้ ที่อยู่ IP ภายนอกที่ถูกต้อง กับ gcloud compute instances listหากระบบปฏิบัติการมีการกำหนดค่าไม่ถูกต้อง ให้เข้าถึงได้ผ่าน คอนโซลอนุกรมแบบโต้ตอบ และดำเนินการ:

• บริการ: net start | find "Remote Desktop Services" (ถ้าไม่มีก็ net start "Remote Desktop Services")
• เปิดใช้งาน RDP: reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections (0 ก็โอเค; ถ้า 1: reg add ... /d 0)
• ไฟร์วอลล์: netsh advfirewall firewall show rule name="Remote Desktop - User Mode (TCP-In)" (แต่, netsh firewall set service remotedesktop enable)
• ชั้นความปลอดภัย: reg add "HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer /t REG_DWORD /d 1 /f
• NLA เริ่มต้น: reg add ... /v UserAuthentication /t REG_DWORD /d 0 /f

การวินิจฉัยขั้นสูง: เหตุการณ์ เครือข่าย และเครื่องมือ

เมื่อสิ่งที่กล่าวมาข้างต้นยังไม่สามารถแก้ไขปัญหาได้ ก็ถึงเวลาที่ต้องตรวจสอบ เหตุการณ์และร่องรอยเปิด Event Viewer และตรวจสอบใน Windows Logs > Application and System และในแหล่งที่มา TerminalServices-ตัวจัดการการเชื่อมต่อระยะไกล y Microsoft-Windows-RemoteDesktopServices-RdpCoreTS เพื่อแก้ไขข้อผิดพลาดให้ชัดเจนในแต่ละความพยายาม

บนเครือข่าย จับภาพด้วย Wireshark และกรองตาม tcp.port==3389 ตรวจสอบสัญญาณ SYN/SYN-ACK, การรีเซ็ต หรือสัญญาณหลุดระหว่างการเชื่อมต่อ หากไม่มีการรับส่งข้อมูล แสดงว่าบล็อกกำลังอยู่ระหว่างการเดินทาง หากมีการรับส่งข้อมูลและสัญญาณหลุดระหว่างการเจรจาความปลอดภัย ให้สงสัยว่า... การเข้ารหัส/NLA ไม่ตรงกันเพื่อทดสอบการเปิดท่าเรืออย่างรวดเร็ว telnet <IP> 3389 (หากเชื่อมต่อได้ก็สามารถเข้าถึงพอร์ตได้) คุณยังสามารถใช้ยูทิลิตี้อื่นๆ เช่น การใช้ ntttcp ใน Windows สำหรับการทดสอบประสิทธิภาพและความอิ่มตัว

Microsoft นำเสนอ RDP Protocol Monitor/Analyzer และใน Windows Server 2012/2012 R2 เครื่องมือวินิจฉัยบริการเดสก์ท็อประยะไกล เพื่อระบุปัญหาคอขวด หากคุณไม่สามารถจัดสรรเวลาให้กับปัญหาที่เกิดขึ้นซ้ำๆ ได้ ให้เตรียมสคริปต์ดังนี้: netsh int ip reset && netsh winsock reset สำหรับเครือข่ายและ taskkill /F /IM mstsc.exe && net stop termservice && net start termservice เพื่อล้างเซสชัน RDP และเริ่มบริการใหม่ (คำเตือน: ย่อเซสชันที่ใช้งานอยู่ให้สั้นลง).

“RDP – เกิดข้อผิดพลาดภายใน” ที่น่าอับอาย

ข้อความทั่วไปนี้มักจะซ่อน การจัดตำแหน่งที่ไม่ถูกต้องเพื่อความปลอดภัย ระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ ตรวจสอบว่าระดับการเข้ารหัสและเลเยอร์ความปลอดภัยตรงกัน (ใน GPO: Session Host Security > “Require the use of a specific security layer” และเลือก RDP (หาก TLS ล้มเหลว) หากเซิร์ฟเวอร์ต้องการ NLA แต่ไคลเอนต์ไม่ต้องการ ให้ยกเลิกการเลือก NLA ชั่วคราวใน System Properties > Remote เพื่อตรวจสอบว่านี่เป็นสาเหตุหรือไม่

ปัจจัยอื่นๆ: ไคลเอนต์ RDP ที่ล้าสมัยเทียบกับเซิร์ฟเวอร์ใหม่กว่า ปัญหาความน่าเชื่อถือของโดเมน (การเข้าร่วมโดเมนอีกครั้งอาจแก้ไขปัญหานี้ได้) หรือโปรไฟล์ความปลอดภัยที่บังคับใช้การเข้ารหัสที่ปลายทางไม่รองรับ ในประสบการณ์ลูกค้า ให้เปิดใช้งาน การเชื่อมต่อใหม่อัตโนมัติ และแคชบิตแมปถาวรเพื่อเซสชันที่มีความยืดหยุ่นมากขึ้น

เมื่อข้อผิดพลาดปรากฏขึ้นหลังจากการอัปเดต Windows และไม่มีสิ่งใดที่สมเหตุสมผล ให้พิจารณาย้อนกลับแพตช์เฉพาะนั้น (แผง > windows Update > ประวัติ > ถอนการติดตั้งการอัปเดต) หลังจากปรึกษาฟอรัมทางเทคนิค (เช่น กระทู้ของ แพทช์อังคาร) ในกรณีที่เป็นปัญหาที่ทราบแล้ว

ประสิทธิภาพ ความจุ และมัลติมีเดีย

หากข้อร้องเรียนไม่ใช่ "เชื่อมต่อไม่ได้" แต่เป็น "มีปัญหา" ให้เริ่มต้นด้วยการลดภาระจากไคลเอนต์ RDP: ลง ความละเอียดและความลึกของสีปิดใช้งานพื้นหลัง รูปแบบภาพ และการปรับความเรียบของแบบอักษรในแท็บประสบการณ์ มาตรการเหล่านี้ช่วยลดการใช้แบนด์วิดท์และปรับปรุงความหน่วง

บนเซิร์ฟเวอร์ ตรวจสอบ CPU/RAM/ดิสก์ใน ผู้จัดการงานหากถึงขีดจำกัดแล้ว เซสชัน RDP ใดๆ ก็จะล้มเหลว โปรดจำไว้ว่าเดสก์ท็อป Windows อนุญาตเฉพาะ การประชุมพร้อมกันWindows Server มีใบอนุญาตการดูแลระบบเริ่มต้นสองใบและต้องมีใบอนุญาต RDS CAL เพิ่มเติม

สำหรับเสียง ให้กำหนดค่าไคลเอนต์ RDP > ทรัพยากรภายในเครื่อง > เสียงระยะไกล เป็น "เล่นบนคอมพิวเตอร์เครื่องนี้" และตรวจสอบว่าบริการ Windows Audio และ "Windows Audio Endpoint Generator" กำลังทำงานอยู่ สำหรับวิดีโอขนาดใหญ่ RDP อาจไม่เหมาะสมเสมอไป สภาพแวดล้อมรุ่นเก่าบางระบบมี RemoteFX อยู่ แต่ในปัจจุบันนี้ ควรใช้ RemoteFX แทน โคเดกแบบปรับตัวและการเร่งความเร็วสมัยใหม่ หรือประเมินเครื่องมือที่ออกแบบมาเพื่อ ที่พริ้ว แผนภูมิ

กรณีเร่งด่วนและการแก้ปัญหาแบบเร่งด่วน

หาก Windows Defender กำลังบล็อกการเชื่อมต่อใน Windows 10/11 ให้ไปที่ไฟร์วอลล์ Windows Defender > อนุญาตให้ใช้แอปพลิเคชัน และเปิดใช้งาน “เดสก์ท็อประยะไกล” โดยทำเครื่องหมายในช่องส่วนตัว (และสาธารณะเท่านั้นหากเกี่ยวข้อง) กด ยอมรับ และทดสอบ ในเหตุการณ์จริงหลายๆ เหตุการณ์เหล่านี้ สามคลิก พวกเขาคือความแตกต่างระหว่างความหงุดหงิดและความสำเร็จ

หากคุณจำเป็นต้องเปลี่ยนพอร์ตเนื่องจากบริการอื่นกำลังใช้ 3389 ให้แก้ไข HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp > หมายเลขพอร์ตเช่น ใส่ 3390 รีสตาร์ทเซอร์วิสแล้วเชื่อมต่อเป็น IP:3390อย่าลืมปรับ ไฟร์วอลล์และ NAT ไปยังพอร์ตใหม่นั้น

ทางเลือกและเกตเวย์เมื่อคุณไม่สามารถเปิดพอร์ตได้

ในเครือข่ายที่การเปิด 3389 เป็นเรื่องที่ไม่สะดวก (หรือคุณไม่ต้องการเปิดเผย) ให้พิจารณาวิธีแก้ปัญหาด้วย ตัวกลางคลาวด์ ที่หลีกเลี่ยงกฎเกณฑ์ด้วยตนเองและความยุ่งยากของ DNS: RealVNC Connect นำเสนอ SSO และการจัดการแบบรวมศูนย์ โครเมี่ยมสก์ท็อประยะไกล ฟรีและใช้งานง่ายหากคุณใช้ Chrome อยู่แล้ว TeamViewer และ AnyDesk พวกเขาให้ความสำคัญกับความสะดวกในการใช้งานและความเร็วข้ามแพลตฟอร์ม นอกจากนี้ยังมีชุดโปรแกรมต่างๆ เช่น ทีเอสพลัสมุ่งเน้นการเสริมสร้างความปลอดภัยและลดความซับซ้อนในการเข้าถึงระยะไกลในระดับขนาดใหญ่

หากคุณจะอยู่ใน RDP ทางเลือกที่ปลอดภัยคือการตั้งค่า เกตเวย์เดสก์ท็อประยะไกล (RD Gateway)กำหนดให้ต้องมี NLA และ MFA และจำกัดการเข้าถึงผ่าน VPN หรือ IPSec นี่เป็นวิธีมาตรฐานในการให้สิทธิ์การเข้าถึงโดยไม่ต้องเปิดพอร์ต 3389 ให้กับผู้ใช้ทั่วโลก

แนวทางปฏิบัติด้านความปลอดภัยและการปฏิบัติตามที่ดี

เสริมสร้าง RDP ด้วยการเปิดใช้งาน สนชการใช้โปรโตคอลการเข้ารหัสที่ทันสมัย ​​และหากกรอบงานของคุณกำหนด (GDPR/HIPAA) การเปิดใช้งานนโยบายการเข้ารหัสที่รัดกุม (เช่น FIPS) และใบรับรองที่ถูกต้องซึ่งออกโดย CA ที่เชื่อถือได้ ปิดกั้นการเปิดเผยข้อมูลสาธารณะ จำกัดการใช้เครือข่ายส่วนตัว/VPN และบังคับใช้ MFA ได้ทุกที่ บนเกตเวย์หรือโบรกเกอร์

สุดท้ายนี้ให้จับตาดู บันทึกติดแผ่นแปะเป็นประจำและตรวจสอบเป็นระยะ ปัญหา RDP ส่วนใหญ่สามารถหลีกเลี่ยงได้ด้วยการใช้มาตรการเหล่านี้ร่วมกัน นโยบายที่ดีกฎไฟร์วอลล์ที่ชัดเจนและการตรวจสอบ