VPN 경유 RDP 멈춤: 입력은 아직 작동하니 전송 방식을 시험하세요

화면이 갱신을 멈췄는데 마우스가 계속 원격 데스크톱 위를 미끄러진다면 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 릴리스마다 전송 동작이 바뀌었으므로 클라이언트 버전을 기록에 남기세요.

호스트 하나만 멈추고 나머지는 괜찮을 때

그 외에는 건강한 서브넷에서 호스트 하나만 실패하면 원인은 터널에서 멀어집니다. VPN 설정을 건드리기 전에 경로 MTU와 원격 화면 스택을 확인하세요.

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

응답이 있으면 경로가 그 크기에서 단편화 없이 전 크기 패킷을 나른다는 뜻이고, 단편화 금지 플래그와 함께 실패하면 터널의 MTU에 주의가 필요하다는 신호입니다. 1472바이트가 통과하고 그 호스트만 멈춘다면 네트워크가 아니라 그래픽 드라이버와 부하를 보세요. 같은 머신으로의 빠른 파일 복사는 처리량에 대한 말이고 RDP 그래픽 채널에 대한 말이 아닙니다. 한 번에 변수 하나만 바꾸고 같은 화면 동작을 반복해 비교가 의미를 갖게 하세요.

세션이 아예 열리지 않으면 그것은 멈춤이 아니라 도달 가능성이므로 여기서 멈추세요. 그렇지 않다면 증상을 바꾼 전송 설정을 유지하고 클라이언트 버전과 함께 기록하세요.