RDP Shortpath para Azure Virtual Desktop

Pode obter a conectividade de linha de visão direta necessária para utilizar o RDP Shortpath com redes geridas através dos seguintes métodos.

• Peering privado do ExpressRoute

• VPN Site a Site ou Ponto a Site (IPsec), como Azure Gateway de VPN

Ter conectividade de linha de visão direta significa que o cliente pode ligar-se diretamente ao anfitrião da sessão sem ser bloqueado por firewalls.

Para utilizar o RDP Shortpath para redes geridas, tem de ativar um serviço de escuta UDP nos anfitriões de sessão. Por predefinição, é utilizada a porta 3390 , embora possa utilizar uma porta diferente.

O diagrama seguinte fornece uma descrição geral de alto nível das ligações de rede ao utilizar o RDP Shortpath para redes geridas e anfitriões de sessão associados a um domínio do Active Directory.

Sequência de ligação

Todas as ligações começam por estabelecer um transporte de ligação inversa baseado em TCP através do Azure Gateway de Ambiente de Trabalho Virtual. Em seguida, o cliente e o anfitrião de sessão estabelecem o transporte RDP inicial e começam a trocar as suas capacidades. Estas capacidades são negociadas com o seguinte processo:

1. O anfitrião da sessão envia a lista dos respetivos endereços IPv4 e IPv6 para o cliente.

2. O cliente inicia o thread em segundo plano para estabelecer um transporte paralelo baseado em UDP diretamente para um dos endereços IP do anfitrião da sessão.

3. Enquanto o cliente está a sondar os endereços IP fornecidos, continua a estabelecer a ligação inicial através do transporte de ligação inversa para garantir que não há nenhum atraso na ligação do utilizador.

4. Se o cliente tiver uma ligação direta ao anfitrião da sessão, o cliente estabelece uma ligação segura com o TLS através de um UDP fiável.

5. Depois de estabelecer o transporte RDP Shortpath, todos os Canais Virtuais Dinâmicos (DVCs), incluindo gráficos remotos, entradas e redirecionamento de dispositivos, são movidos para o novo transporte. No entanto, se uma firewall ou topologia de rede impedir o cliente de estabelecer conectividade UDP direta, o RDP continuará com um transporte de ligação inversa.

Se os seus utilizadores tiverem o RDP Shortpath para redes públicas e de rede geridas disponíveis, será utilizado o algoritmo encontrado pela primeira vez. O utilizador utilizará a ligação estabelecida primeiro para essa sessão.

Para proporcionar a melhor hipótese de uma ligação UDP ser bem-sucedida ao utilizar uma ligação pública, existem os tipos de ligação direta e reencaminhada :

• Ligação direta: o STUN é utilizado para estabelecer uma ligação UDP direta entre um cliente e um anfitrião de sessão. Para estabelecer esta ligação, o cliente e o anfitrião de sessão têm de conseguir ligar-se uns aos outros através de um endereço IP público e de uma porta negociada. No entanto, a maioria dos clientes não sabe o seu próprio endereço IP público, uma vez que se encontra atrás de um dispositivo de gateway de Tradução de Endereços de Rede (NAT). O STUN é um protocolo para a auto-deteção de um endereço IP público por trás de um dispositivo nat gateway e o cliente para determinar o seu próprio endereço IP destinado ao público.

  Para um cliente utilizar STUN, a rede tem de permitir tráfego UDP. Partindo do princípio de que o cliente e o anfitrião de sessão podem encaminhar diretamente para o endereço IP e a porta detetados do outro, a comunicação é estabelecida com o UDP direto através do protocolo WebSocket. Se as firewalls ou outros dispositivos de rede bloquearem ligações diretas, é tentada uma ligação UDP reencaminhada.

• Ligação reencaminhada: TURN é utilizado para estabelecer uma ligação, reencaminhando o tráfego através de um servidor intermédio entre um cliente e um anfitrião de sessão quando não é possível uma ligação direta. TURN é uma extensão de STUN. Utilizar TURN significa que o endereço IP público e a porta são conhecidos antecipadamente, o que pode ser permitido através de firewalls e outros dispositivos de rede.

  Se as firewalls ou outros dispositivos de rede bloquearem o tráfego UDP, a ligação reverterá para um transporte de ligação inversa baseado em TCP.

Quando uma ligação está a ser estabelecida, o Interactive Connectivity Establishment (ICE) coordena a gestão de STUN e TURN para otimizar a probabilidade de uma ligação ser estabelecida e garantir que é dada precedência aos protocolos de comunicação de rede preferenciais.

Cada sessão RDP utiliza uma porta UDP atribuída dinamicamente de um intervalo de portas efémero (49152 a 65535 por predefinição ) que aceita o tráfego RDP Shortpath. A porta 65330 é ignorada deste intervalo, uma vez que está reservada para utilização interna por Azure. Também pode utilizar um intervalo de portas mais pequeno e previsível. Para obter mais informações, veja Limitar o intervalo de portas utilizado pelos clientes para redes públicas.

O diagrama seguinte fornece uma descrição geral de alto nível das ligações de rede ao utilizar o RDP Shortpath para redes públicas em que os anfitriões de sessão se juntaram ao Microsoft Entra ID.

Disponibilidade do reencaminhamento TURN

O reencaminhamento TURN está disponível nas seguintes regiões Azure com Reencaminhamento TURN ACS (51.5.0.0/16):

É selecionado um reencaminhamento TURN com base na localização física do dispositivo cliente. Por exemplo, se um dispositivo cliente estiver no Reino Unido, o reencaminhamento TURN na região Sul ou Oeste do Reino Unido está selecionado. Se um dispositivo cliente estiver longe de ser um reencaminhamento TURN, a ligação UDP poderá reverter para TCP.

Tradução de Endereços de Rede e firewalls

A maioria Azure clientes do Virtual Desktop são executados em computadores na rede privada. O acesso à Internet é fornecido através de um dispositivo de gateway de Tradução de Endereços de Rede (NAT). Por conseguinte, o NAT Gateway modifica todos os pedidos de rede da rede privada e destinados à Internet. Esta modificação pretende partilhar um único endereço IP público em todos os computadores na rede privada.

Devido à modificação do pacote IP, o destinatário do tráfego verá o endereço IP público do NAT Gateway em vez do remetente real. Quando o tráfego voltar ao NAT Gateway, terá o cuidado de reencaminhá-lo para o destinatário pretendido sem o conhecimento do remetente. Na maioria dos cenários, os dispositivos ocultos por trás de tal NAT não têm conhecimento de que a tradução está a ocorrer e não sabem o endereço de rede do NAT Gateway.

O NAT é aplicável às Redes Virtuais Azure onde residem todos os anfitriões de sessão. Quando um anfitrião de sessão tenta aceder ao endereço de rede na Internet, o NAT Gateway (o seu próprio ou predefinido fornecido por Azure) ou Azure Load Balancer efetua a tradução de endereços. Para obter mais informações sobre vários tipos de Tradução de Endereços de Rede de Origem, veja Utilizar a Tradução de Endereços de Rede de Origem (SNAT) para ligações de saída.

Normalmente, a maioria das redes inclui firewalls que inspecionam o tráfego e o bloqueiam com base em regras. A maioria dos clientes configura as firewalls para impedir ligações recebidas (ou seja, pacotes não solicitados da Internet enviados sem um pedido). As firewalls utilizam diferentes técnicas para controlar o fluxo de dados para distinguir entre tráfego solicitado e não solicitado. No contexto do TCP, a firewall controla os pacotes SYN e ACK e o processo é simples. Normalmente, as firewalls UDP utilizam heurística com base em endereços de pacotes para associar o tráfego a fluxos UDP e permitir ou bloquear. Existem várias implementações NAT diferentes disponíveis.

Sequência de ligação

Todas as ligações começam por estabelecer um transporte de ligação inversa baseado em TCP através do Azure Gateway de Ambiente de Trabalho Virtual. Em seguida, o cliente e o anfitrião de sessão estabelecem o transporte RDP inicial e começam a trocar as suas capacidades. Se o RDP Shortpath para redes públicas estiver ativado no anfitrião da sessão, o anfitrião da sessão inicia um processo chamado recolha de candidatos:

1. O anfitrião da sessão enumera todas as interfaces de rede atribuídas a um anfitrião de sessão, incluindo interfaces virtuais como VPN e Teredo.

2. Os Serviços de Ambiente de Trabalho Remoto (TermService) do serviço Windows aloca sockets UDP em cada interface e armazena o par IP:Port na tabela candidata como candidato local.

3. O serviço de Serviços de Ambiente de Trabalho Remoto utiliza cada socket UDP alocado no passo anterior para tentar aceder ao Azure Servidor STUN do Ambiente de Trabalho Virtual na Internet pública. A comunicação é feita através do envio de um pequeno pacote UDP para a porta 3478.

4. Se o pacote chegar ao servidor STUN, o servidor STUN responde com o IP público e a porta. Estas informações são armazenadas na tabela candidata como um candidato reflexivo.

5. Depois de o anfitrião da sessão reunir todos os candidatos, o anfitrião da sessão utiliza o transporte de ligação inversa estabelecido para passar a lista de candidatos ao cliente.

6. Quando o cliente recebe a lista de candidatos do anfitrião da sessão, o cliente também realiza a reunião de candidatos do seu lado. Em seguida, o cliente envia a respetiva lista de candidatos para o anfitrião da sessão.

7. Após o anfitrião da sessão e o cliente trocarem as listas de candidatos, ambas as partes tentam ligar-se entre si através de todos os candidatos reunidos. Esta tentativa de ligação é simultânea em ambos os lados. Muitos nat gateways estão configurados para permitir o tráfego de entrada para o socket assim que a transferência de dados de saída o inicializar. Este comportamento dos nat gateways é a razão pela qual a ligação simultânea é essencial. Se o STUN falhar porque está bloqueado, é efetuada uma tentativa de ligação retransmitida com TURN.

8. Após a troca inicial de pacotes, o cliente e o anfitrião de sessão podem estabelecer um ou muitos fluxos de dados. Nestes fluxos de dados, o RDP escolhe o caminho de rede mais rápido. Em seguida, o cliente estabelece uma ligação segura com o TLS através de um UDP fiável com o anfitrião de sessão e inicia o transporte rdP Shortpath.

9. Depois de o RDP estabelecer o transporte RDP Shortpath, todos os Canais Virtuais Dinâmicos (DVCs), incluindo gráficos remotos, entradas e redirecionamento de dispositivos, são movidos para o novo transporte.

Se os seus utilizadores tiverem o RDP Shortpath para a rede gerida e as redes públicas disponíveis, será utilizado o algoritmo encontrado pela primeira vez, o que significa que o utilizador utilizará a ligação estabelecida primeiro para essa sessão. Para obter mais informações, veja o cenário de exemplo 4.

Configuração da rede

Para suportar o RDP Shortpath para redes públicas, normalmente não precisa de nenhuma configuração específica. O anfitrião e o cliente da sessão detetarão automaticamente o fluxo de dados direto se for possível na configuração de rede. No entanto, cada ambiente é exclusivo e algumas configurações de rede podem afetar negativamente a taxa de êxito da ligação direta. Siga as recomendações para aumentar a probabilidade de um fluxo de dados direto.

Como o RDP Shortpath utiliza o UDP para estabelecer um fluxo de dados, se uma firewall na rede bloquear o tráfego UDP, o RDP Shortpath falhará e a ligação reverterá para o transporte de ligação inversa baseado em TCP. Azure Virtual Desktop utiliza servidores STUN fornecidos pelo Serviços de Comunicação do Azure e o Microsoft Teams. Pela natureza da funcionalidade, é necessária a conectividade de saída dos anfitriões de sessão para o cliente. Infelizmente, não pode prever onde os seus utilizadores estão localizados na maioria dos casos. Por conseguinte, recomendamos que permita a conectividade UDP de saída dos anfitriões de sessão para a Internet. Para reduzir o número de portas necessárias, pode limitar o intervalo de portas utilizado pelos clientes para o fluxo UDP. Utilize as tabelas seguintes para referência ao configurar firewalls para RDP Shortpath.

Se o seu ambiente utilizar NAT simétrico, que é o mapeamento de um único IP de origem privada :Porta para um IP de destino público exclusivo :Porta, pode utilizar uma ligação reencaminhada com TURN. Este será o caso se utilizar Firewall do Azure e Azure NAT Gateway. Para obter mais informações sobre o NAT com Azure redes virtuais, veja Tradução de Endereços de Rede de Origem com redes virtuais.

Temos algumas recomendações gerais para ligações bem-sucedidas através do RDP Shortpath para redes públicas. Para obter mais informações, veja Recomendações gerais.

Quando os utilizadores tiverem o RDP Shortpath para redes públicas e de rede geridas, será utilizado o primeiro algoritmo encontrado. O utilizador utilizará a ligação estabelecida primeiro para essa sessão. Para obter mais informações, veja Cenários de exemplo.

As secções seguintes contêm os requisitos de origem, destino e protocolo para os anfitriões de sessão e dispositivos cliente que têm de ser permitidos para que o RDP Shortpath funcione.

Rede virtual do anfitrião da sessão

A tabela seguinte detalha os requisitos de origem, destino e protocolo do RDP Shortpath para a rede virtual do anfitrião de sessões.

Rede de cliente

A tabela seguinte detalha os requisitos de origem, destino e protocolo para os seus dispositivos cliente.

Suporte do Teredo

Embora não seja necessário para o RDP Shortpath, o Teredo adiciona candidatos extra do NAT Traversal e aumenta a probabilidade de uma ligação RDP Shortpath bem-sucedida em redes apenas IPv4. Para saber como ativar o Teredo em anfitriões e clientes de sessão, veja Ativar o suporte do Teredo.

Suporte de UPnP

Para melhorar as hipóteses de uma ligação direta, no lado do cliente de Ambiente de Trabalho Remoto, o RDP Shortpath pode utilizar o UPnP para configurar um mapeamento de portas no router NAT. O UPnP é uma tecnologia padrão utilizada por várias aplicações, como a Xbox, a Otimização da Entrega e o Teredo. O UPnP está geralmente disponível em routers normalmente encontrados numa rede doméstica. O UPnP está ativado por predefinição na maioria dos routers domésticos e pontos de acesso, mas é frequentemente desativado em redes empresariais.

Recomendações gerais

Seguem-se algumas recomendações gerais ao utilizar o RDP Shortpath para redes públicas:

• Evite utilizar configurações de túnel forçado se os utilizadores acederem Azure Virtual Desktop através da Internet.

• Certifique-se de que não está a utilizar configurações NAT dupla ou Carrier-Grade-NAT (CGN).

• Recomende aos seus utilizadores que não desativem o UPnP nos respetivos routers domésticos.

• Evite utilizar os Serviços de inspeção de pacotes na cloud.

• Evite utilizar soluções de VPN baseadas em TCP.

• Ative a conectividade IPv6 ou Teredo.