Por que escolhi Cloudflare Tunnel em vez de abrir portas no firewall

Essa foi uma das primeiras decisões de arquitetura que tomei ao migrar meu blog para infraestrutura própria. Em vez de abrir portas no roteador e expor diretamente o servidor na internet, optei por usar Cloudflare Tunnel como camada de publicação segura entre o meu ambiente local e a internet.

A decisão pode parecer exagerada para um blog pessoal, mas faz ainda mais sentido em cenários comuns hoje em dia: CGNAT, IPv4 privado, IPv6 parcial e preocupação com segurança.

O problema de expor serviços em casa

Tradicionalmente, para publicar um site hospedado em casa, o caminho era:

1. Criar redirecionamento de portas (80/443) no roteador.
2. Apontar o domínio para o IP público da conexão.
3. Expor o servidor diretamente à internet.

Isso ainda funciona em muitos cenários, mas hoje existem alguns obstáculos bem comuns:

1. CGNAT (Carrier-Grade NAT)

Muitos provedores entregam conexões atrás de CGNAT. Na prática, você não recebe um IPv4 público diretamente na sua casa. Isso impede redirecionamentos de porta tradicionais sem contratar IP fixo ou pedir saída do CGNAT.

2. Segurança

Abrir portas significa que seu servidor fica acessível diretamente da internet. Isso aumenta a superfície de ataque:

• scanners automáticos encontram a porta aberta em minutos,
• bots tentam força bruta em SSH e painéis web,
• qualquer falha no serviço exposto pode virar um problema sério.

3. Complexidade com IPv6

Mesmo quando existe IPv6 disponível, muita gente ainda mantém a rede local apenas com IPv4 privado. Configurar publicação dual-stack corretamente exige mais cuidado com firewall, DNS e exposição direta dos hosts.

A ideia do Cloudflare Tunnel

O Cloudflare Tunnel muda completamente o modelo.

Em vez de a internet entrar na sua rede, é o seu servidor que cria uma conexão de saída segura para a Cloudflare.

A arquitetura fica assim: Internet → Cloudflare → Tunnel → Servidor local Ou, no meu caso: www.paulomazoni.eti.br → Cloudflare → cloudflared → Ghost no LXC Debian

O que isso resolve na prática

✔ Funciona mesmo atrás de CGNAT

Como a conexão é iniciada de dentro para fora, não importa se sua operadora usa CGNAT. Não precisei abrir portas nem contratar IP público.

✔ Não precisei expor 80/443

Meu roteador continua sem portas HTTP/HTTPS abertas para a internet. Isso reduz bastante a superfície de ataque do ambiente doméstico.

✔ HTTPS automático

A Cloudflare entrega o certificado TLS na borda automaticamente. O tráfego do visitante chega em HTTPS sem eu precisar configurar Let’s Encrypt no servidor local.

✔ IPv6 sem dor de cabeça

Mesmo mantendo minha rede local apenas com IPv4 privado (10.44.40.0/24), o site fica acessível por clientes IPv6 normalmente, porque quem fala com o visitante é a infraestrutura global da Cloudflare.

✔ Camada extra de proteção

Além do túnel em si, ainda ganho recursos úteis da Cloudflare:

• WAF (Web Application Firewall),
• proteção contra DDoS,
• rate limiting,
• logs e analytics básicos,
• cache opcional para conteúdo estático.

Minha implementação

O ambiente ficou assim:

• Hardware: Lenovo ThinkCentre i3-8100T
• Hypervisor: Proxmox VE
• Container: LXC Debian 12
• Aplicação: Ghost CMS em Docker
• Publicação: Cloudflare Tunnel (cloudflared como serviço systemd)
• Rede local: IPv4 privado fixo (10.44.40.55/24)

No Cloudflare, publiquei dois hostnames apontando para o serviço local do Ghost:

• www.paulomazoni.eti.br → http://127.0.0.1:2368
• paulomazoni.eti.br → http://127.0.0.1:2368

Assim, tanto o domínio raiz quanto o www funcionam sem qualquer redirecionamento no roteador.

Mas isso substitui um firewall?

Não. O Tunnel não elimina a necessidade de boas práticas locais. Eu ainda mantenho:

• SSH apenas na rede interna,
• serviços sensíveis não publicados,
• atualizações frequentes do Debian e Docker,
• containers separados por função,
• backups do Ghost e do banco MySQL.

O Tunnel reduz a exposição, mas não transforma um servidor mal configurado em algo seguro por mágica.

Vale a pena para um laboratório pessoal?

Na minha opinião, sim — especialmente para quem já trabalha com infraestrutura, redes ou telecom.

Além de resolver o problema prático de publicação, o Cloudflare Tunnel permite montar ambientes domésticos com uma arquitetura muito próxima do que vemos em produção moderna:

• serviços privados publicados por edge segura,
• zero trust como modelo de acesso,
• separação entre origem e borda,
• menor dependência de IPv4 público.

E, honestamente, é muito confortável publicar um serviço sem precisar lembrar se abriu porta, se o IP mudou ou se o CGNAT resolveu te sabotar naquele dia 😄

Conclusão

Escolher o Cloudflare Tunnel para hospedar meu blog não foi só uma questão de conveniência. Foi uma decisão de arquitetura:

• menos exposição direta,
• compatibilidade com CGNAT,
• HTTPS simplificado,
• acesso IPv6 transparente,
• e uma camada extra de segurança entre a internet e o meu laboratório local.

Para um ambiente pessoal de infraestrutura e testes como o Alyxie Labs, esse modelo faz bastante sentido — e provavelmente será o padrão que vou continuar usando nos próximos serviços que publicar daqui pra frente.