RDP Shortpath는 Azure Virtual Desktop의 지원되는 플랫폼 및 세션 호스트에서 로컬 디바이스 Windows App 또는 원격 데스크톱 앱 간에 UDP 기반 전송을 설정합니다. 기본적으로 RDP(원격 데스크톱 프로토콜)는 TCP 기반 역방향 연결 전송을 시작한 다음 UDP를 사용하여 원격 세션을 설정하려고 시도합니다. UDP 연결이 성공하면 TCP 연결이 삭제되고 그렇지 않으면 TCP 연결이 대체 연결 메커니즘으로 사용됩니다.
UDP 기반 전송은 더 나은 연결 안정성과 보다 일관된 대기 시간을 제공합니다. TCP 기반 역방향 연결 전송은 다양한 네트워킹 구성과 최상의 호환성을 제공하며 RDP 연결을 설정하는 데 성공률이 높습니다.
RDP Shortpath는 다음 두 가지 방법으로 사용할 수 있습니다.
관리형 네트워크- Azure ExpressRoute 또는 사이트 간 VPN(가상 사설망)과 같은 프라이빗 연결을 사용할 때 클라이언트와 세션 호스트 간에 직접 연결이 설정됩니다. 관리형 네트워크를 사용하는 연결은 다음 방법 중 하나로 설정됩니다.
RDP Shortpath 수신기를 사용하도록 설정하고 각 세션 호스트의 인바운드 포트가 연결을 수락하도록 허용해야 하는 클라이언트 디바이스와 세션 호스트 간의 직접 UDP 연결입니다.
클라이언트와 세션 호스트 간의 NAT(단순 통과) 프로토콜을 사용하여 클라이언트 디바이스와 세션 호스트 간의 직접 UDP 연결입니다. 세션 호스트의 인바운드 포트는 허용되지 않아도 됩니다.
공용 네트워크- 공용 연결을 사용할 때 클라이언트와 세션 호스트 간에 직접 연결이 설정됩니다. 공용 연결을 사용하는 경우 기본 설정 순서대로 여기에 나열되는 두 가지 연결 형식이 있습니다.
클라이언트와 세션 호스트 간의 NAT(STUN) 아래의 단순 순회 프로토콜을 사용하는 직접 UDP 연결입니다.
클라이언트와 세션 호스트 간에 릴레이 NAT(릴레이 NAT) 프로토콜을 사용하여 릴레이 된 UDP 연결입니다.
RDP Shortpath에 사용되는 전송은 URCP(유니버설 속도 제어 프로토콜)를 기반으로 합니다. URCP는 네트워크 조건의 활성 모니터링을 통해 UDP를 향상시키고 공정하고 전체 링크 사용률을 제공합니다. URCP는 필요에 따라 낮은 지연 및 손실 수준에서 작동합니다.
중요
- AZURE Virtual Desktop용 STUN을 통한 공용 네트워크용 RDP Shortpath는 Azure 퍼블릭 클라우드 및 Azure Government 클라우드에서 사용할 수 있습니다.
- Azure Virtual Desktop용 TURN을 통한 공용 네트워크용 RDP Shortpath는 Azure 퍼블릭 클라우드에서만 사용할 수 있습니다.
주요 장점
RDP Shortpath를 사용하면 다음과 같은 주요 이점이 있습니다.
RDP Shortpath 작동 방식
관리되는 네트워크 및 공용 네트워크에서 RDP Shortpath가 작동하는 방식을 알아보려면 다음 탭을 각각 선택합니다.
다음 방법을 사용하여 관리되는 네트워크에서 RDP Shortpath를 사용하는 데 필요한 직접 가시선 연결을 달성할 수 있습니다.
직접 가시선 연결이 있으면 클라이언트가 방화벽에 의해 차단되지 않고 세션 호스트에 직접 연결할 수 있습니다.
참고
다른 VPN 형식을 사용하여 Azure에 연결하는 경우 UDP 기반 VPN을 사용하는 것이 좋습니다. 대부분의 TCP 기반 VPN 솔루션은 중첩된 UDP를 지원하지만 TCP 정체 제어의 상속된 오버헤드를 추가하여 RDP 성능을 저하합니다.
관리되는 네트워크에 RDP Shortpath를 사용하려면 세션 호스트에서 UDP 수신기를 사용하도록 설정해야 합니다. 다른 포트를 사용할 수 있지만 기본적으로 포트 3390 이 사용됩니다.
다음 다이어그램에서는 Active Directory 도메인에 조인된 관리형 네트워크 및 세션 호스트에 RDP Shortpath를 사용할 때 네트워크 연결에 대한 개략적인 개요를 제공합니다.
연결 시퀀스
모든 연결은 Azure Virtual Desktop Gateway를 통해 TCP 기반 역방향 연결 전송 을 설정하는 것으로 시작합니다. 그런 다음 클라이언트 및 세션 호스트가 초기 RDP 전송을 설정하고 해당 기능 교환을 시작합니다. 이러한 기능은 다음 프로세스를 사용하여 협상됩니다.
세션 호스트는 IPv4 및 IPv6 주소 목록을 클라이언트에 보냅니다.
클라이언트는 백그라운드 스레드를 시작하여 세션 호스트의 IP 주소 중 하나에 직접 병렬 UDP 기반 전송을 설정합니다.
클라이언트는 제공된 IP 주소를 검색하는 동안 사용자 연결이 지연되지 않도록 역방향 연결 전송을 통해 초기 연결을 계속 설정합니다.
클라이언트가 세션 호스트에 직접 연결하는 경우 클라이언트는 신뢰할 수 있는 UDP를 통해 TLS를 사용하여 보안 연결을 설정합니다.
RDP Shortpath 전송을 설정한 후 원격 그래픽, 입력 및 디바이스 리디렉션을 포함한 모든 DVC(동적 가상 채널)가 새 전송으로 이동됩니다. 그러나 방화벽 또는 네트워크 토폴로지로 인해 클라이언트가 직접 UDP 연결을 설정할 수 없는 경우 RDP는 역방향 연결 전송을 계속합니다.
사용자에게 관리형 네트워크용 RDP Shortpath와 공용 네트워크를 모두 사용할 수 있는 경우 처음 찾은 알고리즘이 사용됩니다. 사용자는 해당 세션에 대해 먼저 설정되는 연결을 사용합니다.
공용 연결을 사용할 때 UDP 연결이 성공할 수 있는 최상의 기회를 제공하기 위해 직접 및 릴레이된 연결 유형이 있습니다.
직접 연결: STUN은 클라이언트와 세션 호스트 간에 직접 UDP 연결을 설정하는 데 사용됩니다. 이 연결을 설정하려면 클라이언트와 세션 호스트가 공용 IP 주소 및 협상 포트를 통해 서로 연결할 수 있어야 합니다. 그러나 대부분의 클라이언트는 NAT(네트워크 주소 변환) 게이트웨이 디바이스 뒤에 있기 때문에 자체 공용 IP 주소를 알지 못합니다. STUN은 NAT 게이트웨이 디바이스 뒤에서 공용 IP 주소를 자체 검색하고 클라이언트가 자체 공용 IP 주소를 확인하기 위한 프로토콜입니다.
클라이언트가 STUN을 사용하려면 네트워크에서 UDP 트래픽을 허용해야 합니다. 클라이언트와 세션 호스트가 모두 다른 사람의 검색된 IP 주소와 포트로 직접 라우팅할 수 있다고 가정하면 WebSocket 프로토콜을 통해 직접 UDP로 통신이 설정됩니다. 방화벽 또는 다른 네트워크 디바이스가 직접 연결을 차단하는 경우 릴레이된 UDP 연결이 시도됩니다.
릴레이된 연결: TURN은 직접 연결이 불가능한 경우 클라이언트와 세션 호스트 간의 중간 서버를 통해 트래픽을 릴레이하는 연결을 설정하는 데 사용됩니다. TURN은 STUN의 확장입니다. TURN을 사용하면 공용 IP 주소 및 포트를 미리 알 수 있으며 방화벽 및 기타 네트워크 디바이스를 통해 허용될 수 있습니다.
방화벽 또는 다른 네트워크 디바이스가 UDP 트래픽을 차단하는 경우 연결은 TCP 기반 역방향 연결 전송으로 대체됩니다.
연결이 설정되면 ICE(Interactive Connectivity Establishment)는 STUN 및 TURN의 관리를 조정하여 연결이 설정될 가능성을 최적화하고 기본 네트워크 통신 프로토콜에 우선 순위가 지정되도록 합니다.
각 RDP 세션은 RDP Shortpath 트래픽을 허용하는 임시 포트 범위(기본적으로 49152 ~ 65535 )에서 동적으로 할당된 UDP 포트를 사용합니다. 포트 65330은 Azure에서 내부적으로 사용하도록 예약되어 있으므로 이 범위에서 무시됩니다. 더 작고 예측 가능한 포트 범위를 사용할 수도 있습니다. 자세한 내용은 공용 네트워크에 대해 클라이언트에서 사용하는 포트 범위 제한을 참조하세요.
팁
공용 네트워크에 대한 RDP Shortpath는 추가 구성 없이 자동으로 작동하며, 네트워크 및 방화벽을 통해 트래픽을 허용하고 세션 호스트 및 클라이언트에 대한 Windows 운영 체제의 RDP 전송 설정이 기본값을 사용하고 있습니다.
다음 다이어그램에서는 세션 호스트가 Microsoft Entra ID에 조인된 공용 네트워크에 RDP Shortpath를 사용할 때 네트워크 연결에 대한 개략적인 개요를 제공합니다.
TURN 릴레이 가용성
TURN 릴레이는 ACS TURN Relay(51.5.0.0/16)를 사용하는 다음 Azure 지역에서 사용할 수 있습니다.
- 오스트레일리아 중부
- 오스트레일리아 동부
- 오스트레일리아 남동부
- 브라질 남부
- 캐나다 중부
- 캐나다 동부
- 인도 중부
- 미국 중부
- 미국 동부
- 미국 동부 2
- 프랑스 중부
- 독일 중서부
- 이스라엘 중부
- 일본 동부
- 일본 서부
- 조선중앙
- 대한민국
- 멕시코 중부
- 미국 중북부
- 북유럽
- 노르웨이 서부
- 남아프리카 공화국 북부
- 남아프리카 공화국 서부
- 미국 중남부
- 동남아시아
- 인도 남부
- 스페인 중부
- 스위스 북부
- 타웨인 노스
- 타웨인 북동부
- UAE 중부
- 아랍에미리트 북부
- 영국 남부
- 영국 서부
- 미국 중서부
- 서유럽
- 미국 서부
- 미국 서부 2
- 미국 서부 3
TURN 릴레이는 클라이언트 디바이스의 물리적 위치에 따라 선택됩니다. 예를 들어 클라이언트 디바이스가 영국에 있는 경우 영국 남부 또는 영국 서부 지역의 TURN 릴레이가 선택됩니다. 클라이언트 디바이스가 TURN 릴레이와 거리가 멀면 UDP 연결이 TCP로 대체될 수 있습니다.
네트워크 주소 변환 및 방화벽
대부분의 Azure Virtual Desktop 클라이언트는 프라이빗 네트워크의 컴퓨터에서 실행됩니다. 인터넷 액세스는 NAT(네트워크 주소 변환) 게이트웨이 디바이스를 통해 제공됩니다. 따라서 NAT 게이트웨이는 프라이빗 네트워크에서 인터넷으로 향하는 모든 네트워크 요청을 수정합니다. 이러한 수정은 개인 네트워크의 모든 컴퓨터에서 단일 공용 IP 주소를 공유하려고 합니다.
IP 패킷 수정으로 인해 트래픽 수신자는 실제 보낸 사람 대신 NAT 게이트웨이의 공용 IP 주소를 볼 수 있습니다. 트래픽이 NAT 게이트웨이로 돌아오면 보낸 사람의 지식 없이 의도한 수신자에게 전달합니다. 대부분의 시나리오에서 이러한 NAT 뒤에 숨겨진 디바이스는 변환이 발생하는 것을 인식하지 못하며 NAT 게이트웨이의 네트워크 주소를 모릅니다.
NAT는 모든 세션 호스트가 있는 Azure Virtual Network에 적용할 수 있습니다. 세션 호스트가 인터넷의 네트워크 주소에 도달하려고 하면 NAT 게이트웨이(Azure에서 제공하는 사용자 고유 또는 기본값) 또는 Azure Load Balancer 주소 변환을 수행합니다. 다양한 유형의 원본 네트워크 주소 변환에 대한 자세한 내용은 아웃바운드 연결에 SNAT(원본 네트워크 주소 변환) 사용을 참조하세요.
대부분의 네트워크에는 일반적으로 트래픽을 검사하고 규칙에 따라 차단하는 방화벽이 포함됩니다. 대부분의 고객은 들어오는 연결(즉, 요청 없이 전송된 인터넷에서 원치 않는 패킷)을 방지하도록 방화벽을 구성합니다. 방화벽은 요청된 트래픽과 원치 않는 트래픽을 구분하기 위해 다양한 기술을 사용하여 데이터 흐름을 추적합니다. TCP의 컨텍스트에서 방화벽은 SYN 및 ACK 패킷을 추적하며 프로세스는 간단합니다. UDP 방화벽은 일반적으로 패킷 주소를 기반으로 추론을 사용하여 트래픽을 UDP 흐름과 연결하고 허용하거나 차단합니다. 다양한 NAT 구현을 사용할 수 있습니다.
연결 시퀀스
모든 연결은 Azure Virtual Desktop Gateway를 통해 TCP 기반 역방향 연결 전송 을 설정하는 것으로 시작합니다. 그런 다음 클라이언트 및 세션 호스트가 초기 RDP 전송을 설정하고 해당 기능 교환을 시작합니다. 공용 네트워크에 대한 RDP Shortpath가 세션 호스트에서 사용하도록 설정된 경우 세션 호스트는 후보 수집이라는 프로세스를 시작합니다.
세션 호스트는 VPN 및 Teredo 같은 가상 인터페이스를 포함하여 세션 호스트에 할당된 모든 네트워크 인터페이스를 열거합니다.
Windows 서비스 TermService(원격 데스크톱 서비스 )는 각 인터페이스에 UDP 소켓을 할당하고 IP :포트 쌍을 후보 테이블에 로컬 후보로 저장합니다.
원격 데스크톱 서비스 서비스는 이전 단계에서 할당된 각 UDP 소켓을 사용하여 공용 인터넷에서 Azure Virtual Desktop STUN Server에 도달하려고 시도합니다. 통신은 포트 3478에 작은 UDP 패킷을 전송하여 수행됩니다.
패킷이 STUN 서버에 도달하면 STUN 서버는 공용 IP 및 포트로 응답합니다. 이 정보는 후보 테이블에 반사 후보로 저장됩니다.
세션 호스트가 모든 후보를 수집한 후 세션 호스트는 설정된 역방향 연결 전송을 사용하여 후보 목록을 클라이언트에 전달합니다.
클라이언트가 세션 호스트에서 후보 목록을 받으면 클라이언트는 해당 쪽에서 후보 모임을 수행합니다. 그런 다음 클라이언트는 해당 후보 목록을 세션 호스트로 보냅니다.
세션 호스트와 클라이언트가 후보 목록을 교환한 후 양 당사자는 수집된 모든 후보를 사용하여 서로 연결하려고 시도합니다. 이 연결 시도는 양쪽에서 동시에 수행됩니다. 많은 NAT 게이트웨이는 아웃바운드 데이터 전송이 초기화되는 즉시 소켓으로 들어오는 트래픽을 허용하도록 구성됩니다. NAT 게이트웨이의 이러한 동작은 동시 연결이 필수적인 이유입니다. STUN이 차단되어 실패하면 TURN을 사용하여 릴레이된 연결 시도가 이루어집니다.
초기 패킷 교환 후 클라이언트 및 세션 호스트는 하나 이상의 데이터 흐름을 설정할 수 있습니다. 이러한 데이터 흐름에서 RDP는 가장 빠른 네트워크 경로를 선택합니다. 그런 다음 클라이언트는 세션 호스트와 함께 신뢰할 수 있는 UDP를 통해 TLS를 사용하여 보안 연결을 설정하고 RDP Shortpath 전송을 시작합니다.
RDP가 RDP Shortpath 전송을 설정한 후 원격 그래픽, 입력 및 디바이스 리디렉션을 포함한 모든 DVC(동적 가상 채널)가 새 전송으로 이동합니다.
사용자가 관리형 네트워크용 RDP Shortpath와 공용 네트워크를 모두 사용할 수 있는 경우 처음 찾은 알고리즘이 사용됩니다. 즉, 사용자가 해당 세션에 대해 먼저 설정된 연결을 사용합니다. 자세한 내용은 예제 시나리오 4를 참조하세요.
네트워크 구성
공용 네트워크에 대한 RDP Shortpath를 지원하려면 일반적으로 특정 구성이 필요하지 않습니다. 세션 호스트와 클라이언트는 네트워크 구성에서 가능한 경우 직접 데이터 흐름을 자동으로 검색합니다. 그러나 모든 환경은 고유하며 일부 네트워크 구성은 직접 연결 성공률에 부정적인 영향을 줄 수 있습니다.
권장 사항에 따라 직접 데이터 흐름의 확률을 높입니다.
RDP Shortpath는 UDP를 사용하여 데이터 흐름을 설정하므로 네트워크의 방화벽이 UDP 트래픽을 차단하는 경우 RDP Shortpath가 실패하고 연결이 TCP 기반 역방향 연결 전송으로 대체됩니다. Azure Virtual Desktop은 Azure Communication Services 및 Microsoft Teams에서 제공하는 STUN 서버를 사용합니다. 이 기능의 특성에 따라 세션 호스트에서 클라이언트로의 아웃바운드 연결이 필요합니다. 아쉽게도 대부분의 경우 사용자가 어디에 있는지 예측할 수 없습니다. 따라서 세션 호스트에서 인터넷으로의 아웃바운드 UDP 연결을 허용하는 것이 좋습니다. 필요한 포트 수를 줄이려면 클라이언트가 UDP 흐름 에 사용하는 포트 범위를 제한 할 수 있습니다. RDP Shortpath에 대한 방화벽을 구성할 때 참조에 다음 표를 사용합니다.
환경에서 단일 개인 원본 IP:포트를 고유한 공용 대상IP:포트에 매핑하는 대칭 NAT를 사용하는 경우 TURN과 함께 릴레이된 연결을 사용할 수 있습니다. Azure Firewall 및 Azure NAT Gateway를 사용하는 경우입니다. Azure 가상 네트워크의 NAT에 대한 자세한 내용은 가상 네트워크를 사용한 원본 네트워크 주소 변환을 참조하세요.
공용 네트워크에 RDP Shortpath를 사용하는 성공적인 연결에 대한 몇 가지 일반적인 권장 사항이 있습니다. 자세한 내용은 일반 권장 사항을 참조하세요.
사용자가 관리되는 네트워크와 공용 네트워크 모두에 대한 RDP Shortpath를 사용할 수 있는 경우 찾은 첫 번째 알고리즘이 사용됩니다. 사용자는 해당 세션에 대해 먼저 설정되는 연결을 사용합니다. 자세한 내용은 예제 시나리오를 참조하세요.
다음 섹션에는 RDP Shortpath가 작동하도록 허용해야 하는 세션 호스트 및 클라이언트 디바이스에 대한 원본, 대상 및 프로토콜 요구 사항이 포함되어 있습니다.
참고
Microsoft는 이전에 공유한 20.202.0.0/16 서브넷에서 39개 Azure 지역의 새 51.5.0.0/16 TURN 릴레이 IP 범위로의 전환을 완료했습니다. 이 새로운 범위는 Azure Virtual Desktop 및 Windows 365 전용으로 Azure Communication Services 인프라에서 분리됩니다. 업그레이드는 턴/릴레이를 통해 공용 네트워크에 대한 RDP Shortpath를 향상시켜 더 빠르고 안정적인 연결과 향상된 사용자 환경을 제공하도록 설계되었습니다.
세션 호스트 가상 네트워크
다음 표에서는 세션 호스트 가상 네트워크에 대한 RDP Shortpath에 대한 원본, 대상 및 프로토콜 요구 사항을 자세히 설명합니다.
이름 |
원본 |
원본 포트 |
대상 |
대상 포트 |
Protocol(프로토콜) |
작업 |
STUN 직접 연결 |
VM 서브넷 |
모두 |
모두 |
1024-65535 (기본값 49152-65535) |
UDP |
허용 |
STUN/TURN Relay |
VM 서브넷 |
모두 |
51.5.0.0/16 |
3478 |
UDP |
허용 |
클라이언트 네트워크
다음 표에서는 클라이언트 디바이스에 대한 원본, 대상 및 프로토콜 요구 사항을 자세히 설명합니다.
이름 |
원본 |
원본 포트 |
대상 |
대상 포트 |
Protocol(프로토콜) |
작업 |
STUN 직접 연결 |
클라이언트 네트워크 |
모두 |
NAT 게이트웨이 또는 Azure Firewall 할당된 공용 IP 주소(STUN 엔드포인트에서 제공) |
1024-65535 (기본값 49152-65535) |
UDP |
허용 |
STUN/TURN 릴레이 |
클라이언트 네트워크 |
모두 |
51.5.0.0/16 |
3478 |
UDP |
허용 |
Teredo 지원
RDP Shortpath에는 필요하지 않지만 Teredo 추가 NAT 통과 후보를 추가하고 IPv4 전용 네트워크에서 성공적인 RDP Shortpath 연결 가능성을 높입니다. 세션 호스트 및 클라이언트에서 Teredo 사용하도록 설정하는 방법을 알아보려면 Teredo 지원 사용을 참조하세요.
UPnP 지원
직접 연결 가능성을 개선하기 위해 원격 데스크톱 클라이언트 쪽에서 RDP Shortpath는 UPnP 를 사용하여 NAT 라우터에서 포트 매핑을 구성할 수 있습니다. UPnP는 Xbox, 배달 최적화 및 Teredo 같은 다양한 애플리케이션에서 사용하는 표준 기술입니다. UPnP는 일반적으로 홈 네트워크에 있는 라우터에서 사용할 수 있습니다. UPnP는 대부분의 홈 라우터 및 액세스 지점에서 기본적으로 사용하도록 설정되지만 회사 네트워킹에서는 사용하지 않도록 설정되는 경우가 많습니다.
일반 권장 사항
공용 네트워크에 RDP Shortpath를 사용할 때 권장되는 몇 가지 일반적인 권장 사항은 다음과 같습니다.
사용자가 인터넷을 통해 Azure Virtual Desktop에 액세스하는 경우 강제 터널링 구성을 사용하지 마세요.
이중 NAT 또는 CGN(Carrier-Grade-NAT) 구성을 사용하지 않는지 확인합니다.
홈 라우터에서 UPnP를 사용하지 않도록 설정하지 않는 것이 좋습니다.
클라우드 패킷 검사 서비스를 사용하지 않습니다.
TCP 기반 VPN 솔루션을 사용하지 마세요.
IPv6 연결 또는 Teredo 사용하도록 설정합니다.
연결 보안
RDP Shortpath는 RDP 다중 전송 기능을 확장합니다. 역방향 연결 전송을 대체하지는 않지만 보완합니다. 초기 세션 조정은 Azure Virtual Desktop 서비스 및 역방향 연결 전송을 통해 관리됩니다. 역방향 연결 세션이 먼저 일치하지 않는 한 모든 연결 시도는 무시됩니다. RDP Shortpath는 인증 후에 설정되며, 성공적으로 설정되면 역방향 연결 전송이 삭제되고 모든 트래픽이 RDP Shortpath를 통해 흐릅니다.
RDP Shortpath는 세션 호스트의 인증서를 사용하여 클라이언트와 세션 호스트 간의 신뢰할 수 있는 UDP를 통해 TLS를 사용하여 보안 연결을 사용합니다. 기본적으로 RDP 암호화에 사용되는 인증서는 배포 중에 운영 체제에서 자체 생성됩니다. 엔터프라이즈 인증 기관에서 발급한 중앙에서 관리되는 인증서를 배포할 수도 있습니다. 인증서 구성에 대한 자세한 내용은 원격 데스크톱 수신기 인증서 구성을 참조하세요.
참고
RDP Shortpath에서 제공하는 보안은 TCP 역방향 연결 전송에서 제공하는 보안과 동일합니다.
예제 시나리오
다음은 여러 네트워크 토폴로지에서 RDP Shortpath가 사용되는지 여부를 결정하기 위해 연결을 평가하는 방법을 보여주는 몇 가지 예제 시나리오입니다.
시나리오 1
UDP 연결은 공용 네트워크(인터넷)를 통해 클라이언트 디바이스와 세션 호스트 간에만 설정할 수 있습니다. VPN과 같은 직접 연결을 사용할 수 없습니다. UDP는 방화벽 또는 NAT 디바이스를 통해 허용됩니다.
시나리오 2
방화벽 또는 NAT 디바이스가 직접 UDP 연결을 차단하지만 공용 네트워크(인터넷)를 통해 클라이언트 디바이스와 세션 호스트 간의 TURN을 사용하여 릴레이된 UDP 연결을 릴레이할 수 있습니다. VPN과 같은 다른 직접 연결을 사용할 수 없습니다.
시나리오 3
공용 네트워크 또는 직접 VPN 연결을 통해 클라이언트 디바이스와 세션 호스트 간에 UDP 연결을 설정할 수 있지만 관리되는 네트워크에 대한 RDP Shortpath는 사용하도록 설정되지 않습니다. 클라이언트가 연결을 시작하면 ICE/STUN 프로토콜은 여러 경로를 볼 수 있으며 각 경로를 평가하고 대기 시간이 가장 짧은 경로를 선택합니다.
이 예제에서는 녹색 선에 표시된 것처럼 직접 VPN 연결을 통해 공용 네트워크에 RDP Shortpath를 사용하는 UDP 연결이 대기 시간이 가장 낮기 때문에 만들어집니다.
시나리오 4
공용 네트워크 및 관리형 네트워크에 대한 RDP Shortpath가 모두 사용하도록 설정됩니다. 공용 네트워크 또는 직접 VPN 연결을 통해 클라이언트 디바이스와 세션 호스트 간에 UDP 연결을 설정할 수 있습니다. 클라이언트가 연결을 시작하면 ICE/STUN 프로토콜을 통해 포트 3390(기본적으로) 및 공용 네트워크의 RDP Shortpath를 통해 관리되는 네트워크에 RDP Shortpath를 사용하여 연결하려고 동시에 시도합니다. 처음 찾은 알고리즘이 사용되며 사용자는 해당 세션에 대해 먼저 설정된 연결을 사용합니다.
공용 네트워크를 통해 진행하는 데는 NAT 디바이스, 부하 분산 장치 또는 STUN 서버와 같은 더 많은 단계가 있으므로 처음 찾은 알고리즘은 관리되는 네트워크에 RDP Shortpath를 사용하여 연결을 선택하고 먼저 설정할 가능성이 높습니다.
시나리오 5
공용 네트워크 또는 직접 VPN 연결을 통해 클라이언트 디바이스와 세션 호스트 간에 UDP 연결을 설정할 수 있지만 관리되는 네트워크에 대한 RDP Shortpath는 사용하도록 설정되지 않습니다. ICE/STUN이 특정 경로를 사용하지 못하도록 하려면 관리자가 UDP 트래픽에 대한 경로 중 하나를 차단할 수 있습니다. 경로를 차단하면 나머지 경로가 항상 사용됩니다.
이 예제에서 UDP는 직접 VPN 연결에서 차단되고 ICE/STUN 프로토콜은 공용 네트워크를 통해 연결을 설정합니다.
시나리오 6
공용 네트워크와 관리되는 네트워크에 대한 RDP Shortpath가 모두 구성되지만 직접 VPN 연결을 사용하여 UDP 연결을 설정할 수 없습니다. 방화벽 또는 NAT 디바이스도 공용 네트워크(인터넷)를 사용하여 직접 UDP 연결을 차단하지만, 공용 네트워크(인터넷)를 통해 클라이언트 디바이스와 세션 호스트 간의 TURN을 사용하여 릴레이된 UDP 연결을 릴레이할 수 있습니다.
시나리오 7
공용 네트워크와 관리되는 네트워크에 대한 RDP Shortpath가 모두 구성되지만 UDP 연결을 설정할 수 없습니다. 이 instance RDP Shortpath가 실패하고 연결이 TCP 기반 역방향 연결 전송으로 대체됩니다.
다음 단계