O que é CGNAT? Por que o Port Forwarding Falha e Como Contornar Isso

Quando um Port Forward Correto Ainda Não Funciona

O seu NAS abre normalmente em casa. O serviço está em execução e a regra de port-forwarding aponta para o endereço local correto. Depois muda o seu telemóvel para dados móveis, tenta novamente e recebe um timeout. O mesmo padrão pode afetar um servidor de jogos doméstico, servidor VPN, feed CCTV ou aplicação auto-hospedada.

A resposta rápida é que a regra pode estar correta mas estar atrás de outro limite. Com Carrier-Grade NAT (CGNAT), o ISP partilha endereços IPv4 públicos e toma a primeira decisão de entrada a montante. Controla a regra no seu router doméstico, mas uma nova ligação à internet nunca a atinge a menos que o tradutor do fornecedor saiba para onde a enviar.

Isto não prova que CGNAT é responsável; problemas locais podem parecer idênticos. O serviço pode estar a escutar apenas em localhost, ou uma firewall do anfitrião pode bloqueá-lo. Uma regra do router pode usar o protocolo TCP/UDP errado ou um endereço de destino desatualizado, enquanto um segundo router local pode adicionar outro limite. Primeiro identifique o limite, distinga CGNAT de NAT ordinário e duplo NAT, depois escolha uma solução alternativa para o acesso de que necessita.

Palavras-chave rápidas: O que é CGNAT e por que os ISPs o usam

Estes termos são suficientes para seguir onde essa conexão perdida para.

RFC 6888 define um Carrier-Grade NAT (CGN)—também chamado Large-Scale NAT (LSN)—como uma função do lado do provedor que permite que múltiplos assinantes compartilhem um endereço IPv4. Os assinantes não o gerenciam. “Carrier-grade” descreve posicionamento e escala, não qualidade superior.

O limite de propriedade parece assim:

YOU CONTROL                         ISP CONTROLS
device → home router / NAT → ISP CGNAT → shared public IPv4 → internet

O router doméstico controla a rede local do cliente. O CGN do ISP mapeia conexões de assinantes para seu endereço público compartilhado. A navegação normal ainda funciona porque um dispositivo inicia a conversa e ambas as camadas de tradução podem rastrear a resposta.

Pense no endereço IPv4 público como a entrada de rua de um edifício e uma porta como um interfone. Seu router é a mesa de recepção interna. CGNAT adiciona uma mesa externa compartilhada por muitos clientes e operada pelo ISP. As portas ajudam essa mesa externa a rastrear conversas ativas; elas não dão a cada cliente propriedade permanente de cada interfone no endereço compartilhado.

Os ISPs usam este design porque o espaço IPv4 globalmente roteável é limitado e a transição para IPv6 permanece incompleta. Os pools livres regionais estão efetivamente esgotados, embora endereços existentes ainda possam ser transferidos e reutilizados. CGNAT preserva compatibilidade IPv4 compartilhando endereços escassos. IPv6 fornece o maior espaço de endereço a longo prazo, mas não está disponível de ponta a ponta em todos os lugares.

NAT vs Double NAT vs CGNAT

As questões decisivas não são “Quantas caixas vejo?” mas “Onde acontece a tradução e quem pode alterá-la?”

📝 Nota: CGNAT frequentemente resulta em duas camadas IPv4 NAT quando um router doméstico está presente, mas “CGNAT” nomeia a função operada pelo ISP enquanto “double NAT” apenas descreve a topologia.

Essa distinção de propriedade muda o que pode corrigir. Com dois gateways locais, pode ser possível usar bridge/AP mode ou configurar ambas as camadas. Um tradutor do fornecedor fica fora desses controlos, e alguns designs CGNAT não incluem um segundo tradutor operado pelo cliente.

Rótulos de consola como “open”, “moderate” ou “strict NAT” são separados. Resumem o comportamento de conectividade para essa plataforma; não identificam quem é proprietário dos tradutores nem provam que CGNAT existe.

Por que o Port Forwarding Falha Atrás de CGNAT

O tráfego de saída funciona porque cada tradutor cria estado: um registro temporário vinculando um fluxo interno a um endereço e porta externos. Quando seu dispositivo inicia uma solicitação, o roteador doméstico e o CGN do ISP registram cada um, permitindo que as respostas correspondentes retornem.

Uma nova conexão de entrada não possui tal estado. Ela atinge primeiro o IPv4 público compartilhado do ISP, onde o CGN não possui mapeamento específico do assinante:

OUTBOUND WORKS
device → home NAT [state created] → ISP CGN [state created] → internet
device ← home NAT [state match]   ← ISP CGN [state match]   ← reply

NEW INBOUND CONNECTION STOPS
outside user → shared public IPv4 → ISP CGN
                                      X — no subscriber mapping
                                      home router is never reached

É por isso que o port forwarding CGNAT falha. Sua regra de roteador doméstico pode ser válida, mas pertence à recepção interna. Alterar a lista de visitantes dessa recepção não pode informar à recepção externa compartilhada do ISP qual assinante deve receber um visitante inesperado. O pacote nunca atinge sua regra.

Um proxy reverso no lado doméstico inacessível não muda isso. Ele pode organizar solicitações após chegarem, mas não pode criar a rota ausente. Um túnel reverso—ou um proxy ou relay em uma borda acessível—é diferente porque o lado privado estabelece um caminho de saída primeiro.

Como Saber se Está Atrás de CGNAT

Use as evidências nesta ordem:

1. Desative VPNs e proxies. Desligue qualquer coisa que altere o endereço público a partir do qual o seu tráfego parece sair.
2. Identifique o gateway voltado para o ISP. Use o router ou modem diretamente conectado ao fornecedor, não um segundo router mais dentro da sua rede.
3. Compare os dois endereços. Anote o endereço WAN ou IPv4 da Internet desse gateway, depois use um serviço externo para ver o seu IPv4 público ao mesmo tempo.

❗ Importante: Uma discrepância entre os endereços WAN e públicos prova que existe um limite de tradução a montante, não automaticamente que é CGNAT. Faça esta inferência apenas a partir do gateway diretamente conectado ao ISP.

4. Interprete o resultado. Use estes sinais em conjunto:
   • Um endereço WAN em 100.64.0.0/10—100.64.0.0 até 100.127.255.255—é uma forte evidência de CGNAT. RFC 6598 reserva este Espaço de Endereço Compartilhado não globalmente roteável para uso do fornecedor; não é espaço privado RFC 1918.
   • Um endereço em 10.0.0.0/8, 172.16.0.0/12, ou 192.168.0.0/16 também mostra um WAN não público, mas pode pertencer a outro router local.
   • Endereços WAN e públicos diferentes indicam tradução a montante. Endereços globalmente roteáveis correspondentes tornam o CGNAT IPv4 ordinário muito menos provável nesse caminho.
5. Descarte causas locais. Antes de chamar de CGNAT, verifique que:
   • O serviço escuta no seu endereço LAN, não apenas em localhost.
   • A firewall do host permite a porta e protocolo pretendidos.
   • A regra do router alvo o endereço interno atual e a escolha TCP/UDP correta.
   • Um segundo router local não está adicionando outra camada de tradução.
   • O teste vem de dados móveis ou outra rede genuinamente externa.
6. Confirme com o ISP. Traceroute pode apoiar o diagnóstico quando saltos compartilhados ou privados aparecem além do gateway doméstico, mas saltos ocultos o tornam inconclusivo. Pergunte ao fornecedor se a linha usa CGNAT e se um IPv4 público dinâmico ou estático está disponível.

O Que CGNAT Afeta—e O Que Geralmente Não Afeta

Essa divisão de saída/entrada determina o que os usuários notam. Navegação, streaming, downloads e a maioria dos clientes de aplicativos geralmente funcionam normalmente. Problemas aparecem quando um sistema externo deve iniciar uma nova conexão para algo atrás do limite da operadora.

A hospedagem direta de IPv4 e o acesso remoto, portanto, precisam de outro caminho alcançável. Em uma rede privada, isso afeta o acesso a um NAS, sistema CCTV ou painel interno. Sites públicos, receptores de webhook e servidores de jogos enfrentam o mesmo requisito de entrada. Um cliente VPN normalmente funciona porque se conecta para fora. Um servidor VPN doméstico é diferente porque usuários remotos iniciam a conexão, portanto precisa de entrada alcançável, IPv6 compatível ou um endpoint em um relay ou host público.

Jogos ponto a ponto, voz e compartilhamento de arquivos são menos previsíveis. Alguns aplicativos encontram uma rota direta, enquanto outros usam um relay através de um intermediário alcançável. Um relay pode preservar a conectividade ao custo de latência adicional. Quando a travessia falha, o aplicativo pode relatar NAT restritivo ou falhar na conexão. RFC 7021 documenta esses pontos de pressão sem implicar falha universal.

Compartilhar um endereço IPv4 pode mesclar assinantes não relacionados em uma reputação. O comportamento de um usuário pode fazer com que outros assinantes vejam mais CAPTCHAs ou limites de taxa. O endereço compartilhado também pode cair em listas de bloqueio, acionar restrições de login simultâneo ou produzir geolocalização aproximada. Uma saída residencial compartilhada ou mutável complica ainda mais listas de permissão comerciais que esperam um endpoint estável.

📝 Nota: Bloquear IPv4 de entrada não solicitado por padrão pode reduzir exposição acidental, mas CGNAT não é um firewall e não substitui autenticação, atualizações, TLS ou política de acesso.

CGNAT não interrompe tráfego de saída malicioso. Não protege aplicativos expostos através de outro caminho ou controla quem pode fazer login. Um túnel, IP público ou rota IPv6 ainda exigem controles de segurança deliberados.

Cinco Formas de Contornar CGNAT

As cinco opções resolvem diferentes problemas de acesso. Malhas privadas, túneis gerenciados e relés VPS compartilham um padrão útil: o lado privado se conecta para fora primeiro.

private service → outbound mesh / tunnel link → reachable edge ← outside user

Na analogia do edifício, você obtém uma entrada de rua utilizável ou mantém uma linha para uma entrada em outro lugar.

📝 Nota: “Bypass” é uma abreviação. Estas abordagens não desativam o NAT da operadora; elas obtêm outra borda pública, usam IPv6 ponta a ponta, ou estabelecem um caminho criado por saída.

Comece com a tabela e use os detalhes abaixo para as compensações que importam para sua configuração.

1. Peça ao ISP um IPv4 Público

Para IPv4 inbound geral, esta é geralmente a opção mais simples quando o ISP a oferece. Um IPv4 público dinâmico funciona com DNS atualizado. Escolha um IPv4 público estático para listas de permissão estáveis, registos ou endpoints VPN. Verifique disponibilidade e custo, e proteja qualquer serviço que exponha diretamente.

2. Use IPv6 Nativo

O tráfego IPv6 evita CGNAT IPv4. O acesso direto requer um prefixo global, um listener IPv6, regras de firewall adequadas, DNS correto onde necessário, e IPv6 no lado remoto. Não ajuda clientes apenas IPv4 ou expõe um serviço automaticamente.

3. Construa uma Malha Privada

Uma VPN de malha como Tailscale é adequada para utilizadores e dispositivos confiáveis que podem executar software cliente autenticado. Tenta conexões diretas, depois pode recorrer a um relé de pares ou DERP com algum custo de desempenho. Não é destinado a visitantes anónimos ou webhooks públicos.

4. Publique Através de um Túnel de Saída Gerenciado

Um serviço como Cloudflare Tunnel conecta a origem para fora até uma borda do provedor. Isto funciona bem para aplicativos web, APIs, demonstrações e acesso privado controlado. Visitantes HTTP públicos podem não precisar de cliente, enquanto modos privados ou não-web podem exigir software do provedor. Suporte de protocolo, identidade, limites e disponibilidade de borda permanecem dependências do provedor.

5. Use um VPS como a Borda Pública—ou Mude a Carga de Trabalho

Um VPS pode relé tráfego através de um túnel de saída de casa, ou alojar a aplicação diretamente quando não precisa de dados ou hardware da LAN doméstica. Isto oferece um endpoint estável e controle TCP/UDP amplo. Você fica responsável pela segurança, monitorização, confiabilidade do túnel, largura de banda, tratamento de abuso e latência adicionada. Um VPS AlexHost adequadamente selecionado pode preencher este papel, sujeito à sua política de endereçamento público e rede.

Qual Opção Se Adequa ao Seu Caso de Uso?

Escolha a arquitetura fazendo quatro perguntas em ordem:

1. O acesso é limitado a pessoas e dispositivos confiáveis, ou aberto ao público?
2. Cada dispositivo de conexão pode instalar e autenticar através de software cliente?
3. O serviço é baseado em web, ou requer comportamento TCP/UDP arbitrário?
4. Você prefere conveniência gerenciada ou controle do gateway público?

Para NAS confiável, CCTV, ou acesso administrativo, use uma VPN mesh quando os usuários puderem instalar software cliente. Para endpoints web públicos e webhooks, use um túnel gerenciado ou hospedagem pública. Mova a carga de trabalho se ela não precisar da LAN doméstica.

Para TCP/UDP público, use um IPv4 público do ISP, uma borda VPS, ou IPv6 quando todos os clientes o suportarem. Hospedagem de jogos é específica do título: verifique seu modelo de servidor, suporte de traversal e protocolos. Um túnel genérico não pode garantir um rótulo NAT de console melhor.

Um endpoint VPN público precisa de IPv4 público, IPv6 funcionando, ou um host VPS. Para ingresso comercial ou listas de permissão de parceiros, escolha um endereço estático ou gateway controlado em vez de uma saída residencial compartilhada.

Perguntas e Conceitos Errados Comuns sobre CGNAT

CGNAT é o mesmo que double NAT? Não. CGNAT identifica um NAT multi-assinante operado por ISP. Double NAT significa apenas que o tráfego atravessa dois tradutores.

CGNAT sempre torna a internet mais lenta? Não. O desempenho depende mais do provedor, da aplicação e se um relay está envolvido.

Dynamic DNS pode corrigir CGNAT? Não. Rastreia um endereço em mudança, mas não pode criar um mapeamento upstream. Ajuda quando você tem um endereço público dinâmico acessível.

Uma VPN normal contorna CGNAT? Geralmente não. Funciona apenas quando o serviço VPN fornece encaminhamento de entrada, uma sobreposição privada ou outro ponto de entrada acessível.

IPv6 pode resolver? Sim, quando ambas as extremidades têm IPv6 e o firewall e DNS permitem. Não ajuda clientes apenas IPv4.

É 100.64.0.0/10 espaço privado? É espaço de uso especial, não roteável globalmente Shared Address Space. É distinto dos intervalos privados RFC 1918 usados em redes locais ordinárias.

CGNAT é um recurso de segurança? Não. Seu comportamento de entrada não é uma política de segurança. Você ainda precisa de regras de firewall, autenticação, patches, criptografia e exposição cuidadosa.

A Conclusão: Corrija a Edge Pública Ausente, Não Apenas o Router

O servidor NAS ou de jogos de abertura pode ter uma regra local correta e ainda expirar porque a conexão para no limite do ISP. Mais alterações no router não corrigirão um caminho que o router nunca recebe. Comece com o público: use uma malha para acesso privado confiável, enquanto o acesso público precisa de IPv4 público, IPv6 funcional, um túnel gerenciado ou um host controlado. Verifique as opções do ISP primeiro, depois considere um VPS AlexHost apenas quando uma carga de trabalho hospedada ou retransmissão se adequar ao design.