Cloudflare Access atualização: hostname routing e novo IP range

A Cloudflare Access atualização de agosto de 2026 marca uma virada relevante para times de infraestrutura e segurança que dependem de Zero Trust, especialmente no Brasil, onde o trabalho híbrido consolidou o acesso remoto a aplicações privadas como padrão corporativo. A Cloudflare opera uma das maiores redes de borda do planeta — mais de 300 cidades em 100+ países, respondendo por aproximadamente 1 em cada 5 requisições HTTP da internet — e o Access, peça central do portfólio Cloudflare One, substitui VPNs legadas com autenticação por identidade integrada a Okta, Google Workspace e Azure AD. Nesta atualização, três mudanças chamam atenção de administradores: disponibilidade geral do hostname routing, novo intervalo de initial resolved IPs público e impacto direto em navegadores baseados em Chromium 142. Vamos detalhar cada uma delas com foco em configuração, breaking changes e caminhos de migração.

O contexto de mercado em 2026 reforça que CDN e segurança não são mais camadas separadas. A Cloudflare compete diretamente com Akamai, Fastly e AWS CloudFront no delivery de conteúdo, mas se diferencia ao entregar SASE, WAF, DDoS e Zero Trust em uma única plataforma. Enquanto concorrentes exigem integrações complexas entre múltiplos fornecedores, o Cloudflare Access funciona como camada de autorização na borda, aplicando políticas antes que o tráfego alcance a origem. Para empresas brasileiras que precisam atender à LGPD e reduzir latência em aplicações hospedadas em São Paulo, no exterior ou em nuvens híbridas, manter o Access atualizado evita falhas silenciosas de conectividade — exatamente o tipo de problema que a mudança de IP range pode causar se não for tratada a tempo.

O anúncio vem na esteira de uma onda de lançamentos recentes da Cloudflare: o DDoS Threat Report H1 2026 apontou aumento de 519% em ataques hiper-volumétricos, o WAF recebeu nova detecção para CVE-2026-61511 (vBulletin RCE), a página de status foi reconstruída com feeds RSS separados e suporte a Markdown para agentes de IA, e o cliente Cloudflare One Client for Windows ganhou hotfix para reconexão após sleep. Nesse ecossistema em movimento rápido, a Cloudflare Access atualização se destaca por tocar diretamente roteamento de DNS, políticas de egress e aplicações privadas em portas não-HTTPS. Neste post, você vai entender o que mudou, como migrar sem downtime e por que a JRT Technology Solutions recomenda revisar sua configuração agora.

Antes de avançar, vale reforçar o histórico: o Cloudflare Access nasceu como alternativa leve à VPN, usando o modelo de identity-aware proxy. Em vez de abrir túneis amplos na rede, cada requisição a um hostname protegido é avaliada contra políticas de identidade, grupo, dispositivo e localização. A evolução para SASE adicionou Gateway, WARP, Mesh e Tunnel, e agora o hostname routing elimina a necessidade de listas estáticas de IPs para roteamento. A mudança de initial resolved IPs, porém, exige atenção: contas que ainda usam o intervalo legado CGNAT podem enfrentar bloqueios no Chrome 142+, Edge, Brave e Opera.

Cloudflare Access atualização: o que mudou em agosto de 2026

O changelog oficial da Cloudflare trouxe duas entregas estruturais para o Access e serviços correlatos de Cloudflare One. A primeira é a disponibilidade geral do hostname routing, que já existia em beta e agora está maduro para produção. A segunda é a substituição do intervalo padrão de initial resolved IPs — também chamado de token IPs — do bloco CGNAT 100.80.0.0/16 para o espaço público 172.64.128.0/20 em IPv4, mantendo 2606:4700:0cf1:4000::/64 em IPv6. Essa segunda mudança foi motivada pelas restrições de Local Network Access (LNA) do Chrome 142, que bloqueiam requisições em segundo plano para endereços CGNAT no nível do motor Chromium.

Além dessas, o ecossistema recebeu atualizações complementares: o Gateway e o Cloudflare Tunnel agora podem rotear por hostname, o Mesh ganhou atração de tráfego por hostname e o cliente Windows foi corrigido para reconectar após wake from sleep. Para segurança, o WAF bloqueia ativamente a CVE-2026-61511 do vBulletin, e o Email Security passou a aceitar regras de bloqueio por conteúdo com expressões regulares. A nova página de status, por sua vez, entrega notificações independentes da infraestrutura da Cloudflare — um alívio para quem monitora incidentes em tempo real.

A tabela abaixo resume o changelog mais relevante para quem opera Cloudflare Access e Cloudflare One no dia a dia:

Para administradores que gerenciam políticas de Access, a leitura imediata é clara: se sua conta ainda depende do intervalo legado 100.80.0.0/16, usuários em navegadores Chromium recentes podem começar a falhar de forma silenciosa em recursos que dependem dos initial resolved IPs. A boa notícia é que a Cloudflare oferece configuração via dashboard e API, e a mudança para contas novas já vem ativa por padrão. Contas existentes precisam revisar a configuração em Zero Trust > Team & Resources > Devices > Device profiles.

Hostname routing GA: o fim das listas estáticas de IP

O hostname routing é a mudança conceitualmente mais importante desta Cloudflare Access atualização. Antes, para rotear tráfego entre conectores Cloudflare Tunnel, Mesh ou Gateway, era preciso gerenciar listas estáticas de IPs e rotas — um modelo frágil quando filiais mudam de faixa, ambientes de nuvem escalam dinamicamente ou equipes adotam redes temporárias. Com o recurso em GA, você passa a rotear por hostname, muito mais próximo do modelo de identidade que o Access já defende.

Na prática, um hostname privado como wiki.internal.local pode ser roteado para uma aplicação privada atrás de um túnel específico, enquanto um hostname público como bank.example.com pode egressar por um túnel dedicado e ancorar tráfego em um nó de saída controlado. Isso elimina a necessidade de atualizar roteadores e firewalls sempre que um IP muda, e permite políticas de egress mais granulares — por exemplo, forçar que o tráfego de um domínio sensível saia por um conector em determinada região para cumprir requisitos de residência de dados.

Para o Access especificamente, o hostname routing fortalece o cenário de aplicações privadas em portas não-HTTPS, como SSH, RDP, bancos de dados e aplicações legadas que não falam TLS na porta 443. Nesses casos, a Cloudflare precisa associar a consulta DNS ao fluxo de conexão subsequente, e os initial resolved IPs são o mecanismo que faz essa mágica. Com o novo intervalo público, essa associação permanece estável mesmo diante das restrições do Chrome 142.

Vale notar que o hostname routing também se aplica ao Cloudflare Mesh, que interconecta data centers privados usando a espinha dorsal da Cloudflare. Empresas que operam ambientes híbridos — por exemplo, matriz em São Paulo e filiais no interior com links MPLS ou BGP via Network Interconnect — podem atrair tráfego de hostnames privados para um nó Mesh sem depender de propagação de rotas IP complexas. Para times de rede, isso reduz drasticamente o número de regras manuais e o risco de loops de roteamento.

Novo IP range público: entenda o breaking change do Chrome 142

A mudança de initial resolved IPs de 100.80.0.0/16 para 172.64.128.0/20 não é cosmética — é uma correção preventiva contra o Local Network Access (LNA) implementado no Chrome 142 e herdado por todos os navegadores baseados em Chromium, incluindo Microsoft Edge, Brave e Opera. O LNA bloqueia requisições em segundo plano para endereços CGNAT (100.64.0.0/10), o que antes quebrava silenciosamente recursos baseados em hostname do Access, Gateway e Mesh.

O mecanismo funciona assim: quando um usuário resolve um hostname através do WARP ou de um túnel, a Cloudflare retorna um initial resolved IP temporário que pertence à sua faixa. Esse IP é usado apenas para associar a consulta DNS à conexão de rede que vem em seguida, permitindo que políticas de egress, host selectors e aplicações privadas em portas alternativas funcionem corretamente. Se o navegador bloqueia esse IP por considerá-lo rede local, toda a cadeia de autorização é comprometida.

Com o novo intervalo público 172.64.128.0/20, o problema desaparece, pois o endereço não pertence mais ao espaço CGNAT bloqueado. O intervalo IPv6 2606:4700:0cf1:4000::/64 permanece o mesmo, pois não é afetado pela restrição do Chromium. Contas podem configurar um intervalo IPv4 customizado caso o padrão entre em conflito com a rede existente — útil para empresas que já usam 172.64.0.0/16 internamente em cenários de SD-WAN ou VPN legada.

Se você vinha usando a política empresarial LocalNetworkAccessRestrictionsTemporaryOptOut do Chrome como workaround, a recomendação oficial é abandoná-la assim que migrar para o novo intervalo. Esse workaround, embora eficaz temporariamente, enfraquece a postura de segurança ao liberar acesso a redes locais para contextos que deveriam ser restritos. A migração para o intervalo público permite remover a exceção e voltar a aplicar o LNA de forma integral, alinhando segurança e compatibilidade.

Impacto prático da Cloudflare Access atualização para administradores

Para administradores de Zero Trust, a Cloudflare Access atualização exige uma revisão proativa de três frentes: rotas por hostname, intervalo de initial resolved IPs e políticas de egress com host selectors. O primeiro passo é identificar se sua conta ainda usa o intervalo legado CGNAT. Você pode fazer isso no dashboard em Zero Trust > Team & Resources > Devices > Device profiles ou usando a API Initial Resolved IP Subnet. Contas criadas recentemente já devem estar no intervalo público, mas ambientes antigos podem estar no legado.

O segundo passo é mapear quais aplicações privadas usam portas não-HTTPS. Serviços como SSH na porta 22, RDP na 3389, MySQL na 3306 ou PostgreSQL na 5432 dependem fortemente dos initial resolved IPs para funcionar através do Access. Se esses serviços começarem a falhar apenas em navegadores Chromium atualizados, o sintoma clássico é o usuário conseguir resolver o hostname, mas a conexão ser bloqueada ou cair silenciosamente. Testar com curl ou com o cliente WARP pode ajudar a isolar o problema.

O terceiro passo é revisar as políticas de egress que usam seletores Domain, Host, Application ou Content Categories. Essas políticas dependem da associação DNS-conexão e, portanto, também são afetadas pelo intervalo antigo. Após migrar, é importante validar que relatórios do Gateway continuam classificando corretamente o tráfego e que regras de bloqueio baseadas em hostname voltam a funcionar como esperado. Em ambientes com muitas filiais, a validação pode ser automatizada com scripts que comparam o tráfego antes e depois da mudança.

A seguir, uma lista de verificação recomendada pela JRT Technology Solutions para minimizar o impacto operacional:

• Auditoria de contas: confirme se o intervalo initial resolved IPs é o novo 172.64.128.0/20 ou um customizado válido.
• Inventário de aplicações: liste todos os serviços acessados via Access em portas não-HTTPS.
• Remoção de workarounds: elimine a política LocalNetworkAccessRestrictionsTemporaryOptOut do Chrome após migrar.
• Testes em navegadores: valide Chrome, Edge, Brave e Opera nas versões mais recentes.
• Monitoramento de egress: revise logs do Gateway para detectar alterações de classificação.

Como configurar o novo initial resolved IP range no dashboard

A migração é direta e pode ser feita sem downtime, pois a Cloudflare mantém o serviço ativo durante a troca. No dashboard, navegue até Zero Trust > Team & Resources > Devices > Device profiles. Lá você verá o intervalo atual e poderá optar pelo padrão público ou inserir um intervalo IPv4 customizado, se necessário. O intervalo IPv6 2606:4700:0cf1:4000::/64 não é configurável e permanece fixo. Para quem prefere automação, a API Initial Resolved IP Subnet permite consultar e atualizar o intervalo programaticamente.

Em ambientes com Chrome Enterprise, a remoção da política temporária deve ser feita somente após confirmar que todos os endpoints já estão no novo intervalo. Recomendamos um rollout em fases: primeiro migre um grupo piloto de usuários, monitore por 48 horas e depois expanda para toda a organização. Durante esse período, mantenha o workaround LNA apenas nos grupos que ainda não migraram, para evitar janelas de indisponibilidade.

Para aplicações privadas em portas não-HTTPS, após a mudança, é fundamental testar a resolução e a conexão usando o cliente WARP atualizado. Um teste prático é executar curl -v telnet://app.internal:22 ou usar nmap para verificar se a porta responde através do túnel. Se houver falha, verifique se o hostname está corretamente roteado nas configurações de