Cloudflare Tunnel: exponha serviço interno sem abrir porta

O Cloudflare Tunnel expõe um serviço interno na internet sem abrir nenhuma porta no firewall e sem precisar de IP público fixo. Em vez de esperar conexão de entrada, um daemon instalado no servidor (o cloudflared) abre uma conexão de saída até a borda da Cloudflare — o tráfego chega por lá e é encaminhado de volta pelo túnel. Funciona atrás de CGNAT, em link residencial ou em rede corporativa sem NAT/port forward configurado.

Por que usar em vez de abrir porta no roteador ou firewall

Port forward tradicional expõe o IP do servidor diretamente para varredura e ataque de força bruta — é por isso que SSH na porta 22 aberta para a internet aparece em qualquer log de honeypot em minutos. O túnel inverte essa lógica:

• Nenhuma porta de entrada exposta. O firewall de borda continua fechado para tráfego não solicitado; só existe conexão de saída do servidor para a Cloudflare.
• Funciona sem IP público. Útil atrás de CGNAT de operadora, em links móveis ou em ambientes onde o Patrick não tem controle do roteador de borda.
• TLS e DDoS mitigation ficam por conta da Cloudflare, na borda, antes do tráfego chegar na sua rede.
• Integra com Cloudflare Access para exigir login (Google, GitHub, e-mail corporativo) antes de qualquer requisição alcançar o serviço interno — dá para colocar um painel administrativo atrás de autenticação sem tocar no código da aplicação.

O ponto de atenção é justamente esse: por padrão o hostname fica acessível para qualquer um que conheça a URL. Autenticação (Access) e regras de ingress restritas não são opcionais para nada sensível — isso fica explicado depois do passo a passo.

Passo a passo: instalar e configurar o cloudflared no Ubuntu

Requisitos: um domínio já usando a Cloudflare como servidor DNS (o registro pode estar em qualquer registrador, só o DNS precisa apontar para a Cloudflare) e acesso root ao servidor Ubuntu.

1. Adicionar o repositório oficial e instalar o pacote

Evite baixar o .deb avulso do GitHub — ele não atualiza sozinho. O repositório oficial resolve isso com apt upgrade normal:

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | sudo tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main" | sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt-get update && sudo apt-get install cloudflared

2. Autenticar o servidor na sua conta Cloudflare

cloudflared tunnel login

O comando imprime uma URL. Abra em qualquer navegador logado na conta Cloudflare, escolha o domínio e autorize. Isso grava um certificado em ~/.cloudflared/cert.pem — é o que autoriza este servidor a criar túneis na sua conta.

3. Criar o túnel e guardar as credenciais

cloudflared tunnel create servidor-interno

Anote o UUID retornado. O comando grava um arquivo JSON de credenciais em ~/.cloudflared/<UUID>.json — sem ele o túnel não sobe.

4. Escrever o arquivo de configuração

Crie /etc/cloudflared/config.yml:

tunnel: <UUID-do-tunel>
credentials-file: /etc/cloudflared/<UUID-do-tunel>.json

ingress:
  - hostname: painel.seudominio.com.br
    service: http://localhost:8080
  - hostname: ssh.seudominio.com.br
    service: ssh://localhost:22
  - service: http_status:404

A última linha é obrigatória — é o catch-all que recusa qualquer hostname não listado explicitamente. Sem ela o cloudflared não inicia. Copie o arquivo de credenciais para /etc/cloudflared/ antes de seguir.

5. Apontar o DNS para o túnel

cloudflared tunnel route dns servidor-interno painel.seudominio.com.br
cloudflared tunnel route dns servidor-interno ssh.seudominio.com.br

Isso cria um registro CNAME apontando para <UUID>.cfargotunnel.com — não aparece um IP no DNS público, só o endereço interno do túnel.

6. Testar antes de virar serviço

cloudflared tunnel run servidor-interno

Acesse o hostname configurado por fora da rede. Se responder, encerre com Ctrl+C e siga para o passo de produção.

Rodando como serviço systemd, em produção

Rodar em primeiro plano só serve para teste — em produção o túnel precisa sobreviver a reboot e reiniciar sozinho se cair.

sudo cloudflared service install
sudo systemctl enable --now cloudflared
sudo systemctl status cloudflared

O comando service install lê automaticamente o /etc/cloudflared/config.yml e registra a unit do systemd. Para acompanhar problemas depois de qualquer mudança:

journalctl -u cloudflared -f

Boas práticas de segurança

1. Coloque Cloudflare Access na frente de tudo que não é público. No painel Zero Trust, crie uma política de Access para o hostname exigindo e-mail corporativo ou login social antes de liberar a requisição — isso acontece na borda, antes do tráfego chegar no seu servidor.
2. Nunca aponte ingress para 0.0.0.0 ou para um serviço que já assume que só a rede local acessa. Um painel administrativo sem senha, pensado para LAN, fica exposto do mesmo jeito que ficaria com porta aberta se você não colocar Access na frente.
3. Um túnel por função, não um túnel genérico para tudo. Múltiplos hostnames no mesmo config.yml facilitam a administração, mas revogar acesso de um serviço comprometido é mais rápido com túneis separados.
4. Rotacione o arquivo de credenciais se o servidor for comprometido. cloudflared tunnel cleanup e recriar o túnel invalida o JSON antigo.

Perguntas frequentes

Preciso de IP público ou porta aberta no roteador?
Não. O cloudflared abre a conexão de dentro para fora; funciona atrás de CGNAT e de qualquer NAT sem configuração adicional no roteador.

O Cloudflare Tunnel é gratuito?
Sim, para uso de um único usuário/equipe pequena o túnel em si não tem custo. O Cloudflare Access tem uma cota gratuita de usuários; acima dela entra em plano pago.

Dá para expor SSH e RDP, não só HTTP?
Sim. O ingress aceita ssh://, rdp:// e TCP genérico além de http:///https://, como no exemplo do passo 4.

O que acontece se o servidor cair?
O hostname simplesmente para de responder — a Cloudflare não tem um servidor de origem alternativo. Não há failover automático sem configurar múltiplos cloudflared apontando para o mesmo túnel em servidores diferentes (load balancing de origem).

Isso substitui uma VPN site-to-site?
Não para todos os casos. O túnel expõe serviços específicos por hostname; uma VPN como WireGuard ou IPsec conecta redes inteiras. Para acesso amplo a múltiplos sistemas internos, o Cloudflare Tunnel combinado com o WARP client (modo Zero Trust) se aproxima mais de uma VPN completa.

Conclusão

Para expor um serviço específico — painel de monitoramento, webhook, acesso SSH pontual — o Cloudflare Tunnel elimina a superfície de ataque que um port forward tradicional cria, sem exigir IP fixo nem regra de firewall de entrada. O ganho de segurança real, porém, só existe se a política de Access for configurada junto: o túnel sozinho apenas transporta o tráfego, não decide quem pode entrar.