Diferenca ip publico privado

Tabela comparativa: IP público vs IP privado

RFC 1918: a origem do endereçamento privado

A RFC 1918 (Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot e E. Lear, fevereiro de 1996, "Address Allocation for Private Internets") reservou três blocos de endereços IPv4 para uso em redes privadas, sem necessidade de registro global:

A ideia central da RFC 1918 foi criar dois domínios separados: o espaço global (internet), onde endereços são únicos e roteáveis mundialmente, e o espaço privado (intranet), onde os mesmos endereços podem ser reutilizados por qualquer organização sem conflito externo. Isso aliviou o esgotamento do IPv4 por quase três décadas.

Um detalhe que causa confusão: a RFC 1918 não garante que endereços privados são "seguros" ou "inacessíveis". Ela apenas especifica que roteadores da internet não devem rotear esses prefixos. Dentro de uma rede privada, os endereços 192.168.x.x são perfeitamente visíveis para qualquer dispositivo conectado à mesma LAN.

Como o NAT conecta os dois mundos

NAT (Network Address Translation) é o mecanismo que permite que dispositivos com IP privado acessem a internet. Quando seu notebook em 192.168.1.100 acessa um servidor web, o roteador substitui o IP de origem pelo IP público da interface WAN e anota a tradução numa tabela de estado (origem privada:porta original → IP público:porta nova). Quando a resposta chega, o roteador consulta essa tabela e entrega o pacote ao dispositivo correto.

A variante mais comum é o NAT masquerade, também chamado de NAPT (Network Address and Port Translation). Vários dispositivos compartilham um único IP público usando portas diferentes para distinguir as sessões. Por exemplo: notebook usa a porta externa 50001, celular usa 50002, tablet usa 50003, todos atrás do mesmo IP público.

O NAT tem limitações concretas:

• Dificulta conexões entrantes. Para acessar um servidor em casa (câmera, Minecraft, servidor SSH), você precisa configurar port forwarding manual no roteador.
• Complica protocolos P2P e jogos online que precisam de NAT aberto, como alguns títulos de PlayStation e Xbox.
• Cria estado que consome memória e CPU no roteador. Em roteadores domésticos com tabelas NAT saturadas, a latência aumenta.
• Dificulta rastreabilidade jurídica: um único IP público pode corresponder a dezenas de conexões diferentes ao mesmo tempo.

CGNAT: a terceira camada no Brasil

CGNAT (Carrier-Grade NAT) vai além do NAT doméstico. O provedor coloca um NAT entre os roteadores dos clientes e o pool de IPs públicos, compartilhando um único IP público entre dezenas ou centenas de assinantes simultaneamente.

O espaço de endereços intermediário no CGNAT é a faixa 100.64.0.0/10, definida pela RFC 6598 (2012, "IANA-Reserved IPv4 Prefix for Shared Address Space") especificamente para esse propósito. Essa faixa é distinta dos endereços privados RFC 1918 para evitar conflitos quando a rede do provedor e a rede do cliente usam o mesmo espaço de endereçamento.

O impacto prático do CGNAT no Brasil:

• Impossibilidade de hospedar serviços em casa sem VPS externo ou túnel reverso (como ngrok ou Cloudflare Tunnel).
• NAT duplo que dificulta jogos online com requisito de NAT aberto.
• Dificuldade para VPNs baseadas em UDP que precisam de IP fixo para o endpoint.
• Necessidade de incluir porta de origem nos logs de conexão para identificação judicial de usuários específicos.

IP fixo vs dinâmico

Independentemente de ser público ou privado, um endereço IP pode ser fixo (sempre o mesmo) ou dinâmico (muda a cada reconexão ou periodicamente). Os conceitos são ortogonais:

Provedores brasileiros como Vivo, Claro e TIM oferecem IP público fixo como adicional pago nos planos de empresa e, em alguns casos, em planos residenciais. A Anatel não obriga ISPs a oferecer IP fixo em planos básicos residenciais. Para usuários em CGNAT que precisam de acesso remoto sem IP fixo, soluções como DNS dinâmico (DDNS) com serviços como No-IP ou DuckDNS resolvem parcialmente o problema para IP dinâmico público, mas não funcionam com CGNAT.

NAT como barreira: o que protege e o que não protege

O NAT cria proteção implícita contra conexões entrantes não solicitadas. Sem port forwarding configurado, não existe como um atacante externo iniciar uma conexão direta com um dispositivo atrás de NAT. O roteador descarta pacotes entrantes que não correspondem a nenhuma sessão existente na tabela de estado.

Mas o NAT não é um firewall e não protege contra vários vetores de ataque reais:

• Malware que inicia conexões de dentro para fora. Uma vez instalado num dispositivo da rede interna, o malware usa o NAT normal (conexão de saída) para se comunicar com o servidor de comando. O NAT não bloqueia isso.
• Ataques via web e e-mail. Phishing, downloads maliciosos e exploits de browser não precisam de conexão entrante. Chegam como tráfego de resposta a uma requisição feita pelo próprio dispositivo.
• Vulnerabilidades no próprio roteador. Se o firmware do roteador tem falha, o atacante pode comprometer o gateway e a partir dele acessar qualquer dispositivo da rede interna sem precisar de port forwarding.
• UPnP mal configurado. Muitos roteadores domésticos têm UPnP ativo por padrão, permitindo que qualquer software da rede interna solicite abertura de portas automaticamente, sem confirmação do usuário.

Marco Civil e logs em CGNAT

O artigo 13 da Lei 12.965/2014 (Marco Civil da Internet) obriga provedores de acesso à internet a manter registros de conexão sob sigilo por um ano. O registro deve identificar a conexão de cada usuário: data, hora, duração e endereço IP usado.

Em ambientes com CGNAT, o IP público por si só não identifica o usuário: dezenas de assinantes compartilham o mesmo endereço ao mesmo tempo. Para que o log seja útil em investigações judiciais, o provedor precisa registrar também a porta de origem usada pelo assinante específico. Sem a porta, é matematicamente impossível distinguir qual dos centenas de usuários atrás do mesmo IP fez uma conexão específica.

Esse requisito técnico gerou tensão no setor. Provedores precisam armazenar volumes muito maiores de dados de log quando operam CGNAT: em vez de um registro por IP por sessão, precisam registrar IP público + porta de origem + IP CGNAT do roteador do cliente + timestamp. O CGI.br publicou recomendações técnicas detalhando como implementar logs de CGNAT compatíveis com o Marco Civil.

Sob o CGNAT, a identificação de um usuário em investigações segue um processo em dois passos: primeiro o provedor identifica qual assinante estava usando o IP CGNAT naquele momento (via o IP na faixa 100.64.0.0/10 e a porta), depois cruza com o cadastro do contrato. Sem o log de porta, o segundo passo é impossível, e provedores respondem a intimações judiciais informando a impossibilidade de identificação.

IP privado em IPv6

No IPv6, o conceito de endereços privados é diferente do IPv4. Como o espaço de 128 bits é praticamente ilimitado, não há necessidade de reutilizar endereços entre redes: cada dispositivo recebe um endereço global único. A RFC 1918 não se aplica ao IPv6.

O que existe em IPv6 são endereços link-local (fe80::/10), usados apenas para comunicação dentro do mesmo segmento de rede (equivalentes funcionalmente aos endereços APIPA do IPv4, na faixa 169.254.0.0/16). Endereços link-local não são roteáveis e são gerados automaticamente pelo sistema operacional para cada interface.

Existe também a faixa de endereços locais únicos (ULA, fc00::/7, definida pela RFC 4193), que cumpre papel similar ao RFC 1918 do IPv4: endereços roteáveis dentro de uma organização mas não anunciáveis na internet global. Os prefixos ULA mais comuns começam com fd, seguido de um identificador aleatório de 40 bits.

Perguntas frequentes sobre IP público e privado