Pular para o conteúdo
← Voltar para o blog
Acesso remoto

Como usar o RustDesk na rede local com acesso direto por IP

10 min de leitura

Escrito por: Jonathan Reis em

O ID numérico do RustDesk é prático, mas pode usar um relay público quando a negociação P2P falha. Neste teste de LAN, o acesso direto por IP foi visivelmente mais rápido e manteve a sessão de desktop que já estava em uso.

Imagem de prévia OpenGraph deste artigo. Como usar o RustDesk na rede local com acesso direto por IP

O RustDesk é uma ferramenta de controle remoto: quem conecta vê o desktop que já está aberto e pode compartilhar mouse e teclado. Isso é diferente do Remote Desktop Protocol (RDP) do Windows, que normalmente inicia outra sessão e pode bloquear a sessão de console em uma edição cliente do Windows.

Essa diferença apareceu ao substituir um fluxo de acesso remoto que se comportava como o AnyDesk. O RDP era rápido, mas interrompia quem estava na máquina. O RustDesk preservava o modelo de interação certo e trouxe outra pergunta: por que a conexão usando o ID numérico parecia lenta se os dois computadores estavam na mesma rede?

Não dá para concluir que toda conexão por ID do RustDesk passa por relay. O RustDesk pode estabelecer um caminho P2P direto, mas NAT, firewall ou regras do Wi-Fi podem impedir isso. Para dispositivos na mesma LAN confiável, ele também oferece um listener explícito de acesso direto por IP. Conectar nesse listener evita a rota de descoberta por ID naquela sessão.

Este guia configura esse caminho local, mostra como verificá-lo e separa o problema de rede do ajuste de qualidade da imagem. No ambiente testado, conectar pelo endereço e porta da LAN foi visivelmente mais rápido que conectar pelo ID numérico do RustDesk. Esse resultado é evidência desta rede, não uma garantia de desempenho em qualquer cenário: uma conexão por ID pode já estar direta, e outra LAN pode ter gargalos diferentes.

Comece pelo comportamento de sessão necessário

Escolha o protocolo de acesso remoto pelo comportamento da sessão antes de otimizar latência.

O RDP serve quando uma sessão separada é aceitável ou desejável, como em um host administrativo. Ele é uma escolha ruim quando alguém precisa continuar logado no computador físico, acompanhar o que a pessoa remota faz ou retomar exatamente o que estava na tela.

O RustDesk, como outras ferramentas de compartilhamento de tela, captura e controla o desktop atual. A sessão local permanece ativa. O ID numérico é a forma normal de localizar outro dispositivo, inclusive fora de casa. Esse ID não prova, por si só, que os frames de vídeo usam um relay público: o cliente pode criar uma conexão direta depois da negociação. Ainda assim, quando a sessão não é direta, um relay adiciona mais um salto de rede e pode ser o gargalo.

O acesso direto por IP tem um papel mais limitado: ele aceita uma conexão RustDesk em um endereço e porta da LAN. Só faz sentido quando os dispositivos já conseguem se rotear localmente. Não é uma configuração para acesso pela internet e não deve ser exposto com redirecionamento de porta no roteador.

Habilite o acesso direto por IP na máquina controlada

Configure o listener em todo computador que deve receber conexões locais pelo RustDesk. No aplicativo desktop, abra Configurações > Segurança > Segurança, desbloqueie as opções caso o cliente peça e habilite Acesso direto por IP.

A referência oficial de configurações avançadas do RustDesk documenta essa opção como direct-server. A mesma referência registra 21118 como porta padrão do acesso direto por IP. Mantenha a porta padrão, a menos que outro serviço local já a use. Se trocá-la, use a nova porta no endereço de conexão.

Em uma LAN doméstica, configure também uma lista de IPs permitidos. O RustDesk aceita notação CIDR, então uma rede como 192.168.1.0/24 pode ser liberada sem cadastrar cada dispositivo. Essa lista reduz quem consegue chegar ao listener local, mas não é autenticação. Mantenha uma senha permanente forte ou exija aprovação manual, conforme o uso da máquina.

Não confunda descoberta na LAN com acesso direto por IP. A descoberta faz pares aparecerem na rede local. O acesso direto por IP abre um listener alcançável por endereço e porta. A descoberta pode ser útil, mas o endereço explícito é o teste confiável quando você investiga lentidão.

Encontre o endereço LAN da máquina remota

O endereço deve pertencer à interface de rede que os dois dispositivos realmente compartilham. Não use IP público e não copie um endereço de adaptador VPN, salvo quando a intenção for atravessar deliberadamente essa VPN.

No Windows, execute no PowerShell ou Prompt de Comando e leia o endereço IPv4 do adaptador Wi-Fi ou Ethernet ativo:

ipconfig

No macOS, abra Ajustes do Sistema > Rede, selecione o Wi-Fi ou Ethernet ativo e entre em Detalhes > TCP/IP. Um endereço doméstico comum se parece com 192.168.1.50, 192.168.0.50 ou 10.0.0.50.

Um endereço na mesma faixa é apenas um indício. 192.168.1.20 e 192.168.1.50 normalmente compartilham uma LAN, mas Wi-Fi de convidados, VLANs e isolamento de clientes sem fio podem bloquear o tráfego entre eles de propósito. O teste por IP direto revela essa diferença.

Conecte por endereço e porta, não pelo ID do RustDesk

Na máquina que fará o controle, informe o endereço da máquina remota no campo de conexão normal do RustDesk neste formato:

192.168.1.50:21118

Troque os dois valores pelo IP real da LAN e pela porta configurada na máquina remota. Autenticação e permissões continuam valendo. A única mudança é a forma de o RustDesk alcançar o computador controlado.

Volte a usar o ID numérico do RustDesk quando estiver fora de casa. Um endereço LAN privado normalmente não é alcançável de outra rede, e publicar a porta 21118 no roteador transformaria um recurso local de diagnóstico em um serviço exposto à internet. Se o acesso externo for frequente, use o fluxo normal do RustDesk, uma rede privada confiável ou uma instalação RustDesk auto-hospedada mantida de propósito, em vez de expor o listener direto.

Verifique se o caminho local está funcionando de fato

Uma conexão que abre não é evidência suficiente de que a rota desejada foi usada. Durante a sessão, abra as informações de conexão ou o monitor de qualidade do RustDesk e procure uma conexão direta, não relay. A referência oficial expõe Mostrar monitor de qualidade em Configurações > Exibição > Outras opções padrão. Ative-o antes do teste se estiver oculto.

Teste a mesma tarefa duas vezes enquanto os computadores estiverem na LAN: uma com o ID numérico e outra com IP:porta. Compare tipo de conexão reportado, latência, quadros por segundo e resposta do mouse e teclado. Isso é melhor que comparar pela memória, até porque uma conexão por ID pode já estar direta.

Neste teste, o acesso direto por IP deixou a sessão visivelmente mais rápida. Isso torna a rota uma suspeita mais forte que a captura de tela isoladamente neste ambiente. Se a mesma comparação não melhorar outra sessão, mantenha a conexão direta e investigue captura, codificação, Wi-Fi ou CPU.

Corrija firewall e barreiras do Wi-Fi antes de mexer em codec

Quando a conexão direta falha, o erro comum é reduzir a qualidade de imagem imediatamente. Isso pode esconder o sintoma, mas não faz dois dispositivos se comunicarem através de uma rede local bloqueada.

Primeiro, confirme que o firewall do sistema permite o RustDesk em uma rede privada. No Windows, verifique a regra do RustDesk no Windows Defender Firewall e confirme que o perfil da rede está como Privado, não Público. No macOS, permita conexões de entrada para o RustDesk em Ajustes do Sistema > Rede > Firewall quando o macOS pedir.

Depois, examine a topologia. SSIDs de convidados costumam isolar clientes por definição. Muitos roteadores chamam o mesmo recurso de AP isolation, client isolation ou wireless isolation. VLANs separadas também podem bloquear tráfego lateral mesmo quando cada dispositivo acessa a internet. Um desktop cabeado e um notebook no Wi-Fi também podem ser afetados, dependendo da configuração do ponto de acesso.

Antes de testar o RustDesk de novo, faça uma checagem simples de alcance a partir da máquina controladora:

Test-NetConnection 192.168.1.50 -Port 21118

No macOS ou Linux, use:

nc -vz 192.168.1.50 21118

Um teste TCP bem-sucedido não prova que o RustDesk será fluido, mas um teste que falha restringe o problema ao listener, firewall, IP ou política de rede. Corrija isso primeiro.

Ajuste a sessão somente depois de confirmar a rota direta

Com a sessão local e direta, as opções de vídeo passam a tratar outro problema: quanto dado de imagem a máquina remota captura, codifica, transfere, decodifica e desenha.

Comece com bitrate adaptativo e codec de hardware habilitados no RustDesk. O cliente documenta ambas as opções: o bitrate adaptativo ajusta o stream às condições da conexão, e a codificação por hardware pode deixar a imagem mais fluida quando placa de vídeo e driver oferecem suporte. Se o codec de hardware causar artefatos ou imagem preta, desative-o e teste de novo. O caminho por hardware não é melhor em todo driver.

Para administração comum, escolha qualidade de imagem equilibrada em vez da máxima. Reduza a resolução ou selecione um único monitor quando a máquina usa várias telas de alta resolução. Remova temporariamente o papel de parede remoto se efeitos visuais consumirem banda ou tempo de codificação. Essas mudanças trocam detalhe de imagem por menor custo de codificação e transferência; elas não corrigem relay, isolamento no Wi-Fi ou porta bloqueada.

Ethernet continua sendo a forma mais simples de reduzir variação em um desktop remoto. Se Wi-Fi for obrigatório, use a rede que não é de convidados e teste perto o suficiente do ponto de acesso para eliminar sinal ruim antes de culpar o RustDesk.

Fluxo completo de acesso local

Use esta sequência em cada máquina que deve aceitar acesso direto pela LAN:

1. Instale o RustDesk e defina a política de acesso de entrada.
2. Em Configurações > Segurança > Segurança, habilite Acesso direto por IP.
3. Mantenha a porta 21118 ou anote a porta substituta escolhida.
4. Quando fizer sentido, limite o listener à LAN confiável com lista de IPs permitidos.
5. Encontre o IPv4 LAN ativo da máquina remota.
6. Confirme que o firewall libera o RustDesk em rede privada.
7. Na máquina controladora, teste o alcance de IP:21118.
8. Conecte no RustDesk usando IP:porta, não o ID numérico.
9. Use o monitor de qualidade para confirmar rota direta antes de alterar opções de exibição.
10. Mantenha o listener privado: não redirecione a porta no roteador.

Checklist

  • A máquina remota está com RustDesk aberto ou instalado e acesso direto por IP habilitado.
  • O endereço é o IP LAN ativo da máquina remota, não IP público ou endereço de VPN sem relação com o teste.
  • A conexão usa IP:21118 ou a porta substituta definida.
  • O RustDesk está liberado no firewall de destino em redes privadas.
  • Wi-Fi de convidados, AP isolation e regras de VLAN não bloqueiam tráfego entre dispositivos.
  • O monitor de qualidade mostra sessão direta antes de ajustar exibição.
  • A porta de acesso direto não está redirecionada no roteador para a internet.

A lição prática é separar comportamento de controle remoto de comportamento de transporte. O RustDesk é a classe de ferramenta correta quando o desktop atual precisa continuar visível. O acesso direto por IP é o teste correto quando a rota na mesma LAN precisa ser explícita. Se ainda estiver lento depois disso, o trabalho restante é diagnóstico de desempenho, não outra VPN nem outro protocolo de desktop remoto.

Post relacionadoComo conectar o Playwright MCP ao Chrome pelo Remote Debugging9 min de leituraEscrito por: Jonathan Reis em