Cloudflare Tunnel: como publicar serviços internos com mais segurança

Planeje a publicação de aplicações internas, configure o túnel e controle quem pode acessá-las com Cloudflare Access.

O Cloudflare Tunnel permite conectar uma aplicação interna à rede da Cloudflare sem abrir portas de entrada para esse caminho de publicação. Com o Cloudflare Access, você também pode exigir autenticação e permitir apenas as identidades necessárias.

Neste tutorial, o exemplo será um painel de homologação de uma agência em Recife: uma aplicação web na porta 8080, acessada por um subdomínio e liberada somente para dois revisores. O objetivo é estabelecer acesso seguro a aplicações internas, com testes que confirmem tanto a conectividade quanto os bloqueios.

O que é Cloudflare Tunnel e como ele conecta um serviço interno

O cloudflared é o conector instalado no servidor ou em um container. Ele inicia conexões de saída para a Cloudflare, permitindo encaminhar requisições até um serviço que consegue alcançar.

O caminho da requisição fica assim: navegador, rede da Cloudflare, túnel, conector e aplicação interna. Quando o Access está configurado, a verificação de identidade e das políticas ocorre antes de o visitante acessar a aplicação.

Um hostname, como homologacao.example.com, identifica a aplicação publicada. Esse endereço pode apontar, por meio da configuração do túnel, para um serviço no mesmo host do conector ou em outra máquina acessível pela rede.

Instalar o túnel não fecha exposições anteriores. Se o painel já responde pelo IP público, por uma porta redirecionada no roteador ou por outro hostname, esses caminhos continuam existindo até serem revisados.

Quando usar o Tunnel e quando considerar acesso privado ou VPN

O cenário deste artigo é uma aplicação HTTP ou HTTPS acessada pelo navegador. Ele atende, por exemplo, à revisão de um site antes da publicação ou ao acesso controlado a uma ferramenta interna.

Um ambiente de homologação no fluxo de CI/CD permite validar mudanças antes de colocá-las em produção. O Tunnel pode fornecer o caminho de acesso a esse ambiente, enquanto o Access restringe os participantes.

O hostname protegido continua sendo um endereço público. A autenticação controla a entrada, mas não transforma o serviço em um recurso acessível exclusivamente por uma rede privada.

Quando a equipe precisa alcançar vários recursos internos, endereços privados ou serviços de outros protocolos, avalie uma VPN ou uma arquitetura de acesso privado. Esses cenários podem exigir clientes e configurações específicos; não basta reproduzir a rota HTTP deste tutorial.

Considere também a dependência do provedor, a disponibilidade exigida, a compatibilidade da aplicação e os requisitos de tratamento de dados. Bancos de dados e interfaces administrativas merecem uma decisão própria de arquitetura, mesmo quando sua publicação parece conveniente.

Prepare o domínio, a aplicação e as regras de acesso

Antes de configurar o Cloudflare Tunnel, organize os requisitos do ambiente:

• Uma conta com permissões para administrar o túnel, o DNS e as aplicações do Access.
• Um domínio ativo na Cloudflare; este tutorial considera o DNS do domínio gerenciado nela.
• Um subdomínio dedicado, sem conflito com registros existentes.
• Um servidor ou container com conectividade de saída e acesso à origem.
• Uma aplicação de demonstração sem dados sensíveis para a primeira validação.
• Os dois revisores autorizados e o método de autenticação definido.

Teste a origem a partir do ambiente de execução do conector. Se aplicação e cloudflared estiverem diretamente no mesmo host, uma verificação inicial é:

curl --fail --show-error http://localhost:8080/

Confirme a resposta esperada da aplicação. Um erro nesse teste precisa ser resolvido antes da publicação. Se o conector estiver em Docker, o endereço e o local de execução do teste serão diferentes, como veremos adiante.

Para conectar o túnel, revise a saída na porta 7844: UDP para QUIC e TCP para HTTP/2, conforme o transporte utilizado. Confira também os destinos oficiais, a resolução DNS e as demais necessidades de instalação e atualização. Não abra uma porta de entrada apenas para viabilizar o túnel.

Consulte os limites, planos e recursos disponíveis na conta antes de depender de uma funcionalidade. Registre quem administra a configuração e quem poderá autorizar novos usuários.

Configure o Cloudflare Access antes de disponibilizar o serviço

O Tunnel fornece conectividade; o Access controla o acesso. Uma rota pública sem a aplicação correspondente no Access pode disponibilizar o serviço a qualquer visitante.

1. No painel, abra Zero Trust → Access controls → Applications e crie uma aplicação.
2. Escolha a opção de aplicação autogerenciada, apresentada como Self-hosted and private, e adicione o hostname público escolhido.
3. Crie uma política Allow que inclua somente os dois revisores, por identidades específicas ou por um grupo restrito.
4. Selecione o provedor de identidade e ajuste a duração das sessões.
5. Salve a aplicação antes de ativar a rota pública.

Exija autenticação multifator pelo provedor de identidade quando aplicável. Evite políticas Bypass abrangentes. Para automações, planeje credenciais de serviço e políticas específicas, sem liberar o painel inteiro.

Ative Protect with Access na configuração da origem do túnel para o conector validar o token da aplicação. Essa validação também pode ser implementada na origem. A proteção no conector não cobre conexões que chegam diretamente ao servidor por outro caminho.

Para planejar o login da própria aplicação, a discussão sobre JWT, OAuth 2.0 e sessões ajuda a distinguir mecanismos de autenticação e suas responsabilidades.

Crie o túnel, execute o cloudflared e configure a rota

Adote um túnel persistente gerenciado pelo painel para este cenário empresarial. A configuração remota facilita administrar o destino sem manter as regras de publicação em cada conector.

1. Abra Networking → Tunnels no painel da Cloudflare e selecione Create Tunnel.
2. Escolha um nome que identifique o ambiente, como homologacao-web.
3. Selecione o sistema operacional e a arquitetura do servidor.
4. Execute as instruções de instalação e execução apresentadas pelo painel, tratando o token como uma credencial.
5. Confirme que o conector aparece conectado, com estado Healthy.
6. Em Routes, adicione uma rota do tipo Published application.
7. Informe o hostname já protegido pelo Access e o endereço do serviço. Para aplicação e conector diretamente no mesmo host, use http://localhost:8080.
8. Confira a proteção do Access e a validação do token antes de liberar o uso.

Os nomes dos menus podem mudar. Use as instruções exibidas na sua conta e verifique o resultado, especialmente a associação entre hostname, aplicação do Access e origem.

Execute o conector como serviço do sistema ou container com reinicialização configurada. Uma sessão de terminal aberta não é uma estratégia suficiente de operação.

Proteja o token do túnel. Não o inclua em repositórios, capturas de tela, tickets ou exemplos compartilhados. Restrinja o acesso aos arquivos que armazenam a credencial e substitua-a se houver exposição.

Verifique os diferentes trechos de criptografia

Acesse o hostname externo por HTTPS e confira o certificado no navegador. Essa verificação não comprova que a conexão entre o conector e a aplicação também usa TLS.

O destino http://localhost:8080 usa HTTP no trecho local. Quando a origem estiver em outra máquina ou a política do ambiente exigir criptografia nesse trecho, configure uma origem HTTPS com certificado válido e confiável.

Se o certificado cobrir um nome diferente do endereço usado para conectar, configure originServerName adequadamente. Para uma autoridade certificadora privada, ajuste a confiança do conector. Mantenha a validação de certificados habilitada.

Como conectar o Cloudflare Tunnel a uma aplicação em Docker

Em uma instalação de Cloudflare Tunnel com Docker, localhost dentro do container aponta para o próprio container. Se a aplicação estiver em outro serviço, esse endereço não a alcançará.

Coloque o conector e a aplicação em uma rede compartilhada. No Compose, o nome do serviço pode ser usado como destino: neste exemplo, a rota no painel deve apontar para http://app:8080.

O trecho abaixo pressupõe que sua aplicação possui um Dockerfile em ./app e escuta em 0.0.0.0:8080. Defina CLOUDFLARED_IMAGE com uma imagem oficial cloudflare/cloudflared de versão testada, igual ou superior a 2025.4.0, que suporta --token-file.

services:
  app:
    build: ./app
    restart: unless-stopped
    networks:
      - aplicacao

  cloudflared:
    image: ${CLOUDFLARED_IMAGE:?Defina uma imagem cloudflared de versao testada}
    command:
      - tunnel
      - --no-autoupdate
      - run
      - --token-file
      - /run/secrets/tunnel_token
    restart: unless-stopped
    secrets:
      - tunnel_token
    networks:
      - aplicacao

networks:
  aplicacao:
    driver: bridge

secrets:
  tunnel_token:
    file: ./secrets/tunnel_token.txt

Crie o arquivo do segredo por um procedimento seguro, contendo apenas o token fornecido pelo painel. Garanta que ele seja legível pelo processo do conector, restrinja o acesso no host e exclua a pasta de segredos do controle de versão. O recurso de secrets do Compose não elimina a necessidade de proteger esse arquivo.

Depois de adaptar o exemplo ao projeto, inicie os serviços e confira os registros:

docker compose up -d --build
docker compose ps
docker compose logs --tail=100 cloudflared

Não há uma seção ports: o conector usa a rede Docker para alcançar a aplicação, sem precisar publicar a porta no host. Essa rede precisa permitir a saída do conector para a Cloudflare.

Teste http://app:8080 com uma ferramenta disponível em um container da mesma rede. Não presuma que a imagem do cloudflared oferece shell ou curl. Planeje atualizações das imagens e reinicie os containers de maneira controlada após cada alteração de versão.

Valide o acesso e reduza a exposição direta do servidor

Faça os testes a partir de uma rede externa. Use sessões separadas para evitar que cookies de um revisor autorizado escondam um problema de política.

Registre os resultados e confira também caminhos específicos, APIs e hostnames alternativos. Uma política aplicada somente a uma parte da aplicação pode deixar outra rota desprotegida.

Revise registros DNS antigos, redirecionamentos no roteador, regras de entrada do servidor e controles de rede do provedor. Remova a exposição desnecessária preservando os acessos administrativos legítimos e os demais serviços.

Em containers, confirme os mapeamentos de portas efetivos e as regras de rede. A padronização de ambientes com Docker ajuda a manter configurações previsíveis entre desenvolvimento e produção.

As permissões do Access e as permissões internas da aplicação têm funções distintas. Ser autorizado a entrar não deve conceder automaticamente poderes administrativos. Mantenha o login próprio quando necessário, atualizações, backups e testes de recuperação.

Resolva erros de conexão, origem e certificados

Investigue o caminho por etapas: identidade, conexão do túnel e comunicação com a origem. Uma negativa de autorização pode ser o resultado correto de uma política, enquanto uma falha de conectividade exige outro diagnóstico.

Nem todo 502 tem a mesma causa. Leia a mensagem apresentada e os logs do conector antes de alterar a configuração. Um túnel saudável não garante que a aplicação esteja funcionando.

No exemplo Docker, trocar http://localhost:8080 por http://app:8080 resolve o endereço incorreto somente se os containers compartilharem a rede e a aplicação estiver escutando na interface e porta esperadas.

Não desative a validação TLS como correção padrão. Ajuste o certificado, o nome da origem ou a confiança na autoridade certificadora. Antes de compartilhar logs, remova tokens, cookies, cabeçalhos de autenticação e dados pessoais.

Mantenha o acesso seguro após a implantação

A configuração precisa de um responsável e de uma rotina de revisão. Para um ambiente de homologação, uma revisão mensal pode acompanhar a entrada e a saída de participantes; mudanças de equipe exigem ação imediata.

• Revogue o acesso de prestadores e colaboradores ao encerrar sua participação.
• Revise políticas, grupos, sessões e credenciais de integrações.
• Atualize o conector e a aplicação com validação prévia.
• Monitore a disponibilidade do túnel e a resposta real da aplicação.
• Documente como recuperar o serviço e como remover sua publicação.

Conforme a criticidade, considere conectores redundantes em ambientes separados. Duas instâncias no mesmo servidor continuam dependendo da energia, da rede e da disponibilidade desse servidor. A origem também precisa de uma estratégia compatível com o nível de disponibilidade esperado.

O procedimento de desligamento deve incluir a remoção da rota pública, a revisão do DNS e a revogação das credenciais que perderam a finalidade. Não remova apenas a proteção do Access enquanto a aplicação continua publicada.

Nos projetos de criação de sites em Recife, esses cuidados ajudam a organizar a revisão com equipes e clientes: cada participante acessa o ambiente necessário, pelo período necessário. Essa prática segue o princípio do menor privilégio e a abordagem de Zero Trust.

Seu projeto precisa de um ambiente de homologação com acesso controlado? Converse com a equipe da Codephix sobre os requisitos do seu site ou sistema em Recife e avalie a arquitetura adequada antes da publicação.