Cliente RDP baseado na web feito com Go WebAssembly e grdp
(github.com/nakagami)- É um cliente RDP baseado na web que permite acessar a Área de Trabalho Remota do Windows apenas pelo navegador e funciona sem plugin
- Separa o Go WebAssembly no navegador e um proxy WebSocket-para-TCP no lado do servidor, que assume a conexão TCP do RDP que o navegador não consegue abrir diretamente
- A conexão segue o fluxo
Browser -> WebSocket -> proxy -> TCP -> RDP Server; após conectar, a tela remota é exibida em um canvas e repassa entradas de teclado e mouse - Os dispositivos de entrada incluem teclado baseado 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 com HTTPS/WSS e uma camada de autenticação antes de ser exposto externamente
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 plugin
- A implementação combina Go WebAssembly com grdp e adota uma arquitetura 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, é necessário também um proxy leve em Go que conecte a sessão WebSocket à porta TCP do servidor RDP
Arquitetura e modo de funcionamento
- O caminho completo segue a sequência
Browser (WASM) -> WebSocket -> proxy (Go) -> TCP -> RDP Server - No navegador, é executado um binário WASM, enquanto o proxy atua tanto como ponte WebSocket-para-TCP quanto como servidor de arquivos estáticos
- Os artefatos gerados por
make allsão divididos 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 trata a conexão com tecnologias web padrão, enquanto o proxy assume a comunicação TCP real com o servidor RDP
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 no canvas; para receber entrada do teclado, é preciso clicar no canvas
- Ao clicar em Disconnect, a sessão é encerrada
Dispositivos de entrada e suporte a áudio
- Toda a entrada padrão do teclado é encaminhada 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 transmitidos; se a digitação parar de funcionar, é necessário 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 cuidados 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 qualquer host compatível com RDP
- O proxy permite conexões de todas as origins, portanto deve ser executado apenas em uma rede confiável ou com uma camada de autenticação adicionada antes de ser exposto à internet
- Como as credenciais são enviadas do navegador ao proxy via WebSocket, em redes não confiáveis é necessário usar HTTPS/WSS
- O README também menciona a possibilidade de usar 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 permitem definir o endereço e a porta de escuta com
-listene o diretório de arquivos estáticos com-static - Os alvos para desenvolvimento se dividem 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/