grdpwasm - Cliente RDP baseado na web
(github.com/nakagami)- É um cliente RDP baseado na web que permite acessar a Área de Trabalho Remota do Windows apenas pelo navegador, funcionando sem plugins
- Separa o Go WebAssembly no navegador e um proxy WebSocket-para-TCP no lado do servidor, que lida no lugar do navegador com a conexão RDP via TCP que ele não pode abrir diretamente
- A conexão segue o fluxo
Browser -> WebSocket -> proxy -> TCP -> RDP Server; após a conexão, a tela remota é exibida em um canvas e as entradas de teclado e mouse são encaminhadas - Os dispositivos de entrada incluem suporte a teclado com base em RDP scan codes e mouse com movimento, clique e roda de rolagem; o áudio remoto é recebido via RDPSND e reproduzido com a Web Audio API
- Como a estrutura do proxy permite todas as origins, ele deve ser executado apenas em uma rede confiável ou, antes de ser exposto externamente, deve ser usado com HTTPS/WSS e uma camada de autenticação
Visão geral do projeto
- Funciona como um cliente RDP baseado na web para acessar a Área de Trabalho Remota do Windows no navegador sem plugins
- A implementação combina Go WebAssembly com grdp e adota uma estrutura separada entre a parte executada no navegador e a parte de intermediação do proxy
- Como o navegador não pode abrir sockets TCP brutos diretamente, também é necessário um proxy leve em Go que conecte a ligação WebSocket à porta TCP do servidor RDP
Arquitetura e modo de funcionamento
- O caminho completo segue a ordem
Browser (WASM) -> WebSocket -> proxy (Go) -> TCP -> RDP Server - No navegador, é executado o binário WASM, enquanto o proxy atua ao mesmo tempo como ponte WebSocket-para-TCP e servidor de arquivos estáticos
- O resultado de
make allé dividido emstatic/main.wasm, executado no navegador,static/wasm_exec.js, arquivo de suporte ao runtime do Go, eproxy/proxy, o servidor proxy - Graças a essa estrutura, o lado do navegador lida com a conexão usando tecnologias web padrão, enquanto a comunicação TCP real com o servidor RDP fica a cargo do proxy
Fluxo de uso e interface do usuário
- No navegador, abra
http://localhost:8080, preencha no formulário de conexão os valores de Host, Port, Domain, User, Password, Width, Height e clique em Connect para iniciar a sessão - O valor padrão de Port é
3389, e Domain pode ficar em branco ao usar uma conta local - Quando a conexão é concluída, a área de trabalho remota é exibida em um canvas e, para receber entrada de teclado, é necessário clicar no canvas
- Ao clicar em Disconnect, a sessão é encerrada
Dispositivos de entrada e suporte a áudio
- Toda a entrada de teclado padrão é enviada para a área de trabalho remota por meio de RDP scan codes
- O mouse oferece suporte a movimento, clique de botões e roda de rolagem
- A aba do navegador precisa estar em foco para que os eventos de teclado sejam enviados; se a digitação parar de funcionar, é preciso clicar novamente na área do canvas
- O áudio remoto é transmitido por RDPSND e reproduzido no navegador com a Web Audio API
- O formato de áudio é especificado como PCM 44100 Hz, stereo, 16-bit signed little-endian
Condições de operação e pontos de atenção de segurança
- Os requisitos são Go 1.24 ou superior e um servidor RDP acessível; o servidor de destino pode ser Windows ou um host compatível com RDP
- O proxy permite conexões de qualquer origin, portanto deve ser executado apenas em uma rede confiável ou deve receber uma camada de autenticação antes de ser exposto à internet
- Como as credenciais são enviadas do navegador para o proxy via WebSocket, é necessário usar HTTPS/WSS em redes não confiáveis
- O README também menciona o uso de um reverse proxy com terminação TLS, como nginx ou Caddy
Formas de execução e informações adicionais
- A execução pode ser feita com
make serveou./proxy/proxy -listen :8080 -static static - As opções do proxy definem o endereço e a porta de escuta com
-listene o diretório de arquivos estáticos com-static - Os alvos para desenvolvimento são divididos em
make wasm, para recompilar apenas o WASM,make proxy, para recompilar apenas o proxy,make wasm_exec, para atualizarwasm_exec.js, emake clean, para remover os artefatos gerados - A licença é GPLv3, com referência adicional ao grdp LICENSE
2 comentários
Mas eu realmente não vejo qual é a grande vantagem aqui.
No fim, é só um cliente, então o lado do servidor também não consegue impor nenhum requisito.
E também não é algo que dê para acessar só com um navegador puro.
Comentários do Hacker News
Parece bem legal. Se ainda tiver suporte a gravação de sessão e autenticação SSO, já daria para usar direto como jump host de RDP
Já usei algo parecido com o Azure Bastion: você faz login no portal do Azure com o método de autenticação configurado no tenant, depois acessa a VM via RDP no navegador e faz login na VM com uma conta local. O tratamento de arquivos e da área de transferência funciona muito bem, e ele também suporta sessão de console dentro do navegador
Não sei dizer se funciona no lado Windows/RDP porque não usei, mas o SSH no navegador do GCP foi, de longe, um dos mais bem feitos que já vi
No Linux também já achei que o xrdp às vezes é melhor do que outras alternativas
Um dos grandes valores que isso resolve é a separação da interface de administração da VM/servidor. Só de garantir que o serviço de administração do servidor web não fique no mesmo IP/domínio/interface do serviço HTTP, a segurança já melhora bastante
No RDP no navegador, a área de transferência é um pesadelo sorrateiro. A negociação do protocolo em si funciona bem, mas a Clipboard API do navegador fica presa a permissões e exigências de gesto do usuário
No lado da leitura, a maioria dos navegadores praticamente pede confirmação do usuário quase toda vez. Então ou você cria um buffer de área de transferência separado dentro da página, ou colar para dentro do RDP funciona de forma fluida, mas copiar para fora do RDP exige um clique toda vez
Nenhuma das duas opções chega perto do comportamento que as pessoas esperam de um cliente web de RDP. Antes de dizer que está no nível do mstsc nativo, vale muito testar como isso se comporta de forma diferente no Chrome e no Firefox
Com a HP descontinuando Anyware / Teradici / PCoIP, bastante gente passou a procurar alternativas. Há uma necessidade especial por opções com multimonitor em alta resolução, 60fps, reprodução em alta profundidade de bits, suporte a tablet Wacom e suporte aos 3 sistemas operacionais
No lado pago, existem Parsec e DCV, e é ótimo ver tentativas open source. Há projetos como rustdesk, kyber e teraguchi, então a comunidade realmente parece precisar de uma opção open source de alto desempenho
https://github.com/rustdesk/rustdesk
https://github.com/thedepartmentofexternalservices/teraguchi
https://kyber.tech/
Parece interessante, mas me surpreende que a função mais importante não tenha sido mencionada. Fico curioso sobre quão bem a área de transferência compartilhada funciona na prática
Compartilhamento de área de transferência e upload/download por meio de unidades compartilhadas são recursos do FreeRDP, então dá para aproveitar de forma relativamente direta
E a gravação de sessão é inegociável em um ambiente PAM
[1] https://adaptive.live
Escalonamento de desktop, suporte a multimonitor, transferência de arquivos, redirecionamento de unidades e redirecionamento de periféricos também são todos importantes
Fico me perguntando se isso também funciona ao abrir um arquivo RDP recebido do CyberArk PAM
Também queria saber se o cliente RDP consegue capturar Alt-Tab dentro de uma aba do navegador
Antigamente esse era o maior problema do RDP no navegador do Guacamole
Tecnicamente é interessante, mas como praticamente toda plataforma já tem um cliente RDP nativo, não entendo muito bem por que isso seria necessário
https://guacamole.apache.org/