Como acessar o WebApp do Protheus sem abrir portas no servidor
Você precisa acessar o Protheus WebApp de fora da empresa — de casa, do cliente, do celular — com segurança. O caminho antigo era feio: abrir porta no firewall, expor o IP público do servidor, brigar com certificado, talvez montar uma VPN. Cada uma dessas opções aumenta a superfície de ataque do seu ERP. E a técnica a seguir vale para qualquer aplicação web interna — um dashboard, um sistema legado —, não só o Protheus.
Tem um jeito muito melhor: Cloudflare Tunnel. A ideia é elegante — em vez de abrir uma porta de entrada, o servidor abre uma conexão de saída para a Cloudflare, e todo o tráfego passa por dentro dela. O firewall continua fechado. O IP de origem nunca aparece. E o HTTPS você ganha de graça.
Por que isso é mais seguro
A inversão é o ponto. Numa publicação tradicional, o mundo inteiro consegue
bater na sua porta — e você torce para que o cadeado segure. Com o túnel,
não existe porta para bater: o cloudflared (o agente que roda no servidor)
inicia a conexão para fora, e a Cloudflare só entrega tráfego por aquele canal já
estabelecido.
Na prática você ganha:
- Nenhuma porta de entrada aberta no firewall.
- IP de origem oculto — atacante não descobre onde o serviço mora.
- SSL/TLS gerenciado pela Cloudflare, sem lidar com renovação de certificado.
- Zero Trust opcional — dá para exigir login (Google, e-mail, OTP) antes de o tráfego sequer chegar ao app.
A receita
1. Instale e autentique o cloudflared no servidor
O agente roda no mesmo servidor (ou rede) da aplicação. Você cria um túnel gerenciado remotamente (token), em que o mapeamento de rotas vive no painel da Cloudflare — não num arquivo local. Isso facilita operar vários hostnames.
2. Aponte o ingress para o serviço local
O túnel mapeia um hostname público → serviço local. Por exemplo,
app.seudominio.com.br → http://localhost:PORTA, onde PORTA é a porta web da
sua aplicação interna.
Em túneis gerenciados por token, esse mapa fica no painel. Mas dá para
inspecionar o túnel em execução lendo o endpoint de métricas local do
cloudflared (algo como http://127.0.0.1:<porta-de-métricas>/config), que
lista cada hostname → service ativo. É ótimo para depurar "por que esse host
não resolve?".
3. Publique o DNS — o pulo do gato
Para o hostname resolver, crie um registro CNAME proxied apontando para o túnel:
app.seudominio.com.br CNAME <TUNNEL_ID>.cfargotunnel.com (proxied)
Esse <TUNNEL_ID>.cfargotunnel.com é o endereço mágico do túnel. Com o registro
proxied (nuvem laranja), a Cloudflare assume a borda, entrega o SSL e roteia para
o cloudflared certo. Dá para automatizar isso com a API da Cloudflare em três
chamadas (achar a zona, checar se já existe, criar o CNAME).
4. Elimine o "conteúdo misto" (mixed content)
O erro mais comum depois que sobe: a página abre em HTTPS, mas o app gera links
internos em HTTP (imagens, APIs, websocket). O navegador bloqueia, e você vê
metade da tela. A correção é garantir que a aplicação saiba que está atrás de
HTTPS — ajustando o host/baseUrl das suas chamadas internas para o domínio
público, não para o IP/porta antigos.
5. Valide a cadeia de ponta a ponta
Navegue de fora, confirme o HTTP 200 e cheque o encadeamento:
navegador → Cloudflare (SSL) → túnel → serviço. Sem aviso de conteúdo misto,
sem certificado quebrado, tráfego criptografado fim a fim.
O caso do Protheus WebApp
Esse padrão funciona para qualquer app web interno, e ele brilha num caso específico da comunidade TOTVS: publicar o Protheus WebApp sem expor o servidor. O "serviço local" do ingress vira a porta WebApp do AppServer/broker, e valem dois cuidados que economizam horas:
- Mixed content no broker: o broker precisa entregar os recursos já em HTTPS; caso contrário o SmartClient web carrega pela metade. Aponte o host público, não o IP interno.
- Keepalive de websocket: a sessão web mantém um websocket vivo. Se o
ConnectionTimeoutdo AppServer for curto, a sessão cai por inatividade. Aumentar esse timeout (e manter o keepalive) resolve as quedas misteriosas depois de alguns minutos parado.
O resultado: acesso ao ERP de qualquer lugar, com HTTPS de verdade e sem abrir um único furo no firewall.
O que fica
Cloudflare Tunnel troca o modelo "abra uma porta e reze" por "não tenha porta nenhuma". Para sistemas internos sensíveis — e ERP é o exemplo perfeito — essa inversão é a diferença entre uma superfície de ataque exposta e uma que simplesmente não existe do lado de fora.