Planeamento de endereços IP para redes virtuais Azure

Este artigo aborda o planeamento de endereços IP privados e públicos para implementações do Azure. Aprende-se a alocar espaço de endereçamento, evitar intervalos sobrepostos, escolher o tipo certo de IP público e avaliar o suporte IPv6 dual-stack.

O que este artigo aborda

Este artigo aborda estratégias de alocação de endereços privados, tipos e SKUs de IP públicos, o planeamento do CIDR para evitar intervalos sobrepostos, considerações de dual-stack IPv6 e o Gestor de Endereços IP (IPAM) para ambientes de grande escala.

Quem precisa deste artigo

Leia este artigo se:

  • Estão a implementar uma rede virtual (VNet) no Azure e precisam de decidir que intervalos de endereços IP usar.
  • Estão a ligar redes Azure a ambientes locais e precisam de evitar conflitos de endereços.
  • Precisa de escolher entre IPs Públicos Padrão, Prefixos de IP Públicos ou trazer os seus próprios intervalos de IP (BYOIP).
  • Quero perceber quando o dual-stack IPv6 é apropriado para as tuas cargas de trabalho.
  • Estão a gerir um ambiente grande ou em crescimento e precisam de uma estratégia para acompanhar as alocações de IP em larga escala.

Foco em levantar e deslocar: Escolha intervalos privados que não se sobreponham à sua rede local para que o encaminhamento VPN ou ExpressRoute funcione sem tradução. Reserva um grande bloco de zona de aterragem com espaço para as cargas de trabalho que vais migrar nos próximos anos.

Modernizar o foco: Planeie espaços de endereçamento não sobrepostos entre as suas regiões primárias e de backup para que as cargas de trabalho ativas-ativas possam fazer peering mais tarde, e reserve sub-redes de tamanho adequado para Ambiente do Serviço de Aplicações e AKS.

Foco multicloud: Crie um plano global de endereçamento que não entre em conflito com os intervalos CIDR existentes das VPC da AWS nem com os da Google Cloud, o que é obrigatório antes de ligar as clouds através de VPN ou interligação.

Serviços e funcionalidades do Azure

Os seguintes serviços e funcionalidades suportam o planeamento de endereços IP no Azure:

Serviço ou Característica O que oferece Quando usar
Espaços de endereços privados RFC 1918 Três intervalos reservados para uso privado: 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16. Os VNets do Azure utilizam estes intervalos para comunicação interna. Sempre: cada VNet requer pelo menos um intervalo de endereços privados destes espaços.
Espaço de endereçamento partilhado RFC 6598 100.64.0.0/10: tratado como espaço de endereçamento privado no Azure. Originalmente concebido para ambientes de NAT de classe de operadora (CGNAT). Quando a sua organização já utiliza os campos RFC 6598 nas instalações, ou quando o espaço do RFC 1918 está esgotado.
IP Pública Padrão Um endereço IP público estático com redundância entre zonas atribuído a um único recurso. Seguro por predefinição, com o tráfego de entrada bloqueado. Quando um recurso precisa de um endpoint público único, como um balanceador de carga, gateway VPN ou máquina virtual pública.
Prefixo de IP público Um bloco contíguo reservado de endereços IP públicos de uma região específica do Azure. Quando precisar de intervalos de IP previsíveis para o NAT Gateway, os Conjuntos de Dimensionamento de Máquinas Virtuais ou recursos externos, adicione-os a uma lista aprovada.
BYOIP / Prefixo IP Personalizado Traga os seus próprios intervalos de IP públicos para o Azure. Utiliza um processo em três fases: validar a propriedade, provisionar o prefixo e depois comissioná-lo para uso. Quando for necessário preservar a reputação IP existente, manter entradas em listas de permissões externas ou migrar cargas de trabalho sem alterar IPs públicos.
Azure Virtual Network Manager IPAM Uma funcionalidade integrada de Gestão de Endereços IP no Azure Virtual Network Manager. Geralmente disponível na maioria das regiões. Proporciona visibilidade centralizada e controlo das alocações em todas as subscrições. Ao gerir muitos VNets em múltiplas subscrições, é necessário um rastreio automático da utilização de endereços. Ver Gestão centralizada de rede.

Como escolher

Utilize as seguintes tabelas de decisão para orientar as suas decisões de planeamento de propriedade intelectual.

Melhores práticas de planeamento de PI

Practice Porquê Example
Alocar um CIDR pai grande (/16) e subdividir Evita o esgotamento de endereços à medida que as cargas de trabalho aumentam. É mais fácil resumir as rotas. Atribuir 10.1.0.0/16 ao ambiente de produção e, em seguida, subdividir em sub-redes /24 para cada camada de carga de trabalho.
Deixe pelo menos 30% de margem em cada sub-rede Serviços de escalabilidade como Conjuntos de Dimensionamento de Máquinas Virtuais, AKS e Ambientes de Serviços de Aplicações consomem IPs rapidamente durante a escalabilidade. Uma sub-rede /24 fornece 251 IPs utilizáveis. Se a tua implementação de base usar 100, tens margem para triplicar.
Use blocos CIDR contíguos para cada ambiente Simplifica a sumarização de rotas e as regras do firewall. Uma única rota resumida representa todo o ambiente. Produção: 10.1.0.0/16. Estágio: 10.2.0.0/16. Desenvolvimento: 10.3.0.0/16.
Evite intervalos reservados na plataforma Azure e proibidos O uso de intervalos reservados causa falhas de roteamento e erros de implantação. Não atribui 169.254.0.0/16, 168.63.129.16/32, 224.0.0.0/4, 127.0.0.0/8, ou 255.255.255.255/32.
Alocações de documentos no Azure IPAM ou numa folha de cálculo Previne sobreposições à medida que o ambiente cresce. Centraliza a visibilidade das equipas de rede. Use o Azure Virtual Network Manager IPAM para rastreamento automatizado, ou mantenha uma folha de cálculo partilhada para ambientes mais pequenos.

Diagrama que mostra como um espaço de endereçamento VNet é dividido em sub-redes dimensionadas para níveis de carga de trabalho e serviços dedicados de plataforma, como gateway, firewall e Bastion.

Tipos de endereços IP públicos

Tipo O que é Quando usar
IP Pública Padrão Um IP público estático atribuído individualmente. Com redundância entre zonas por defeito em regiões com suporte para zonas de disponibilidade. Seguro por predefinição: todo o tráfego de entrada é bloqueado até que uma regra de NSG ou do balanceador de carga o permita. Balanceadores de carga acessíveis publicamente, gateways VPN, Azure Bastion, gateways de aplicações ou qualquer recurso que necessite de um endpoint público exclusivo.
Prefixo de IP público Um bloco contíguo reservado de IPs públicos de uma região específica. Garante endereços sequenciais. NAT Gateway (requer prefixo para múltiplos IPs de saída), Conjuntos de Dimensionamento de Máquinas Virtuais, ou quando sistemas externos precisam de adicionar a uma lista aprovada um intervalo previsível de IPs.
BYOIP / Prefixo IP Personalizado Os intervalos de IP públicos pertencentes ao cliente são integrados no Azure através de um processo em três fases: validação, aprovisionamento e entrada em funcionamento. Prefixos regionais são comissionados em aproximadamente 30 minutos; Os prefixos globais demoram 3–4 horas. Preservar a reputação do IP durante a migração para a cloud, manter entradas de listas aprovadas externas ou cumprir os requisitos regulamentares para a posse da IP. IPs derivados de um Prefixo IP Personalizado também podem usar a Proteção DDoS do Azure.

Note

As IPs públicas básicas dos SKU foram retiradas a 30 de setembro de 2025. Os IPs Básicos existentes continuam a funcionar, mas não têm suporte e não têm SLA. Atualize para o SKU Standard para todas as novas implementações.

Decisão IPv6

Scenario Recommendation Fundamentação
A carga de trabalho serve apenas clientes IPv4, sem exigência regulatória de IPv6 Apenas IPv4 Configuração mais simples. Evita a sobrecarga de gestão dual-stack. A maioria dos serviços do Azure suporta IPv4 de forma nativa.
A carga de trabalho deve servir clientes IPv6, ou as regulamentações exigem suporte IPv6 Dual-stack (IPv4 + IPv6) Os VNets do Azure suportam subredes de pilha dupla. Implemente IPv6 juntamente com IPv4 nos mesmos recursos.
A carga de trabalho precisa de IPv6 mas depende do Azure Firewall, WAN Virtual ou Route Server Apenas IPv4 (com terminação IPv6 externa) Azure Firewall, WAN Virtual e Route Server atualmente não suportam IPv6. Terminar o IPv6 num balanceador de carga externo ou dispositivo de borda antes de o tráfego entrar nestes serviços. Gateway de VPN IPv6 está disponível em pré-visualização.

IPv6 dual-stack in Azure

O Azure suporta implementações IPv6 dual-stack em redes virtuais. Quando ativas o dual-stack, cada sub-rede recebe tanto um intervalo IPv4 como um intervalo IPv6 /64. Os recursos recebem endereços de ambas as famílias de endereços e podem comunicar em simultâneo através de ambos os protocolos.

O IPv6 no Azure tem requisitos específicos de dimensionamento. As subredes IPv6 devem ser exatamente /64. Não é suportado nenhum outro comprimento de prefixo. O espaço de endereçamento IPv6 que atribui a uma VNet deve ser suficientemente grande para acomodar sub-redes /64 para cada sub-rede que necessite de conectividade IPv6. Planeie a sua alocação de endereços IPv6 juntamente com os seus intervalos IPv4 durante o desenho inicial da rede.

Os seguintes serviços do Azure suportam configurações IPv6 dual-stack:

Serviço Suporte a IPv6
Rede Virtual do Azure Subredes de pilha dupla com intervalos /64 IPv6
Balanceador de Carga Standard Interfaces IPv6 públicas e internas
Gateway de VPN Pontos de extremidade do túnel IPv6 (pré-visualização; requer adesão explícita)
NAT Gateway Tradução externa IPv6 (apenas SKU StandardV2; O SKU padrão é apenas IPv4)
IP público (SKU padrão) Endereços públicos IPv6
Conjuntos de Dimensionamento de Máquinas Virtuais Interfaces de rede IPv6
VNet Peering Tráfego IPv6 entre VNets emparelhadas
Grupos de Segurança de Rede Regras IPv6 para filtragem
DNS (DNS do Azure) Suporte a discos AAAA

Serviços-chave que não suportam IPv6: Azure Firewall (requer uma sub-rede apenas IPv4), WAN Virtual (apenas IPv4) e Route Server (apenas IPv4). O Gateway de VPN suporta IPv6 em modo dual-stack, mas apenas como uma funcionalidade de pré-visualização (requer opt-in). Se a sua arquitetura depende do Azure Firewall, WAN Virtual ou Route Server para inspeção de tráfego ou encaminhamento, projete a sua rede de forma a que o tráfego IPv6 seja tratado antes de chegar a esses componentes.

Para capacidades detalhadas do IPv6, limitações e passos de configuração, consulte IPv6 for Rede Virtual do Azure.

Endereços reservados do Azure

O Azure reserva cinco endereços IP em cada subrede:

Endereço reservado Purpose
Primeiro endereço (.0) Identificador de rede
Segundo endereço (.1) Gateway predefinido
Terceiro endereço (.2) Mapeamento do DNS do Azure
Quarto endereço (.3) Mapeamento do DNS do Azure
Último discurso (emissão) Endereço de transmissão

Inclua estes cinco endereços reservados em todos os cálculos de dimensionamento de sub-rede. Uma sub-rede /24 fornece 256 endereços no total, menos 5 reservados, restando 251 IPs de host utilizáveis. A sub-rede IPv4 mais pequena suportada é /29 (8 endereços menos 5 reservados = 3 utilizáveis). A maior sub-rede IPv4 suportada é o /2.

Dica

Endereços IP públicos de SKU padrão têm uma cobrança, estejam ou não ligados a um recurso. Como parte da higiene da IP, elimine periodicamente endereços IP públicos que já não usa e liberte prefixos de IP públicos que já não utilizou. IPs públicos não ligados são uma fonte frequente de custos evitáveis e uma superfície de ataque desnecessária.

Considerações de design

Foco no planeamento e desenho de IP para lift-and-shift

  • Reserve um único bloco CIDR grande (um /16 é comum) para a landing zone e subdivida-o por cada aplicação migrada, deixando uma margem de cerca de 20 % para crescimento.
  • Escolhe intervalos que não se sobreponham às redes locais que ligas através do Gateway de VPN ou ExpressRoute, para que o encaminhamento funcione sem tradução de endereços.
  • Tenha em conta os cinco endereços reservados do Azure por sub-rede e as subredes dedicadas que os serviços da plataforma necessitam, como GatewaySubnet (/27) e AzureFirewallSubnet (/26).
  • Onde as redes nunca fazem peering, pode-se reutilizar deliberadamente intervalos privados de IPv4 para poupar espaço de endereçamento.

Modernizar o foco da conceção do planeamento de IP

  • Aloque intervalos não sobrepostos nas suas regiões primárias e de backup para que cargas de trabalho ativas-ativas possam usar peering global mais tarde sem necessidade de reendereçamento.
  • Reserve uma sub-rede dedicada dimensionada para Ambiente do Serviço de Aplicações (/24, ou /23 perto da escala máxima). Para AKS com CNI Overlay, dimensione a sub-rede apenas para os nós, porque os pods utilizam um CIDR de overlay separado, o que faz com que a sub-rede dos nós seja muito mais pequena do que o exigido por uma configuração CNI plana.
  • Reserve uma sub-rede dedicada para endpoints privados para que a adoção de PaaS não fragmente o seu plano de endereços.
  • Use a gestão de endereços IP do Azure Virtual Network Manager para acompanhar e automatizar alocações à medida que o seu ambiente cresce.

Foco na conceção do planeamento de IP entre clouds

  • Estabeleça primeiro um plano global de endereçamento: reserve blocos CIDR do Azure que não se sobreponham às VPCs da AWS existentes nem às redes VPC da Google Cloud, o que é necessário para uma VPN com encaminhamento ou interconexão.
  • Documente os intervalos de endereços de cada nuvem e filial ligadas, para que possa planear rotas agregadas através do WAN Virtual do Azure.
  • Reserve espaço de endereços para componentes de trânsito, como o hub WAN Virtual e as sub-redes do gateway VPN, com margem para expansão à medida que adiciona extremidades da cloud e sucursais.
  • Quando as sobreposições são inevitáveis, planeie fazer NAT às ligações VPN afetadas ou reendereçar cargas de trabalho durante a migração em vez de depois.

Pré-requisitos

Antes de planear a alocação do seu endereço IP:

  • Design de redes virtuais: Tem uma estrutura VNet existente ou planeada. Se ainda não desenhaste os teus VNets, vê primeiro as redes virtuais e sub-redes do Azure.
  • Inventário de IP local: Documente os intervalos de endereços existentes no local, incluindo quaisquer intervalos usados por filiais, centros de dados ou outros fornecedores de cloud. Endereços não sobrepostos são necessários para conectividade híbrida.
  • Projeções de crescimento: Estima quantos sub-redes e hosts adicionais vais precisar nos próximos 2–3 anos. Alocar espaço de endereçamento desde o início é mais fácil do que expandir um VNet mais tarde.

Considerações de segurança

O planeamento de PI tem implicações diretas de segurança. Siga estas práticas para reduzir o risco:

  • Evitar sobreposição de endereços: Intervalos de IP sobrepostos entre redes locais, VNets Azure e VNets peered causam falhas de roteamento. O tráfego pode ser encaminhado para o destino errado ou ser descartado sem aviso. Verifique se cada intervalo de endereços é único em toda a sua rede.
  • Evite campos proibidos: A Azure reserva os seguintes campos para operações de plataforma. Nunca os uses como espaço de endereçamento VNet:
    • 169.254.0.0/16 (ligação local)
    • 168.63.129.16/32 (DNS interno do Azure)
    • 224.0.0.0/4 (multicast)
    • 127.0.0.0/8 (endereço de retorno)
    • 255.255.255.255/32 (transmissão)
  • Documentar e auditar: Mantenha um registo atualizado de todas as alocações de IP. Intervalos não documentados levam a sobreposição acidental quando novas cargas de trabalho são implementadas. Use o Azure Virtual Network Manager IPAM para acompanhamento automatizado de conformidade, ou mantenha uma folha de cálculo partilhada que é revista em cada implementação.
  • Proteger IPs públicos: Associe o Azure DDoS Protection a recursos públicos de IP em ambientes de produção. Os intervalos BYOIP também podem ser protegidos por proteção DDoS.

Estes artigos abordam temas que interagem com o planeamento de endereços IP:

Saiba mais

Passos seguintes

Dica

Explorar sozinho? Volte ao navegador de visão geral para encontrar o seu próximo artigo por capacidade.

A seguir na sua jornada de levantar e deslocar:

Proteja as suas sub-redes com grupos de segurança de rede: Espelhe as suas regras de firewall existentes como regras NSG para manter a sua postura de segurança no Azure.

Próximo passo na sua jornada de modernização:

Proteja as suas sub-redes com grupos de segurança de rede: Imponha uma segmentação rigorosa para que apenas o tráfego do balanceador de carga chegue às sub-redes da sua aplicação.

A seguir na sua jornada através da cloud:

Proteja as suas sub-redes com grupos de segurança de rede: Espelhe os seus Grupos de Segurança AWS e as regras do firewall Google Cloud como NSGs do Azure.

  • Last updated on