Servidor de desktop remoto Linux: configuração X11VNC e daemon RustDesk

Você precisa permitir que outras pessoas (ou você mesmo) se conectem a um desktop Linux de forma confiável, segura e sem depender de serviços proprietários caros — e os manuais que encontrou são ou vagos demais ou escritos para usuários de GUI. Este guia mostra duas abordagens práticas no lado do servidor para um servidor de desktop remoto Linux: uma configuração comprovada com X11VNC para expor diretamente uma sessão X, e um daemon RustDesk auto-hospedado (hbbs/hbbr) para NAT traversal moderno e relay — com comandos reais, unidades systemd, exemplos em Docker e passos concretos de hardening.

Por que executar um servidor de desktop remoto Linux? Árvore de decisão rápida

Antes de entrar nos comandos: escolha o modelo que atende às suas necessidades.

• Se você precisa de acesso direto à sessão X física em uma máquina (interagindo com o usuário logado, estado da sessão local, múltiplos monitores), X11VNC é a ferramenta servidor mais simples.
• Se você quer um modelo cliente/servidor que suporte NAT traversal, servidores de ID, relays e clientes multiplataforma mais fáceis — e deseja hospedar esses componentes de servidor — execute os daemons hbbs/hbbr do RustDesk.
• Se você só quer um túnel rápido para suporte pontual em uma única máquina, um túnel SSH ou usar um serviço hospedado ainda pode ser mais rápido. Veja também nosso guia sobre self-hosted remote desktop para estratégia e trade-offs.

Nota: produtos comerciais como TeamViewer e AnyDesk frequentemente vencem em conveniência pura (traversal automático de NAT e codecs otimizados prontos para uso). São escolhas razoáveis se você precisa de confiabilidade plug-and-play e suporte comercial; veja nossa comparação de trade-offs em rustdesk-vs-anydesk.

1) X11VNC: um servidor de desktop remoto Linux minimal que expõe a sessão X física

X11VNC conecta-se a um servidor X existente e serve a área de trabalho atual. Não é um desktop virtual separado — ele espelha a GUI localmente logada. Isso o torna excelente para suporte remoto e administração quando você quer interagir com a mesma sessão que um usuário local vê.

Pré-requisitos e versões recomendadas

• Funciona em desktops baseados em X11. Para Wayland, use APIs remotas específicas do compositor ou uma abordagem diferente.
• Instale x11vnc >= 0.9.16 (0.9.16+ traz recursos modernos e melhorias de estabilidade).
• Certifique-se de ter um display manager (gdm/lightdm/sddm) ou uma sessão X rodando em :0.

Instalação no Debian/Ubuntu (exemplo):

sudo apt update
sudo apt install -y x11vnc xauth

Crie um arquivo de senha (armazene-o com segurança):

sudo x11vnc -storepasswd /etc/x11vnc.pass
sudo chown root:root /etc/x11vnc.pass
sudo chmod 600 /etc/x11vnc.pass

Unidade systemd simples para iniciar automaticamente na tela :0 (coloque em /etc/systemd/system/x11vnc.service):

[Unit]
Description=x11vnc - VNC server for :0
After=display-manager.service

[Service]
Type=simple
ExecStart=/usr/bin/x11vnc -auth guess -forever -loop -noxdamage -repeat -rfbauth /etc/x11vnc.pass -rfbport 5900 -shared -ncache 10
User=root
Restart=on-failure

[Install]
WantedBy=graphical.target

Habilitar e iniciar:

sudo systemctl daemon-reload
sudo systemctl enable --now x11vnc.service
sudo systemctl status x11vnc.service

Observações de segurança para X11VNC

• Não exponha TCP/5900 diretamente na internet sem proteções adicionais. A autenticação VNC é aceitável para uso em LAN, mas deve ser tratada como fraca em redes públicas.
• Prefira um túnel SSH para acesso remoto: ssh -L 5900:localhost:5900 user@your-server e, em seguida, conecte um cliente VNC a localhost:5900.
• Se precisar de TLS direto, use stunnel ou uma VPN. Ou coloque o VNC atrás de um firewall adequado e exija acesso via VPN.

Dicas de desempenho

• Use -ncache 10 para reduzir picos de largura de banda quando o conteúdo da área de trabalho muda rapidamente.
• Quando observar alta CPU em links de 1–2 Mbps, reduza a profundidade de cor ou use flags de compressão (x11vnc suporta -compresslevel e -quality). Teste — qualidade menor frequentemente traz melhor responsividade percebida.

2) RustDesk daemon: ID server e relay auto-hospedado para acesso remoto moderno

RustDesk fornece um cliente que pode usar um servidor central de ID (hbbs) e um relay (hbbr) para conectar pares mesmo atrás de NAT. Executar seus próprios hbbs/hbbr dá controle total sobre IDs e relays — importante se você quer evitar servidores de terceiros. Este é o setup no lado do servidor que a maioria das pessoas quer ao buscar um servidor de desktop remoto Linux em um modelo auto-hospedado.

Por que executar hbbs/hbbr em vez de um único binário? Hbbs é o servidor de ID (autenticação, atribuição), hbbr é o servidor de relay (relay TCP/UDP para mídia quando o P2P direto falha). Ambos são leves e comumente executados em Docker.

Versões recomendadas: use os componentes do servidor rustdesk 1.1.9+ (ou a tag stable mais recente na hora da implantação). Revise as notas de versão no projeto RustDesk antes de rollouts em produção.

Exemplo de Docker Compose para hbbs + hbbr (mínimo)

version: '3.3'
services:
  hbbs:
    image: rustdesk/rustdesk-server:1.1.9
    container_name: rustdesk_hbbs
    restart: unless-stopped
    ports:
      - "21115:21115/tcp"  # hbbs TCP (ID server)
    environment:
      - RUST_LOG=info
    volumes:
      - ./data/hbbs:/data

  hbbr:
    image: rustdesk/rustdesk-server:1.1.9
    container_name: rustdesk_hbbr
    restart: unless-stopped
    ports:
      - "21116:21116/tcp"  # hbbr TCP (relay)
      - "21116:21116/udp"  # hbbr UDP for hole punching/relay
    environment:
      - RUST_LOG=info
    volumes:
      - ./data/hbbr:/data

Observações sobre portas e NAT

• As portas padrão do RustDesk comumente mapeadas são 21115 (hbbs ID server) e 21116 (hbbr relay). UDP é útil para NAT traversal; abra TCP e UDP sempre que possível.
• Mantenha o servidor em um IP público ou em um host com IP/DNS estático. Use um registro A/AAAA para o hostname que você configurar nos clientes.

Configurando o lado do cliente

Aponte o cliente RustDesk para o hostname do seu hbbs e habilite o relay conforme necessário. Você pode forçar o uso de relay por privacidade ou permitir peer-to-peer se ambos os clientes conseguirem perfurar o NAT. A interface de configuração do cliente aceita o hostname e porta do seu servidor (por exemplo, server.example.com:21115).

Protegendo uma implantação RustDesk daemon auto-hospedada

O tráfego padrão do RustDesk é criptografado entre pares, mas os componentes de servidor autenticam e coordenam. Considere estes passos de hardening:

• Execute hbbs/hbbr atrás de um firewall e abra apenas as portas necessárias (21115 TCP, 21116 TCP/UDP). Use UFW ou firewall-cmd; exemplo: sudo ufw allow 21115/tcp; sudo ufw allow 21116/tcp; sudo ufw allow 21116/udp.
• Use TLS/HTTPS para qualquer UI administrativa exposta na web que você adicionar. Se terminar TLS em um reverse proxy (nginx/caddy), mantenha o backend isolado.
• Monitore logs e uso de recursos. Os componentes RustDesk são leves, mas você deve observar contagens de conexões e largura de banda do relay.
• Considere rate-limiting e fail2ban no host se observar tentativas de brute-force contra a porta do hbbs.

Quando escolher RustDesk vs X11VNC

• Escolha RustDesk quando precisar de suporte a clientes multiplataforma (Windows/Mac/Linux/Android/iOS), NAT traversal e um único ID/relay auto-hospedado para muitos endpoints. É uma solução moderna para frotas distribuídas.
• Escolha X11VNC quando você atende máquinas de desktop específicas e precisa interagir com a sessão X local (por exemplo, para solucionar problemas do usuário logado ou problemas gráficos de boot).

Notas práticas de produção e ajuste de desempenho

Largura de banda e CPU: espere que sessões de desktop remoto diretas consumam entre 1–5 Mbps para tarefas de escritório típicas com codecs comprimidos; compartilhamento de tela com vídeo ou jogos provocará picos bem maiores. Se você hospedar seu próprio relay (hbbr), faça orçamento para largura de banda de relay: 100 sessões concorrentes a 2 Mbps = ~200 Mbps de capacidade contínua.

Monitoramento e autoscaling: para organizações maiores, execute hbbs com um pequeno HA proxy ou load balancer à frente, e execute múltiplos relays hbbr distribuídos por regiões. Use orquestração de contêineres padrão (Docker Swarm ou Kubernetes) se precisar de auto-scaling; caso contrário, uma única VM relay robusta é suficiente para equipes pequenas.

Registro e solução de problemas

• Os logs do x11vnc aparecem no journal do systemd: sudo journalctl -u x11vnc.service
• Containers RustDesk: docker logs rustdesk_hbbs e docker logs rustdesk_hbbr para erros de inicialização. Verifique a alcançabilidade de portas com ss ou netstat e teste UDP/TCP a partir de um cliente remoto.
• Se conexões diretas falharem, confirme se UDP não está sendo bloqueado por NATs intermediários ou firewalls; muitos provedores bloqueiam faixas UDP incomuns.

Comparação de segurança e visão franca sobre fornecedores

Se segurança e privacidade são prioridades máximas, hospedar hbbs/hbbr lhe dá controle sobre metadados e endpoints de relay. No entanto, fornecedores proprietários como TeamViewer ou AnyDesk podem oferecer traversal de NAT pronto, codecs proprietários com bitrates menores para links ruins e suporte/SLAs empresariais. Podem ser melhores se você precisar de suporte comercial 24/7 garantido e onboarding mais simples para usuários não técnicos — mas essa conveniência tem custo. Veja anydesk-pricing-explained para diferenças de preços e trade-offs.

Checklist prático antes de entrar em produção

1. Decida qual modelo atende você (X11VNC para sessões físicas vs RustDesk para acesso baseado em ID/relay).
2. Hardenize o servidor: firewall, apenas chaves SSH, fail2ban para rate-limiting e TLS onde aplicável.
3. Teste a partir de fora da sua rede: verifique comportamento do relay, latência e failover.
4. Configure monitoramento (logs, largura de banda, reinícios de processos) e uma política de alertas para indisponibilidades.

Leitura adicional e recursos internos

Se você está avaliando opções self-hosted mais amplas e os trade-offs, leia nosso guia self-hosted em /self-hosted-remote-desktop. Para uma comparação focada de recursos entre RustDesk e opções comerciais, veja /rustdesk-vs-anydesk.

Notas práticas finais

Ambas as abordagens são mantíveis, mas resolvem problemas ligeiramente diferentes. X11VNC é simples e previsível para desktops únicos; os daemon(s) RustDesk escalam melhor para frotas e lidam com NAT traversal de forma mais elegante quando configurados corretamente. Em todos os casos, nunca exponha VNC não criptografado diretamente à internet — use sempre túneis SSH, VPNs ou um relay devidamente hardenizado.

Pronto para testar? Baixe os clientes Tenvo (godeskflow) ou consulte nossa documentação de servidor em /download — e se precisar de opções de preço ou empresariais, veja /pricing. Faça o deploy de uma instância de teste, exercite suas regras de firewall e valide o comportamento dos clientes antes de liberar para os usuários.