Partilhar via


Compreender a conectividade de rede do Azure Virtual Desktop

O Azure Virtual Desktop aloja sessões de cliente em anfitriões de sessão em execução no Azure. A Microsoft gere partes dos serviços em nome do cliente e fornece pontos finais seguros para ligar clientes e anfitriões de sessão. O diagrama seguinte apresenta uma descrição geral de alto nível das ligações de rede utilizadas pelo Azure Virtual Desktop.

Diagrama da Rede do Azure Virtual Desktop Connections

Conectividade da sessão

A Área de Trabalho Virtual do Azure usa o protocolo RDP para fornecer recursos de exibição e de entrada remotos em conexões de rede. O RDP evoluiu continuamente com cada versão do Microsoft Windows e Windows Server. Desde o início, o RDP desenvolveu-se para ser independente da pilha de transporte subjacente e hoje suporta vários tipos de transporte.

Transporte de ligação inversa

O Azure Virtual Desktop está a utilizar o transporte de ligação inversa para estabelecer a sessão remota e para transportar tráfego RDP. Ao contrário das implementações dos Serviços de Ambiente de Trabalho Remoto no local, o transporte de ligação inversa não utiliza um serviço de escuta TCP para receber ligações RDP recebidas. Em vez disso, está a utilizar a conectividade de saída à infraestrutura do Azure Virtual Desktop através da ligação HTTPS.

Canal de comunicação do anfitrião de sessões

Após o arranque do anfitrião de sessão do Azure Virtual Desktop, o serviço Loader do Agente de Ambiente de Trabalho Remoto estabelece o canal de comunicação persistente do mediador do Azure Virtual Desktop. Este canal de comunicação está sobreposto a uma ligação TLS (Transport Layer Security) segura e funciona como um barramento para a troca de mensagens de serviço entre o anfitrião de sessões e a infraestrutura do Azure Virtual Desktop.

Sequência de ligação de cliente

A sequência de ligação do cliente é a seguinte:

  1. Utilizar o utilizador cliente do Azure Virtual Desktop suportado subscreve a Área de Trabalho do Azure Virtual Desktop.

  2. Microsoft Entra autentica o utilizador e devolve o token utilizado para enumerar os recursos disponíveis para um utilizador.

  3. O cliente passa o token para o serviço de subscrição do feed do Azure Virtual Desktop.

  4. O serviço de subscrição do feed do Azure Virtual Desktop valida o token.

  5. O serviço de subscrição do feed do Azure Virtual Desktop transmite a lista de ambientes de trabalho e aplicações disponíveis para o cliente sob a forma de configuração de ligação assinada digitalmente.

  6. O cliente armazena a configuração de ligação para cada recurso disponível num conjunto de .rdp ficheiros.

  7. Quando um utilizador seleciona o recurso a ligar, o cliente utiliza o ficheiro associado .rdp e estabelece uma ligação TLS segura a uma instância de gateway do Azure Virtual Desktop com a ajuda do Azure Front Door e transmite as informações de ligação. A latência de todos os gateways é avaliada e os gateways são colocados em grupos de 10 ms. É escolhido o gateway com a latência mais baixa e o menor número de ligações existentes.

  8. O gateway do Azure Virtual Desktop valida o pedido e pede ao mediador do Azure Virtual Desktop para orquestrar a ligação.

  9. O mediador do Azure Virtual Desktop identifica o anfitrião da sessão e utiliza o canal de comunicação persistente estabelecido anteriormente para inicializar a ligação.

  10. A pilha de Ambiente de Trabalho Remoto inicia uma ligação TLS à mesma instância do gateway do Azure Virtual Desktop, conforme utilizado pelo cliente.

  11. Depois de o cliente e o anfitrião de sessão se ligarem ao gateway, o gateway começa a reencaminhar os dados entre ambos os pontos finais. Esta ligação estabelece o transporte de ligação inversa base para a ligação RDP através de um túnel aninhado, utilizando a versão do TLS mutuamente acordada suportada e ativada entre o cliente e o anfitrião de sessão, até TLS 1.3.

  12. Depois de definir o transporte base, o cliente inicia o handshake RDP.

Segurança da ligação

O TLS é utilizado para todas as ligações. A versão utilizada depende da ligação e das capacidades do cliente e do anfitrião da sessão:

  • Para todas as ligações iniciadas a partir dos clientes e anfitriões de sessão para os componentes de infraestrutura do Azure Virtual Desktop, o TLS 1.2 é o mínimo e o TLS 1.3 pode ser utilizado se o sistema operativo cliente o suportar. O Azure Virtual Desktop utiliza as mesmas cifras TLS 1.2 ou 1.3 que o Azure Front Door. É importante garantir que os computadores cliente e os anfitriões de sessão podem utilizar estas cifras.

  • Para o transporte de ligação inversa, o cliente e o anfitrião de sessão ligam-se ao gateway do Azure Virtual Desktop. Após a ligação TCP para o transporte base ser estabelecida, o cliente ou anfitrião de sessão valida o certificado do gateway do Azure Virtual Desktop. Em seguida, o RDP estabelece uma ligação TLS aninhada entre o cliente e o anfitrião da sessão com os certificados do anfitrião da sessão. A versão do TLS utiliza a versão do TLS mutuamente acordada suportada e ativada entre o cliente e o anfitrião da sessão, até ao TLS 1.3. O TLS 1.3 é suportado a partir de Windows 11 (21H2) e em Windows Server 2022. Para saber mais, veja Windows 11 suporte do TLS. Para outros sistemas operativos, marcar com o fornecedor do sistema operativo para suporte TLS 1.3.

Por predefinição, o certificado utilizado para encriptação RDP é gerado automaticamente pelo SO durante a implementação. Neste momento, o Azure Virtual Desktop não suporta a utilização de um certificado emitido por uma autoridade de certificação.

Próximas etapas