Como o "Null Routing" de ISPs brasileiros derrubou minha infraestrutura (e a migração para Caddy + IPv6 + HTTP/3)

Durante operações de bloqueio judicial a serviços de IPTV clandestinos, ISPs brasileiros (Vivo, Claro, Nio e Tim) aplicam Null Routing em blocos de IPs compartilhados da Cloudflare.

Serviços legítimos hospedados atrás do Cloudflare Tunnel sofrem dano colateral: o tráfego é descartado na borda da operadora, sem gerar logs na origem.

Este artigo documenta a arquitetura de saída dessa "vizinhança de risco" através de:

• Exposição direta com IPv6 nativo
• Caddy como reverse proxy na borda
• HTTP/3 com QUIC
• Hardening de TLS com classificação A+ no SSL Labs

Resultado: Latência de handshake reduzida para ~12ms em conexões subsequentes, soberania total sobre a borda da rede e eliminação de pontos únicos de falha externos.

O problema: Dano colateral em infraestrutura compartilhada

Operadoras brasileiras, ao cumprirem ordens judiciais contra transmissão ilegal de eventos esportivos via IPTV, frequentemente aplicam bloqueios por faixa de IP (Null Routing) em vez de filtragem granular por SNI ou URL.

Quando um serviço legítimo compartilha o mesmo bloco de IPs de saída da Cloudflare com um serviço de IPTV pirata, o bloqueio atinge ambos.

Sintomas Observados

• Blog inacessível em redes Vivo/Claro/Nio e Tim, durante jogos de futebol
• Ausência total de logs no servidor de origem (tráfego descartado antes de chegar)
• Resolução temporária apenas via VPN ou mudança de ISP pelo usuário final

Por que o Cloudflare Tunnel agravou o problema?

O Tunnel é excelente para:

• Bypass de CGNAT sem port forwarding
• Ocultação do IP real do servidor
• Gestão automática de TLS

Mas cria um "Single Point of Failure" queando o IP de saída do túnel entra em listas de bloqueio de ISPs. Você terceiriza a borda da sua rede e perde o controle sobre o roteamento.

A Solução: Assumindo a Borda da Rede

Decisão Arquitetural

Abandonar abstrações que mascaram a realidade do roteamento. Expor o serviço diretamente com:

• IPv6 nativo (evita conflitos de NAT e CGNAT)
• Caddy como reverse proxy na borda
• Firewall de host configurado para permitir apenas tráfego essencial

Configuração do Caddy (Caddyfile)

{
    servers {
        trusted_proxies static private_ranges
    }
}

# 1. Redirecionamento Canônico (Apenas WWW para Apex)
www.franciscomonteiro.com.br {
    redir https://franciscomonteiro.com.br{uri} permanent
}

# 2. Configuração do Domínio Principal (Borda de Produção)
franciscomonteiro.com.br {
    # Observabilidade: Logs estruturados em JSON direto no stdout do Docker.
    # Logs completos são obrigatórios para auditoria e CrowdSec.
    log {
        output stdout
        format json
    }

    # Mitigação de Exaustão de Recursos (Slowloris / Payload DDoS)
    request_body {
        max_size 100MB
    }

    # Compressão Moderna (Zstd priorizado)
    encode zstd gzip

    # Hardening de Segurança (Headers de Resposta)
    header {
        X-Frame-Options "DENY"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "strict-origin-when-cross-origin"
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        Permissions-Policy "geolocation=(), microphone=(), camera=()"
        -Server
    }

    # Reverse Proxy para o Ghost
    reverse_proxy 127.0.0.1:2368 {
        # Repasse de Identidade: CRÍTICO para o CrowdSec.
        # Garante que o Ghost veja o IP real do usuário, não o IP interno do Caddy
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-For {remote_host}
        header_up X-Forwarded-Proto {scheme}
    }
}

Hardening de Rede (Linux)

# Firewall: permitir apenas HTTP/HTTPS e SSH
ufw default deny incoming
ufw default allow outgoing
ufw allow 80/tcp    # HTTP (redirecionamento)
ufw allow 443/tcp   # HTTPS
ufw allow 443/udp   # HTTP/3 QUIC
ufw allow 22/tcp    # SSH (restrito por IP em produção)
ufw enable

# Parâmetros de kernel para otimização de QUIC/UDP
cat >> /etc/sysctl.conf <<EOF
net.core.rmem_max=25864192
net.core.wmem_max=25864192
net.ipv4.udp_mem="262144 524288 1048576"
net.ipv4.udp_rmem_min=16384
net.ipv4.udp_wmem_min=16384
EOF
sysctl -p

Resultados e Métricas

SSL Labs: Classificação A+

• Certificado: Let's Encrypt YE2 (ECDSA P-256)
• Cadeia completa com ISRG Root X2
• HSTS com preload habilitado
• TLS 1.3 obrigatório, cifras modernas apenas

HTTP/3 Check: QUIC

• Primeira conexão: Handshake completo em ~27ms
• Conexões subsequentes: Handshake em ~12ms graças a Zero Round Trip Time Resumption
• Conexão resiliente a mudanças de rede (migração entre Wi-Fi/4G sem drop)

Lições Aprendidas

1. Conveniência cobra preço em controle.
   Túneis e proxies gerenciados são excelentes para prototipagem, mas em ambientes de roteamento hostil, possuir a borda da rede é uma necessidade de resiliência.
2. IPv6 não é "futuro", é presente.
   A adoção de IPv6 nativo eliminou a dependência de soluções de contorno para CGNAT e simplificou a arquitetura de firewall.
3. HTTP/3 com QUIC entrega valor real em redes móveis.
   A capacidade de 0-RTT e migração de conexão sem drop é particularmente valiosa para usuários em 4G/5G com flutuação de sinal.
4. Monitoramento da borda é crítico.
   Após a migração, implementei logs de acesso no Caddy com exportação para sistema externo (ex: Loki/Promtail), garantindo visibilidade mesmo em cenários de bloqueio parcial.

Próximos Passos (Roadmap Técnico)

• Implementar Certificate Transparency monitoring para detecção precoce de certificados fraudulentos
• Adicionar DNS-over-HTTPS (DoH) no servidor para resolução interna segura
• Testar Multipath QUIC para resiliência em cenários de falha de link
• Automatizar deploy via Ansible/Terraform para replicação da arquitetura em outros projetos

Como Acessar Este Conteúdo de Forma Confiável

Este artigo está hospedado em infraestrutura própria com:

• TLS 1.3 + HTTP/3 (QUIC)
• IPv6 nativo
• Headers de segurança rigorosos

Verifique a integridade via:

• SSL Labs Report
• HTTP/3 Check