Agora finalmente entendi os túneis do Cloudflare Zero Trust

• Explicação da arquitetura que usa Cloudflare Zero Trust e WARP para conectar redes privadas e controlar o acesso a serviços sem problemas de NAT ou firewall
• Com os túneis Argo, é possível expor uma rede privada ou um serviço local em um domínio público, ou montar uma rede privada acessível apenas quando houver conexão via WARP
• O Tailscale é rápido por ser baseado em P2P, mas tem limitações em ambientes com NAT; já a Cloudflare roteia todo o tráfego pela rede de borda, oferecendo conexão estável
• O cloudflared cuida da criação dos túneis, e o WARP Client é responsável pela conexão de rede e pela aplicação das políticas; o fluxo de tráfego e o controle de acesso são definidos com Tunnels, Routes e Targets
• É possível configurar Access Policies detalhadas com login por e-mail ou GitHub, criando um ambiente de rede seguro que pula ou restringe o processo de login dependendo de a conexão WARP estar ativa ou não

---

Visão geral do Cloudflare Zero Trust e do WARP

• O aprendizado de Cloudflare Zero Trust + WARP começou depois que o Tailscale falhou em atravessar NAT
• Com túneis Zero Trust, é possível conectar redes privadas, publicar serviços, montar redes com IP privado e expor temporariamente serviços locais, entre outras possibilidades
• Todo o tráfego é entregue pela rede da Cloudflare sem problemas de NAT, e políticas de acesso granulares permitem controlar o acesso entre usuários, bots e servidores
• Em conexões SSH, há suporte a login baseado em autenticação Zero Trust sem precisar abrir portas públicas

Cloudflare Zero Trust vs Tailscale

• O Tailscale tenta estabelecer conexões P2P contornando NAT e firewall; quando isso não é possível, usa um servidor de retransmissão
• Na Cloudflare, com exceção de conexões Warp-to-Warp, todo o tráfego passa pelos servidores de borda da Cloudflare, eliminando problemas de NAT ao custo de um pequeno aumento de latência

Diferença entre cloudflared e WARP

• WARP Client: ferramenta que conecta o cliente à rede da Cloudflare e aplica políticas
  • Normalmente roda no cliente, mas também pode ser usado em servidores
  • Suporta conexão P2P com roteamento Warp-to-Warp
• cloudflared: ferramenta que cria túneis e os adiciona à rede Zero Trust
  • Roda no servidor para fornecer um ponto de entrada para a rede
  • Pode se conectar a outros recursos Zero Trust com o comando cloudflared access
  • Permite criar túneis temporários para testes pontuais

Estrutura de Tunnels, Routes e Targets

• Tunnels: pontos de saída de tráfego implantados com cloudflared
  • Exemplo: instalação em um equipamento sempre ligado dentro da rede doméstica (192.168.1.1/24)
  • O arquivo de configuração (/etc/cloudflared/config.yml) define para onde rotear quando uma requisição chega
  • Exemplo: gitlab.widgetcorp.tech → localhost:80, gitlab-ssh → localhost:22
• Exemplo de exposição pública:
  • homeassistant.mydomain.com → roteado para 192.168.1.3
  • Se no DNS da Cloudflare o CNAME apontar para o endereço do túnel, o acesso funciona mesmo sem WARP
• Routes: definem para qual túnel enviar um intervalo específico de IPs
  • Exemplo: a rede inteira 192.168.1.1/24 ou um IP único 192.168.1.3/32
  • Ao conectar via WARP, requisições para esses IPs são enviadas pela rede da Cloudflare até o túnel
  • Também é possível rotear IPs virtuais inexistentes, como 10.128.1.1
• Targets: definem as unidades de infraestrutura a serem protegidas
  • Exemplo: homeassistant.mydomain.com → 192.168.1.3/32
  • É possível atribuir políticas de acesso ao destino para permitir acesso apenas a usuários específicos

Access Policies: controle de acesso

• Depois de configurar túneis, rotas e alvos, as permissões são definidas com Access Policy
• Componentes da política
  • Include: condição para permitir acesso (OR)
  • Require: condição que deve ser obrigatoriamente atendida (AND)
  • Action: Allow / Deny / Bypass / Service Auth
• Exemplo 1 – controle de acesso baseado em e-mail
  • Permitir acesso apenas para endereços de e-mail específicos
  • Também é possível restringir a autenticação ao login via GitHub
• Exemplo 2 – pular login quando houver conexão WARP
  • Usando o seletor Gateway, é possível pular a tela de login quando há conexão Zero Trust via WARP
  • Sem conexão WARP, o login via GitHub é exigido

Implantação e registro do cliente WARP

• Em Settings → Warp Client, é possível definir a política de registro
  • Permitir autenticação via GitHub e registro apenas para determinados e-mails
  • Ao configurar um ID de autenticação do WARP, o seletor Gateway pode ser usado
• Em Profile Settings, define-se o comportamento do cliente
  • É possível configurar protocolo (MASQUE/WireGuard), modo de serviço, IPs excluídos do roteamento e mais
  • Também dá para ativar instalação automática da CA da Cloudflare, atribuição de um IP CGNAT exclusivo e verificação de estado do dispositivo (Device Posture)
• Após o login no cliente WARP, a conexão com a rede Zero Trust fica concluída
  • A partir daí, requisições para 192.168.1.3 são roteadas pelo túnel

Resumo do resultado da implementação

• Registro do cliente WARP com política de login baseada em GitHub e e-mail
• Um túnel dentro da rede privada encaminha requisições para homeassistant.mydomain.com até 192.168.1.3
• O tráfego para 192.168.1.3 só pode ser acessado pelo túnel quando há conexão WARP
• São oferecidas duas formas de acesso: pública via DNS e privada via WARP
• Com WARP conectado, o login é pulado; sem conexão, é exigida autenticação via GitHub

Itens não abordados adicionalmente

• Roteamento Warp-to-Warp
• Criação de IP privado exclusivo para uso interno no Zero Trust
• Configuração de política de autenticação SSH
• Tipos de aplicação além de Self-Hosted

Não há informações adicionais no texto original

[GN⁺]

Opiniões no Hacker News

• A Cloudflare opera como ponto de terminação TLS, então é desvantajosa para uso pessoal
  Com o Tailscale Funnel, o certificado é instalado diretamente no meu endpoint, mas a Cloudflare descriptografa o tráfego no meio do caminho e o criptografa novamente
  Não sei exatamente qual é o nível de privacidade da rede pessoal do WARP, mas acho que há uma grande perda de privacidade ao tunelar tráfego da internet
  Além disso, uma arquitetura de conexão P2P + fallback por relay funciona sem intermediação de terceiros, o que me parece muito mais desejável

  • Recentemente criei eu mesmo um projeto chamado TunnelBuddy
    A estrutura usa a máquina de um amigo como exit node baseada em WebRTC, com suporte apenas a P2P, sem servidor TURN/relay
    A taxa de sucesso da conexão é baixa dependendo do ambiente NAT, mas como o tráfego não passa por servidores de terceiros, a garantia de privacidade é clara
  • É irônico chamar isso de “Zero Trust” quando, no fim, você precisa confiar totalmente na Cloudflare
  • Pessoalmente confio mais no Tailscale, mas os recursos de domínio personalizado e acesso sem cliente da Cloudflare são atraentes
    Dá para montar algo parecido com Caddy, mas ainda é necessário fazer port forwarding
  • O NetFoundry da lista awesome-tunneling também é uma boa alternativa
    As vantagens são a criptografia de ponta a ponta e desempenho e confiabilidade garantidos por mais de 100 PoPs
  • O connet busca uma arquitetura de P2P + fallback por relay
    Como só os peers participantes expõem endpoints, ele leva vantagem em segurança e privacidade
    Dá para fazer self-host ou usar o serviço oficial

• Eu uso Netbird em casa e para uso pessoal
  Instalei no Synology NAS, em todos os notebooks, desktops e celulares da família, e é prático de usar como se fosse um desktop remoto em um ambiente Tmux

• Parei de ler na frase “todo o tráfego passa pela rede da Cloudflare”
  O Hyprspace conseguiu atravessar todos os NATs que encontrei e funciona bem sem infraestrutura de big tech

• O texto parece mesmo um excelente guia de configuração
  A Cloudflare poderia documentar isso e usar como guia oficial

• Li um texto de alguém que resolveu aprender Cloudflare Zero Trust + Warp porque estava frustrado quando o Tailscale não conseguia estabelecer conexão P2P em ambientes NAT
  Mas a Cloudflare nem tenta P2P desde o início, então no fim é uma migração para o modelo de confiança da Cloudflare
  É difícil entender a motivação, mas o texto em si está bem organizado

  • A Cloudflare tem uma rede global de PoPs de alta qualidade, então na prática a qualidade foi melhor do que P2P
    Nossa empresa também é totalmente remota, e o desempenho melhorou depois que migramos de Tailscale para Cloudflare
  • O ponto principal é saber se a criptografia entre peers continua sendo mantida mesmo ao passar pela Cloudflare
    Se sim, a diferença no modelo de confiança não é tão grande, mas a Cloudflare leva vantagem em velocidade porque seu forte é o desempenho de relay
    Ainda assim, a capacidade de NAT hole punching do Tailscale é excelente, então prefiro conexão direta sempre que possível

• Estou usando tuns.sh para expor serviços pessoais
  Gosto do fato de ser baseado em túnel SSH e poder ser usado imediatamente, sem instalação

• Tanto o texto quanto os comentários foram úteis
  Só que as imagens do corpo do texto estão quebradas e retornam erro 404 — por exemplo: targets-config-screen.png

• Fico feliz em finalmente ver críticas ao grande problema da CF
  Acho que precisamos de discussões que apontem os problemas do modelo Zero Trust

• O fato de não ser possível operar um servidor Plex com uma conta gratuita da Cloudflare é fatal
  Os termos relevantes podem ser vistos aqui

  • Seu ISP por acaso fornece IPv6?
    Eu uso Emby e Jellyfin baseados em IPv6 com amigos sem problemas
  • Quem esperaria que alguém fornecesse tráfego de streaming de vídeo de graça?
    Diferente de tráfego web simples, um único filme gera custos de largura de banda centenas de vezes maiores
  • Na minha conta gratuita, o cloudflared tunnel funciona bem com Jellyfin
    Esse método foi útil porque não dava para instalar Tailscale no notebook de trabalho da minha namorada
  • Na prática, se o tráfego não for alto, os termos não são aplicados de forma rígida
  • Eu também uso com Jellyfin e já está funcionando sem problemas há alguns meses

• Existe a dúvida se usar Cloudflare não seria vendor lock-in
  Acho que pelo menos o Tailscale não tem esse tipo de dependência

  • Mas me surpreendi ao descobrir que o Tailscale também era, no fim, um fornecedor comercial
    Eu achava que era um projeto open source, mas não era