Cloudflare Zero Trust e cloudflared

Resumo

Cloudflare Tunnel usa o daemon cloudflared para criar conexões de saída entre uma origem e a rede da Cloudflare, sem expor diretamente um IP público de entrada. Túneis gerenciados remotamente podem ser executados com um token, que deve permanecer secreto.

Uso atual

Confirmado (verificação operacional registrada em 2026-08-29): há conectores cloudflared ativos tanto no PC local Windows quanto na VM. O conector local é executado como serviço do Windows e usa o modo de túnel gerenciado remotamente pelo dashboard do Cloudflare Zero Trust.

Os identificadores de túnel e tokens não são registrados nesta nota.

Limitações e cuidados

• Um token de túnel permite executar o respectivo túnel; não deve ser incluído no vault, em comandos compartilhados ou em logs.
• A configuração de um túnel gerenciado remotamente é administrada no dashboard da Cloudflare; mudanças de rotas e hostnames exigem validar o destino de origem e a exposição pretendida.
• A existência de conectores em duas origens não implica que ambas publiquem os mesmos serviços. Confirmar cada hostname e rota no dashboard antes de alterações operacionais.

Incidente de origem registrado — 2026-09-12

Registro operacional (evidência local): uma indisponibilidade simultânea de dm.yanbraga.com, waha.yanbraga.com e n8n.yanbraga.com retornou HTTP 502, embora a resolução pública dos hostnames e o conector do Tunnel estivessem ativos. O diagnóstico reportado identificou aliases desatualizados no /etc/hosts do host após recriações de contêineres e um nome de contêiner da aplicação do DM desalinhado. Como o conector executava em rede do host e alcançava origens por esses aliases, ele não usava a descoberta DNS de uma rede Docker definida pelo usuário.

Recuperação reportada: os aliases e o nome do contêiner foram normalizados, o conector foi reiniciado de modo controlado para renovar a resolução e o dicionário de dependências do watchdog foi sincronizado. A checagem posterior reportou respostas públicas esperadas para os cinco hostnames monitorados, inclusive os três afetados. IPs internos, nomes operacionais completos de contêineres, tokens e identificadores de túnel não são registrados nesta nota.

Limite de confirmação: o lote preserva um diagnóstico e uma verificação operacional reportados, mas esta curadoria não auditou a configuração, os comandos, a telemetria ou o estado atual da VM. O registro é histórico operacional, não prova independente de disponibilidade contínua.

Procedimento preventivo

• Para cada hostname publicado, validar o mapeamento hostname → serviço de origem no dashboard/configuração do Tunnel e a resolução efetiva no ambiente onde cloudflared é executado.
• Após recriar ou renomear contêineres, revisar aliases do host e demais dependências que referenciem endereços ou nomes de origem. Não registrar no vault IPs privados, tokens ou IDs de túnel.
• Testar o hostname público e a origem local antes de encerrar um incidente; uma conexão ativa do Tunnel, isoladamente, não confirma que a origem correta esteja acessível.
• Manter o watchdog alinhado aos nomes de origem vigentes e tratar sua checagem como complemento, não substituto, dos testes de origem e HTTPS.

Incidentes adicionais — 2026-09-18

Registro operacional (evidência local reportada): após reinicialização da máquina que hospeda o serviço, foundry.yanbraga.com exibiu transitoriamente o erro Cloudflare 1033 e voltou a responder em seguida. Segundo a Cloudflare, 1033 indica que a borda não encontra uma instância cloudflared saudável para receber o tráfego; o episódio é compatível com uma janela de reconexão, mas o lote não contém logs que comprovem sua duração ou causa precisa.

No mesmo dia, indisponibilidades HTTP 502 em n8n.yanbraga.com e waha.yanbraga.com foram atribuídas, no diagnóstico reportado, a mapeamentos estáticos de nomes de origem no host que ficaram desatualizados após recriações de contêineres. O conector usava a rede do host e esses mapeamentos para alcançar serviços em uma bridge Docker; portanto, não obtinha a resolução automática por nome disponível entre contêineres da mesma rede definida pelo usuário. A recuperação reportada atualizou os mapeamentos e as dependências de monitoramento, reiniciou o conector de maneira controlada e confirmou respostas HTTPS esperadas.

Decisão operacional consolidada: não tratar endereços IP de contêiner como identificadores estáveis. Docker documenta que endereços são atribuídos dinamicamente em recriações, enquanto nomes de serviço permanecem estáveis para serviços na mesma rede Compose. Quando a topologia exigir network_mode: host, validar e automatizar a atualização de qualquer ponte de resolução host → serviço; preferir uma arquitetura que elimine esses mapeamentos estáticos quando for viável e aprovada.

Limite de confirmação: este é um registro histórico baseado no diagnóstico e na validação reportados na conversa. Não foi feita auditoria independente do estado corrente, da configuração do Docker, de /etc/hosts, do conector ou dos logs.

Incidente e ajuste reportados — 2026-09-21

Registro operacional (resposta de manutenção; não auditado independentemente): uma checagem do watchdog multissite identificou falha de origem do WAHA após recriações de contêineres. O relato atribuiu a persistência do erro a um alias do host ainda associado a um endereço interno anterior, apesar da recuperação inicial; a escalada para diagnóstico mais profundo excedeu o tempo limite e fez o cronjob terminar com erro.

Ajuste reportado: o watchdog passou a reconciliar os aliases de origem do host a partir das associações vigentes dos contêineres antes e durante a recuperação de primeiro nível. Esse mecanismo reduz a dependência de endereços efêmeros, mas continua exigindo validação dos hostnames públicos e das origens após qualquer mudança de topologia. Não registrar endereços internos, nomes completos de contêineres, comandos, tokens ou identificadores do cronjob.

Limite de confirmação: o lote contém somente a descrição da correção e não inclui releitura independente do script, de /etc/hosts, dos logs ou de um novo health check bem-sucedido. Tratar a implementação como reportada até uma verificação operacional posterior.

Fontes

• Cloudflare. Cloudflare Tunnel. Consultado em 2026-08-29.
• Cloudflare. Tunnel tokens. Consultado em 2026-08-29.
• Cloudflare. Routing. Consultado em 2026-08-30.
• Docker. Bridge network driver. Consultado em 2026-08-30.
• Cloudflare. Error 1033. Consultado em 2026-09-18.
• Docker. Networking in Compose. Consultado em 2026-09-18.
• Evidência local: verificação operacional registrada na conversa de 2026-08-29; sem tokens, IDs de túnel ou outros identificadores privados.
• Registro operacional: resposta preservada no batch batch-db61032c44164ec7a2373d8303209603, consultado em 2026-09-12; não auditada independentemente durante esta curadoria.
• Registro operacional: resposta de manutenção preservada no lote de knowledge capture de 2026-09-21; não auditada independentemente durante esta curadoria.