Cloudflare Tunnel + Zero Trust + WARP 2026: Guia Empresarial

Cloudflare · Tunnel · Zero Trust · WARP · ZTNA · Access · Gateway · PME | ✎ Duarte Spínola | 2026-06-15

O artigo Cloudflare Tunnel: Expor Serviços cobriu a instalação básica do cloudflared. Este guia empresarial (baseado na documentação oficial Cloudflare One) transforma o Tunnel numa plataforma completa de acesso remoto: ingress rules para múltiplos serviços, Cloudflare Access com políticas Zero Trust, WARP como cliente gerido, Gateway para DNS filtering e troubleshooting dos problemas mais comuns — para PMEs de 25-100 colaboradores que precisam de acesso seguro sem VPN legacy.

Conteúdos

• 1. Plataforma Unificada Cloudflare (2018-2026)
• 2. Cenários de Aplicação
• 3. Os 7 Componentes do Zero Trust
• 4. Tunnel Avançado — Ingress Rules
• 5. Cloudflare Access — Políticas Zero Trust
• 6. Cloudflare WARP — Cliente Remoto
• 7. Cloudflare Gateway — DNS Filtering
• 8. Tunnel com Docker
• 9. Troubleshooting — 8 Problemas Comuns
• 10. Free Tier e Custos PME
• 11. FAQ para Sysadmins
• 12. Boas-Práticas de Operação

1. Plataforma Unificada Cloudflare (2018-2026)

A Cloudflare começou em 2010 como CDN + DDoS protection. Em 2018 lançou o Tunnel (daemon cloudflared com ligação outbound). Em 2020 surgiu o Access (substituto Zero Trust de VPN). Em 2021, o WARP (cliente para dispositivos remotos). Em 2024-2026, unificou tudo sob a marca Cloudflare Zero Trust — uma plataforma única para acesso seguro, DNS filtering, RBI, CASB e DLP.

O Tunnel sozinho expõe apps self-hosted. O verdadeiro poder está em combinar Tunnel + Access + WARP + Gateway — substituindo VPN, DNS filtering, anti-malware e CASB por uma plataforma única gerida na cloud.

2. Cenários de Aplicação

• Developer solo — Quick tunnel *.trycloudflare.com para demos temporárias (24h, sem DNS). Custo zero.
• PME 25-50 cols — Substituir VPN legacy por Tunnel + WARP. Apps self-hosted via Tunnel, DNS filtering via WARP. Custo: 125-250€/mês (Standard).
• MSP multi-tenant — Cada cliente com tunnel + policies isoladas. ZT é pré-requisito para NIS2 (ver NIS2: Implementação 90 Dias).
• Equipa remota híbrida (50+ cols) — WARP via MDM (Intune, Jamf). Split tunneling: SaaS passa direto, tráfego corporativo por Cloudflare. Latência <50ms.
• Hospital/clinica — Tunnel para EHR, Access com MFA FIDO2, WARP para staff móvel. Audit logs 180 dias (compliance RGPD).

3. Os 7 Componentes do Zero Trust

A plataforma Cloudflare Zero Trust em 2026 tem 7 componentes integrados, configurados no Cloudflare Dashboard:

Trade-off: Cloudflare é multi-cloud (AWS, GCP, Azure, on-premises); Microsoft é Microsoft-first. Para PME 100% Microsoft, M365 E5 é natural. Para PME multi-cloud ou híbrida, Cloudflare ZT é superior.

4. Tunnel Avançado — Ingress Rules

Em produção, é preciso expor múltiplos serviços (Grafana, Zabbix, SSH, RDP) com URLs distintas — grafana.empresa.pt, ssh.empresa.pt, etc. Isto é feito via config.yml com ingress rules.

O ficheiro /etc/cloudflared/config.yml tem 3 secções principais: tunnel: (UUID), credentials-file: (path para JSON), e ingress: (lista de regras hostname → serviço). Opcionalmente warp-routing: e originRequest: para configurações avançadas.

Exemplo: 5 Serviços + Catch-all

# /etc/cloudflared/config.yml
tunnel: a1b2c3d4-e5f6-7890-abcd-ef1234567890
credentials-file: /etc/cloudflared/a1b2c3d4-e5f6-7890-abcd-ef1234567890.json

logfile: /var/log/cloudflared.log
loglevel: info
metrics: localhost:2000

ingress:
  # Grafana (porta 3000)
  - hostname: grafana.empresa.pt
    service: http://localhost:3000
    originRequest:
      connectTimeout: 30s
      keepAliveConnections: 8

  # Zabbix (porta 8080)
  - hostname: zabbix.empresa.pt
    service: http://localhost:8080

  # Aplicação custom (porta 5000)
  - hostname: app.empresa.pt
    service: http://localhost:5000

  # SSH (TCP raw via proxy-protocol)
  - hostname: ssh.empresa.pt
    service: ssh://localhost:22
    originRequest:
      proxyType: "socks"

  # RDP
  - hostname: rdp.empresa.pt
    service: rdp://localhost:3389
    originRequest:
      proxyType: "socks"
      connectTimeout: 60s

  # Catch-all (OBRIGATÓRIO — última regra)
  - service: http_status:404

Quando crias o tunnel no dashboard, a Cloudflare gera automaticamente CNAMEs para os hostnames configurados (ex: grafana.empresa.pt → a1b2c3d4.cfargotunnel.com). Após editar o config.yml, recarregar com sudo systemctl restart cloudflared.

Load Balancing

Para apps com múltiplas instâncias, o Tunnel suporta round-robin:

ingress:
  - hostname: api.empresa.pt
    service: http://10.0.1.10:5000
  - service: http://10.0.1.11:5000
  - service: http://10.0.1.12:5000

5. Cloudflare Access — Políticas Zero Trust

O Access aplica políticas de autenticação e autorização a cada app exposta via Tunnel. Em vez de “VPN dá acesso à LAN inteira”, Access dá acesso granular por app com autenticação contínua.

Setup de Self-hosted App (Grafana)

1. Dashboard → Access → Applications → Add Application → Self-hosted
2. Name: Grafana Produção | Session Duration: 24h (1h para apps sensíveis) | Application domain: grafana.empresa.pt
3. Identity Provider: Settings → Authentication → Add new → Entra ID (copiar Tenant ID + Client ID + Client Secret da App Registration no Azure)
4. Testar: Abrir https://grafana.empresa.pt → Access intercepta → redireciona para Entra ID → login + MFA → cookie de sessão → Grafana

Políticas (Allow/Block)

Exemplo de policy JSON (acesso a Grafana só para @empresa.pt, MFA obrigatório, sessão 1h, geo PT/ES/FR/BR):

{
  "name": "Developers Grafana",
  "decision": "allow",
  "include": [
    { "email_domain": ["empresa.pt"] },
    { "email": ["[email protected]", "[email protected]"] }
  ],
  "exclude": [
    { "email": ["[email protected]"] }
  ],
  "require": [ { "mfa": true } ],
  "session_duration": "1h",
  "geo": { "allowed_countries": ["PT", "ES", "FR", "BR"] }
}

Identity Providers Suportados

6. Cloudflare WARP — Cliente Remoto

O WARP é o cliente (Windows, macOS, Linux, iOS, Android) que liga dispositivos à rede Cloudflare. Substitui o cliente VPN tradicional com 3 modos:

Instalação Manual (1 dispositivo)

# Ubuntu 24.04
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 noble main" | \
  sudo tee /etc/apt/sources.list.d/cloudflared.list
sudo apt update && sudo apt install -y cloudflare-warp

# Windows: winget install --id Cloudflare.Warp
# macOS: App Store → "Cloudflare One Agent"

# Ativar e autenticar
warp-cli registration new   # abre browser para autenticar
warp-cli connect
warp-cli status             # deve mostrar "Connected"

Verificar: aceder a https://www.cloudflare.com/cdn-cgi/trace e procurar warp=on.

Setup via MDM (Intune) — 50+ dispositivos

1. Intune admin center → Devices → Configuration → Create profile → Windows 10+ → Settings catalog
2. Pesquisar “Cloudflare” → selecionar Cloudflare WARP settings: Organization = <team-id>, Mode = WARP with Zero Trust
3. Atribuir a grupo “All Windows Devices” → Force Sync

Para PME 50 cols, deployment completo demora 1-2 dias (Intune policy + device sync + WARP install).

Split Tunneling Inteligente

O Zero Trust client usa routing domains para decidir que tráfego passa por Cloudflare vs directo à internet. Por defeito, tráfego privado (10.0.0.0/8, 192.168.0.0/16) passa por WARP; tráfego público passa directo.

7. Cloudflare Gateway — DNS Filtering

O Gateway adiciona 3 camadas de segurança ao tráfego WARP: DNS filtering (bloqueia domínios maliciosos), HTTP inspection (inspeção de tráfego web com TLS decryption opcional), e RBI (browser isolation para sites não-confiantes).

HTTP Policies (com TLS decryption via root certificate instalado por MDM) permitem: bloquear upload de .exe para sites não-autorizados, bloquear Google Drive pessoal (vs Workspace empresarial), warn em sites com rating C/D. RBI executa o browser num servidor Cloudflare remoto e envia apenas o rendering visual — se o site for malicioso, o malware executa no servidor, não no dispositivo.

8. Tunnel com Docker

Em ambientes container-first, correr cloudflared em container é mais limpo que systemd.

# docker-compose.yml — cloudflared standalone
services:
  cloudflared:
    image: linuxserver/cloudflared:latest
    container_name: cloudflared
    restart: unless-stopped
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Lisbon
    volumes:
      - ./config:/config  # config.yml + creds file

Para expor containers Docker locais (ex: Grafana), partilhar a rede com network_mode: "service:grafana" — o cloudflared passa a “ver” Grafana em localhost:3000.

# docker-compose.yml — cloudflared + Grafana
services:
  cloudflared:
    image: linuxserver/cloudflared:latest
    restart: unless-stopped
    network_mode: "service:grafana"
    depends_on: [grafana]
    volumes: [./config:/config]

  grafana:
    image: grafana/grafana:latest
    restart: unless-stopped
    volumes: [grafana_data:/var/lib/grafana]

volumes:
  grafana_data:

Quick Tunnel via Docker (demo 24h)

# URL aleatória *.trycloudflare.com (expira em 24h)
docker run --rm -it --network host linuxserver/cloudflared:latest \
  tunnel --url http://host.docker.internal:3000

9. Troubleshooting — 8 Problemas Comuns

Comandos de Diagnóstico

# Status do cloudflared
sudo systemctl status cloudflared
cloudflared --version

# Ver logs em tempo real
sudo journalctl -u cloudflared -f -n 100
sudo tail -f /var/log/cloudflared.log

# Validar config.yml
cloudflared tunnel --config /etc/cloudflared/config.yml ingress validate

# Listar tunnels
cloudflared tunnel list
cloudflared tunnel info <NOME_OU_ID>

# Testar DNS e conectividade
dig grafana.empresa.pt
curl -I http://localhost:3000

# Debug verbose
cloudflared tunnel --loglevel debug

Outras Causas Comuns

• TLS mismatch em apps self-hosted: Se a app exige HTTPS upstream com cert self-signed, usar originRequest: noTLSVerify: true no config.yml.
• Gateway demasiado restritivo: Bloquear “Technology” ou “Computers/Internet” quebra apps legítimas. Começar com Malware + Phishing + C2 e adicionar Warn para outras.
• Tunnel “1033” frequente: Verificar firewall local (porta outbound 7844 QUIC / 443 HTTPS), NAT timeouts, dual-stack IPv4/IPv6. Forçar IPv4 com --originOnly.
• Access “Too many redirects”: Loop entre Access e IdP. Causa: redirect URI mal configurado na App Registration Entra. Copiar exactamente o callback URL do dashboard (case-sensitive).

10. Free Tier e Custos PME

Custo anual PME 25 cols (Standard): €1.512/ano (€126/mês) com domínio + servidor on-premises. vs €4.500/ano Zscaler ou €6.000/ano VPN legacy. ROI típico: 3-6 meses vs VPN legacy.

11. FAQ para Sysadmins

Posso usar Tunnel sem domínio próprio?
Sim, via quick tunnel (*.trycloudflare.com, 24h, aleatório). Para produção, domínio próprio (~€10/ano) é obrigatório.

Tunnel substitui VPN site-to-site?
Sim, para a maioria dos casos. A excepção é protocolos muito específicos (Kerberos, SMB v1, multicast) que não passam por tunnel — para esses, manter VPN IPsec.

WARP é obrigatório?
Não. Pode usar Tunnel + Access sem WARP (acesso via browser). WARP é necessário quando quer DNS filtering global, tráfego interno via Cloudflare, ou RBI.

Funciona com Microsoft 365 / Entra ID?
Sim, e é o caminho recomendado para PME com M365. Access integra com Entra ID via OAuth/OIDC. Criar App Registration no Azure (10 min) e copiar Client ID + Secret para Cloudflare.

Migrar de VPN IPsec sem downtime?
Sim, em 4 fases: (1) Piloto com 1-2 utilizadores; (2) Access policies para 3-5 apps, VPN como backup; (3) Roll-out WARP via MDM para 100%; (4) Sunset VPN (manter como backup 1 mês antes de remover).

Funciona com Kubernetes?
Sim, via Cloudflare Tunnel Ingress Controller (helm chart). Cria automaticamente tunnel + DNS + ingress para cada recurso Ingress K8s.

E se a Cloudflare tiver um outage?
Tunnel e WARP ficam down. Para sectores críticos, ter fallback: DNS secundário (Google 8.8.8.8 / Quad9 9.9.9.9), VPN legacy como backup, ou Cloudflare Spectrum (SLA 100%).

Funciona com Microsoft Defender for Endpoint?
Sim, complementam-se: Cloudflare ZT protege a fronteira (apps, DNS, web); MDE protege o endpoint (EDR, antimalware). Defense in depth — ZT na cloud, MDE no device.

12. Boas-Práticas de Operação

1. Versionar config.yml em Git (repo privado, credentials file encriptado). Mudanças → PR → review → apply via CI/CD.
2. Monitorizar tunnel uptime com UptimeRobot, Healthchecks.io, ou Zabbix (HTTP HEAD a cada 5 min por hostname). Alertar se down > 2 min.
3. Tagging de tunnels (env=prod, owner=ti, cost-center=42) para billing reports e inventory.
4. Renovação de tokens — Access tokens expiram (default 1 ano). Calendário para renovar 30 dias antes. Automatizar via Terraform/API.
5. Testar updates em staging — Manter tunnel de staging separado do prod para testar major versions antes de promover.
6. Documentar topologia — Diagrama com todos os tunnels, hostnames, serviços e policies. Evidência obrigatória para NIS2/ISO 27001.
7. Audit logs exportados — Configurar Logpush desde o dia 1 (S3 ou Azure Blob) para 180d + 7 anos de arquivo frio. Custo: €1-3/mês.
8. WARP auto-update — Ativar via MDM. Cloudflare lança security patches mensalmente.

Artigos Relacionados

• Cloudflare Tunnel: Expor Serviços da Rede Local para a Internet
• Zero Trust para PMEs 2026: Guia Sysadmin
• NIS2: Implementação 90 Dias — Guia Sysadmin
• Ollama + Open WebUI: Stack Avançado 2026
• Microsoft Entra MFA: Multi-Factor Authentication 2026
• VPN Serverless Self-Hosted para PME 2026
• MEO CGNAT: Verificar e Contornar 2026
• Microsoft Defender for Endpoint: Implementação PME 2026
• Phishing Moderno: Detetar e Prevenir 2026
• Grafana PME 2026: Dashboards Prometheus

← Voltar ao Índice