Skip to content
Back to BlogTutorial

Configuração do RustDesk auto-hospedado — passo a passo completo com Docker + TLS via Caddy

GoDesk Editorial Team8 min de leitura
Configuração do RustDesk auto-hospedado — passo a passo completo com Docker + TLS via Caddy

Você quer hospedar o RustDesk por conta própria, mas esbarra em barreiras: NAT e firewalls, componentes de servidor confusos e a dúvida sobre precisar de TLS além da criptografia do RustDesk. Este guia leva um leitor técnico por uma configuração completa e reproduzível em um único VPS.

Você está tentando hospedar o RustDesk por conta própria, mas continua esbarrando nos mesmos obstáculos: NAT e firewalls, componentes de servidor confusos e a pergunta persistente se é necessário TLS além da própria criptografia do RustDesk. Este guia conduz um leitor com perfil técnico por uma configuração completa e reprodutível do RustDesk em um único VPS — Docker Compose para hbbs/hbbr, e TLS na frente usando Caddy para que clientes possam conectar pela porta 443 em redes restritivas.

O que vamos construir e por quê

Objetivo: um servidor de rendezvous e relay do RustDesk em um único VPS, que seus clientes apontem por nome DNS. Componentes em uso:

  • Componentes de servidor do RustDesk (hbbs e hbbr) rodando em Docker — testados aqui com imagens rustdesk-server v1.2.1.
  • Caddy v2 (gerenciamento de certificados via Let's Encrypt) para fornecer uma frente TLS na porta 443 para que clientes alcancem seu relay mesmo quando a saída 21115 estiver bloqueada.
  • Passagem UDP opcional ou relays adicionais para escala (tratados nas notas).

Por que fazer isso? O protocolo do RustDesk já fornece criptografia end-to-end para a sessão de desktop, mas muitas redes permitem apenas saída pelas portas 443/80. Terminar o TLS no seu VPS (e deixar o Caddy obter e renovar automaticamente os certificados) é uma forma prática de tornar o serviço acessível sem abrir portas não padrão. Se você quer apenas acesso em LAN ou controlar NAT com túneis reversos, veja nosso artigo sobre acesso remoto sem encaminhamento de portas.

Pré-requisitos e escolhas

O que usei ao escrever isto:

  • Ubuntu 22.04 LTS em um VPS público (1 vCPU / 2 GB de RAM é suficiente para testes; para muitos clientes aumente para 4+ CPUs e monitore CPU/RAM).
  • Docker 24.x e Docker Compose v2 (sintaxe do CLI do Compose V2).
  • imagem Docker rustdesk-server (tag v1.2.1 neste guia) — ajuste se existir release estável mais recente.
  • Caddy v2.6+ (o ACME automático do Caddy torna a renovação de certificados simples).
  • Um registro DNS A como rustdesk.example.com apontando para o IP público do VPS, e portas 80/443 liberadas (Caddy precisa de 80/443 para validar).

Notas sobre quando um produto comercial hospedado é mais adequado: se você precisa de SLA em nível empresarial, auditoria avançada de sessões ou suporte comercial, TeamViewer/AnyDesk podem ser melhores — veja rustdesk-vs-anydesk e nossos comparativos de preços. Auto-hospedar é melhor quando você quer controle, custos recorrentes menores ou evitar servidores de terceiros.

Etapa 1 — Implantar o servidor RustDesk com Docker Compose

Crie um diretório de projeto no VPS e coloque o docker-compose.yml abaixo. Este exemplo expõe as portas típicas do servidor RustDesk para o host. Substitua variáveis de ambiente e tags de imagem conforme seu ambiente.

mkdir -p ~/rustdesk-server
cd ~/rustdesk-server
cat > docker-compose.yml <<'EOF'
version: '3.8'
services:
  rustdesk-server:
    image: rustdesk/rustdesk-server:1.2.1
    container_name: rustdesk-server
    restart: unless-stopped
    ports:
      - "21115:21115/tcp"   # rendezvous / TCP relay
      - "21115:21115/udp"   # optional UDP relay (if your image supports it)
      - "21116:21116/udp"   # additional UDP (some builds use multiple UDP ports)
    volumes:
      - ./data:/root/.config/rustdesk-server
    environment:
      - RUSTDESK_RELAY_IPV4=0.0.0.0
      - RUSTDESK_RELAY_PORT=21115
EOF

Inicie:

docker compose up -d
# watch logs
docker compose logs -f rustdesk-server

Confirme que o contêiner iniciou e está escutando na porta 21115. No seu VPS execute:

ss -tuln | grep 21115

Se a imagem que você usa expõe portas diferentes ou tem um estilo de configuração distinto, consulte o README dessa imagem. Alguns operadores compilam hbbs/hbbr manualmente e usam portas customizadas; adapte estes passos conforme necessário.

Etapa 2 — Usar o Caddy para colocar TLS sobre o relay (443)

Existem dois padrões comuns para tornar o RustDesk acessível na porta 443:

  1. Terminação TLS de TCP com Caddy 2.6+ (o Caddy termina o TLS e encaminha TCP bruto para o relay do RustDesk). Caddy adicionou recursos TCP aprimorados na v2.6; se usar essa abordagem, você obtém certificados ACME automáticos e renovação.
  2. Deixar o Caddy gerenciar apenas os certificados e usar um proxy TCP (stunnel, HAProxy ou Nginx stream) para consumir esses arquivos de cert. Esta é uma alternativa caso sua versão do Caddy ou ambiente não suporte os recursos de proxy TCP necessários.

Abaixo está uma configuração mínima e pragmática do Caddy que usa o Caddy para TLS na porta 443 e encaminha a conexão TCP bruta para o relay do RustDesk em localhost:21115. Isso requer Caddy v2.6+ (verifique com caddy version).

# Caddyfile (save as ./Caddyfile in the same folder as docker-compose.yml)
rustdesk.example.com:443 {
    # Caddy will obtain/renew certificates automatically
    reverse_proxy 127.0.0.1:21115 {
        # Use plain TCP transport; Caddy will accept TLS from clients and connect to the backend via TCP
        transport http {
            # We don't speak HTTP to the backend; keep minimal transport settings
        }
    }
}

Trecho do docker-compose para executar o Caddy ao lado do servidor RustDesk (mesmo projeto):

cat >> docker-compose.yml <<'EOF'
  caddy:
    image: caddy:2.6.4
    container_name: caddy
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
volumes:
  caddy_data:
  caddy_config:
EOF

docker compose up -d caddy

Advertência importante: o reverse_proxy embutido do Caddy é orientado a HTTP, então o comportamento ao proxyar TCP bruto não-HTTP depende da versão do Caddy e das opções de transporte. Na prática, muitos operadores usam os recursos de proxy TCP do Caddy introduzidos na 2.6 para terminar TLS para backends TCP arbitrários. Se você encontrar problemas de protocolo, use a opção (2) acima: deixe o Caddy cuidar dos certificados e entregue os arquivos de cert a uma camada TLS TCP leve (stunnel ou HAProxy stream) que então proxie TCP puro para o RustDesk.

Exemplo: Caddy como gerenciador de certificados + stunnel para terminação TLS (visão rápida).

# 1) Ensure Caddy is running and has issued certs for rustdesk.example.com
# 2) Copy cert/key from Caddy storage into a place stunnel can read, or mount the same volume.
# 3) Run stunnel with a config that points TLS 443 -> 127.0.0.1:21115

# stunnel.conf snippet
[rustdesk]
accept = 443
connect = 127.0.0.1:21115
cert = /etc/stunnel/fullchain.pem
key = /etc/stunnel/privkey.pem

# In Docker world, mount Caddy's certificate files into the stunnel container path above.

Qualquer uma das abordagens provê um hostname (rustdesk.example.com) e porta 443 para os clientes. Teste conectividade a partir de outra máquina com: nc -vz rustdesk.example.com 443 — você deverá estabelecer um handshake TLS se o Caddy/stunnel estiverem configurados corretamente.

Etapa 3 — Aponte os clientes para seu servidor auto-hospedado

Os clientes RustDesk permitem servidores personalizados de ID/relay nas configurações. A interface varia por plataforma e versão, mas os valores essenciais são:

  • ID Server / Rendezvous: rustdesk.example.com:443 (ou seu domínio e porta)
  • Relay Server: rustdesk.example.com:443

No Windows: Abra RustDesk > Settings > ID/Server e defina Id server e Relay server para rustdesk.example.com:443. No Linux e macOS as mesmas opções existem em Preferências. Para instalações headless, o cliente às vezes aceita flags de linha de comando ou um arquivo de configuração — verifique o repositório do cliente para detalhes.

Certifique-se de que os clientes sejam recentes (1.2.x ou mais novos no momento da redação). Clientes mais novos incluem correções de protocolo e melhor travessia de NAT. Se você tentar usar um cliente muito mais antigo, o comportamento pode variar.

Solução de problemas e reforço de segurança

Problemas comuns e como diagnosticar:

  • Firewall: confirme que o firewall do VPS (ufw/iptables/console do provedor) permite entrada em 80/443. Para o contêiner do servidor RustDesk escutando localmente em 21115, verifique se o socket TCP existe (ss/netstat).
  • Emissão de certificado: se o Let's Encrypt não conseguir validar, o Caddy registrará um erro. Confirme que seu registro DNS A aponta para o VPS e que a porta 80 está acessível durante a emissão inicial.
  • Incompatibilidade de protocolo: se você vir sucesso no handshake TLS, mas falhas de conexão no cliente, pode estar proxyando apenas HTTP com Caddy por engano. Use a abordagem com stunnel nesses casos.
  • Relay UDP: o desempenho do RustDesk melhora com UDP para quadros de tela; se UDP for necessário e o caminho de rede bloquear UDP, você cairá para o relay TCP. Exponha/encaminhe as portas UDP apenas se você controlar a rede e souber o que está fazendo.

Dicas de reforço de segurança:

  • Execute o servidor RustDesk sob um usuário dedicado sem privilégios e mantenha as imagens Docker atualizadas.
  • Ative fail2ban ou similar para limitar tentativas repetidas de conexão falha, e monitore logs (docker compose logs -f rustdesk-server).
  • Faça backup regularmente do diretório de dados do rustdesk server (no exemplo é ./data).
  • Considere executar o relay atrás de uma rede privada ou VPC se você operar múltiplos relays.

Notas de escala: um único relay serve bem para equipes pequenas. Para implantações maiores, execute múltiplos processos hbbr em máquinas separadas e use balanceamento de carga via DNS ou um balanceador L4 apropriado. Se você precisa de recursos centralizados empresariais como auditoria, aí soluções comerciais podem ter vantagem. Veja nossos textos sobre self-hosted-remote-desktop e rustdesk-vs-anydesk para prós e contras.

Manutenção, custos e recomendações finais

Os custos operacionais são principalmente a taxa do VPS e seu tempo. Um VPS pequeno típico (1–2 CPU, 2–4 GB) pode ser encontrado por $5–10/mês (DigitalOcean, Vultr, Hetzner). Caddy e o servidor RustDesk são open-source; o custo recorrente principal é o hosting. Se você precisa de cobrança via GUI ou suporte empresarial, fornecedores comerciais cobram por assento ou por sessão — veja nossos comparativos de preço como anydesk-pricing-explained e godeskflow-vs-teamviewer-pricing para contexto.

Recomendações:

  • Comece com um único VPS e o layout Docker Compose acima. Teste conexões nas redes exatas que seus usuários usarão (ISPs residenciais, firewalls corporativos).
  • Se clientes estiverem frequentemente atrás de firewalls muito restritivos, coloque seu relay na 443 e verifique se a terminação TLS funciona de forma confiável; use Caddy+stunnel se o proxy TCP somente com Caddy causar problemas.
  • Automatize backups do diretório de dados do servidor e acompanhe atualizações de imagens. Releases do RustDesk server avançam; teste upgrades em um ambiente de staging se você depende da disponibilidade em produção.

Se você quiser um passo a passo mais curto sobre padrões de acesso remoto ou alternativas, leia nossos artigos relacionados: remote-access-setup-guide e remote-desktop-security.

Terminou de ler? Se quiser experimentar um desktop remoto totalmente open-source que se integra bem com auto-hospedagem, baixe GoDesk ou compare seus preços — veja GoDesk download e GoDesk pricing. Se você já está pronto para implantar esta configuração do RustDesk, comece criando o docker-compose.yml e o Caddyfile acima e execute docker compose up -d. Para um início rápido, vá para /download para baixar clientes e conectar.