acesso remoto cgnat: por que o encaminhamento de portas quebrou

Encaminhamento de portas era a solução simples: abrir uma porta no roteador doméstico, mapear TCP 3389 ou uma porta customizada, e você conseguia alcançar a máquina de qualquer lugar. Hoje muitas dessas máquinas estão inacessíveis porque a operadora coloca clientes atrás de CGNAT. Se você pesquisou por "remote access cgnat" quer saber: por que o encaminhamento de portas parou de funcionar, como detectar isso e quais são as substituições práticas e operacionais que funcionam em escala.

O que é CGNAT e por que os ISPs o usam

CGNAT (Carrier-Grade NAT) é uma medida de escala adotada pelos ISPs para esticar endereços IPv4 escassos. Em vez de atribuir a cada cliente um IPv4 público único, o ISP fornece um endereço privado RFC 6598 (100.64.0.0/10) ou outro intervalo privado e compartilha um único IP público entre muitos assinantes. O ISP faz NAT no ponto de agregação — daí o termo "carrier‑grade".

Duas consequências seguem imediatamente: primeiro, dispositivos atrás de CGNAT não têm mais um IPv4 público roteável que você possa apontar. Segundo, o ISP controla os mapeamentos e políticas de NAT: ele decide quais portas são mapeadas, se conexões inbound são permitidas e quão estáveis são os mapeamentos efêmeros. Em redes móveis, a maioria dos assinantes está atrás de CGNAT; alguns ISPs de linha fixa também o usam para evitar alocar mais espaço IPv4.

Por que o encaminhamento de portas deixou de ser uma opção

• Sem IPv4 público = sem rota de entrada. Se o IP WAN do seu roteador está em 100.64.0.0/10 ou em um bloco privado como 10.x.x.x, a Internet não pode abrir uma conexão diretamente para o mapeamento de porta local.
• Double NAT e mapeamentos efêmeros. Mesmo que o CPE (roteador do cliente) suporte encaminhamento de portas, o NAT da operadora fica a montante e geralmente tem mapeamentos de porta transitórios que você não controla.
• NAT simétrico e bloqueios por política. Muitos NATs de operadora são simétricos: o mapeamento depende do destino, o que quebra estratégias de hole‑punching e torna P2P pouco confiável.
• Segurança e políticas legais da operadora. ISPs frequentemente bloqueiam conexões inbound não solicitadas para reduzir abuso e cumprir requisitos regulatórios.
• Links móveis e transitórios. Clientes celulares mudam de IP com frequência; mesmo que você tivesse um mapeamento, ele não sobreviveria a um handover de LTE ou a um reboot do modem.

Como detectar CGNAT (verificações práticas)

Antes de mudar sua arquitetura, confirme CGNAT. Estas são verificações rápidas e determinísticas que você pode executar na máquina alvo ou pedindo ao usuário.

Windows: ipconfig /all
Linux/macOS: ip addr show
Verifique o IP público: curl -s https://ifconfig.co
Verifique o WAN do roteador: veja o endereço "WAN" ou "Internet" na UI de administração do roteador
Se o roteador mostrar 100.64.x.x ou um privado 10.x/192.168.x.x enquanto curl mostrar um IP público diferente, você está atrás de CGNAT.

Outra pista útil é o traceroute: se o primeiro salto público for um dispositivo NAT do ISP com endereçamento privado ou se o traceroute mostrar um intervalo privado antes do IP público, isso é um indício. Além disso, se as regras de encaminhamento de portas que você criou no roteador não têm efeito a partir da Internet pública, CGNAT é a causa provável.

O que substituiu o encaminhamento de portas: alternativas do mundo real

Encaminhamento de portas é uma solução no roteador local. Quando o endereço público desaparece, você precisa migrar para um dos poucos modelos gerais. Cada um tem tradeoffs em confiabilidade, latência, visibilidade de segurança e custo operacional.

1. Ponto a ponto com hole punching (STUN/ICE/WebRTC): Funciona bem quando ambos os endpoints estão em NATs que permitem UDP ou têm mapeamentos previsíveis. Muitas ferramentas modernas usam ICE para tentar caminhos diretos. Prós: baixa latência quando conecta; contras: falha em NATs simétricos de operadora e exige fallback.
2. Relays / TURN / relay gerenciado: Quando o hole punching falha, o tráfego é proxyado por um relay. Relays do tipo TURN garantem conectividade ao custo de saltos e largura de banda extras. Esta é a substituição pragmática para encaminhamento de portas no mundo real porque funciona independentemente do NAT do cliente.
3. VPNs (site ou dispositivo): Uma VPN pode dar ao administrador remoto um endereço roteável dentro de uma malha (Tailscale, ZeroTier, IPsec site‑to‑site clássico). Prós: roteamento estável e controles de acesso fortes; contras: exige instalação de cliente ou hardware de gateway e pode complicar o roteamento em frotas grandes.
4. IPv6: IPv6 nativo restaura o modelo antigo porque cada dispositivo pode ter um endereço globalmente roteável. Mas os ISPs frequentemente não fornecem IPv6 de forma consistente, e operar IPv6 com segurança em escala requer postura de firewall e monitoramento diferente.
5. Túneis reversos (SSH, autossh): Simples e eficaz para poucas máquinas: o alvo abre uma conexão outbound para um servidor conhecido que você controla, criando um caminho inbound que você pode usar. Intensivo operacionalmente para frotas por causa de gerenciamento de chaves e confiabilidade em escala.

Na prática, a maioria dos produtos comerciais de acesso remoto usa uma combinação: tenta direto (STUN/UDP) primeiro e depois recorre ao relay. O caminho via relay é a única opção que substitui de forma confiável o encaminhamento de portas diante da variedade de NATs de operadora, portais cativos e links móveis que você encontrará.

O que esperar de um relay e os tradeoffs de segurança

Muitos leitores assumem que relays são magicamente criptografados end‑to‑end de modo que o operador do relay não possa ver o conteúdo da sessão. Isso não é verdade implícita para a maioria dos sistemas de remote‑desktop. O modelo técnico real geralmente é TLS com certificados por dispositivo: quando uma sessão recorre a um relay, o TLS termina no relay, de modo que o operador da infraestrutura fica em posição de acessar ou inspecionar o tráfego da sessão se assim decidir. Uma conexão P2P direta que nunca passa por um relay é end‑to‑end entre os dois endpoints, mas você não pode contar com isso em um mundo com CGNAT.

Consequência operacional: escolha um operador de relay em quem você confie, rode relays em múltiplas regiões para baixa latência e failover, e garanta que o relay ofereça logs de auditoria e controles de acesso que você possa verificar. Se uma regulamentação proíbe acesso de terceiros ao tráfego de sessão, você precisará de um relay self‑hosted sob seu controle (mais sobre isso abaixo).

Caminho recomendado pela Tenvo: relay gerenciado por padrão

Em escala, a escolha mais barata e com menos riscos é um relay gerenciado com um cliente moderno que suporte caminhos diretos e por relay. Tenvo oferece clientes nativos para Windows, macOS e Linux, um cliente em navegador em beta público, e um relay gerenciado multi‑região que você pode usar imediatamente. Pricing tiers são Free $0 / Lite $2.99/mo / Pro $7.99/mo. O relay gerenciado remove o ônus operacional de patching, renovação de certificados, failover multi‑região e custódia de chaves — tarefas que muitas equipes subestimam quando consideram "hospedagem própria" como uma opção gratuita.

Detalhe importante: Tenvo usa TLS com um certificado por dispositivo para sessões. Isso significa que conexões peer diretas são end‑to‑end entre os dois dispositivos, mas sessões que usam o relay gerenciado terão TLS terminado no relay. Para equipes que não podem aceitar que o operador do relay esteja em posição de descriptografar, self‑hosting é o único caminho correto — mas isso tem custos reais.

Para uma visão técnica mais profunda sobre conectar sem encaminhamento de portas, veja Acesso remoto sem encaminhamento de portas explicado.

Quando hospedar seu próprio relay faz sentido

Hospedar seu próprio relay só faz sentido quando um requisito escrito o obriga: uma obrigação de conformidade que proíbe infraestrutura de terceiros, uma rede isolada sem egressa para a Internet, ou uma regra de residência de dados mandatória. Se você escolher self‑hosting por conveniência ou custo percebido como "grátis", pagará em horas e risco:

• Plantões de emergência para patches e resposta a CVE do software de relay e do OS
• Emissão e renovação de certificados (letsencrypt ou PKI corporativa), e armazenamento seguro de chaves
• Alta disponibilidade e engenharia de failover multi‑região para igualar ofertas gerenciadas
• Telemetria operacional, logging e retenção para auditorias

Se seu requisito realmente exigir hospedagem própria, o guia canônico é Self-Hosted Remote Desktop: Why, How, and What Breaks, que percorre a checklist e os pontos problemáticos.

Checklist prático de migração: migrando de encaminhamento de portas para acesso confiável

• Inventário de dispositivos: identifique quais endpoints dependem de encaminhamento de portas e se estão atrás de CGNAT. Registre OS, versão do cliente e se agentes sem supervisão estão disponíveis.
• Detecte CGNAT: execute as verificações acima em dispositivos representativos. Logue exemplos para poder falar com o ISP se necessário.
• Decida o modelo de conectividade: relay gerenciado para a maioria das frotas; VPN para redes que precisam de uma malha roteada; IPv6 onde ISPs e postura de segurança permitirem.
• Implemente agentes persistentes: troque sessões efêmeras RDP/SSH por um pequeno agente persistente que inicia conexões outbound para o relay ou malha. Isso reduz o esforço de correção.
• Planeje monitoramento: adicione SLOs de disponibilidade de sessão, checagens de saúde do relay e alertas de custo de largura de banda (relays consomem egress que você deve orçar).
• Hardenize o acesso: exija MFA, atestação de dispositivo quando possível, e logs de auditoria centralizados para gravação de sessão e forense pós‑incidente.
• Teste failover e recuperação: simule quedas de relay e garanta que uma região secundária ou caminho VPN esteja disponível.

Para um passo a passo rápido sobre como colocar um agente de acesso remoto em funcionamento, veja Como configurar acesso remoto em 60 segundos. Para a mecânica subjacente de como conexões são estabelecidas, leia Como funciona o acesso remoto: uma explicação simples.

Números operacionais e algumas expectativas

Espere que tráfego via relay acrescente latência e custo de largura de banda. Um relay regional bem posicionado deve acrescentar 20–80 ms de round‑trip comparado com um salto na LAN quando os endpoints estão no mesmo continente; sessões intercontinentais serão dominadas pela geografia de qualquer forma. Largura de banda é faturável: se você rodar sessões de vídeo/gráficos pesadas, conte 1–5 Mbps como baseline para tarefas administrativas típicas; edição ou jogos em alta taxa de frames facilmente podem chegar a 20–50 Mbps. Esses números informam se uma VPN local ou uma rota IPv6 é preferível.

TL;DR: recomendação

Se você está lidando com "remote access cgnat" no mundo real, pare de planejar o encaminhamento de portas como solução confiável. Detecte CGNAT e então escolha um modelo: relay gerenciado para a maioria das equipes, VPN/malha para acesso roteado e isolamento, IPv6 quando o ISP e a postura de segurança permitirem, e hospedagem própria somente quando um requisito escrito proibir relays de terceiros. A opção de relay gerenciado reduz a carga operacional — a oferta da Tenvo é multi‑região, suporta clientes nativos e um cliente em navegador em beta público, e vem em tiers Free/Lite/Pro (Free $0 / Lite $2.99/mo / Pro $7.99/mo).

Por fim, lembre‑se do tradeoff de segurança: relays terminam TLS. Se sua política permite que um operador confiável rode relays com controles de auditoria, use a opção gerenciada. Caso contrário, planeje o orçamento e a equipe necessários para operar seus próprios relays corretamente.

Pronto para parar de correr atrás de encaminhamento de portas e obter acesso remoto confiável que lide com CGNAT? Baixe o Tenvo client e teste um caminho de relay gerenciado na sua frota: Baixe o Tenvo.