Planejar o endereçamento IP

É importante que sua organização planeje o endereçamento IP no Azure. O planejamento garante que o espaço de endereço IP não se sobreponha entre locais locais e regiões do Azure.

Considerações sobre design:

• A sobreposição de espaços de endereço IP em regiões locais e do Azure cria grandes desafios de contenção.

• O Gateway de VPN do Azure pode se conectar a sites locais sobrepostos com espaços de endereço IP sobrepostos por meio da capacidade NAT (conversão de endereços de rede). Esse recurso geralmente está disponível na WAN Virtual do Azure e no Gateway de VPN autônomo do Azure.

  

• Você pode adicionar espaço de endereço depois de criar uma rede virtual. Esse processo não exigirá uma interrupção se a rede virtual já estiver conectada a outra rede virtual por meio do emparelhamento de rede virtual. Em vez disso, cada emparelhamento remoto precisa de uma operação de ressincronização feita após a alteração do espaço de rede.

• O Azure reserva cinco endereços IP em cada sub-rede. Considere esses endereços no dimensionamento de redes virtuais e sub-redes englobadas.

• Alguns serviços do Azure exigem sub-redes dedicadas. Esses serviços incluem o Firewall do Azure e o Gateway de VPN do Azure.

• Você pode delegar sub-redes a determinados serviços para criar instâncias de um serviço dentro da sub-rede.

Recomendações de design:

• Planeje espaços de endereço IP não sobrepostos entre regiões do Azure e locais com antecedência.

• Use endereços IP da alocação de endereços para a Internet privada, conhecida como endereços RFC 1918.

• Não use os seguintes intervalos de endereços:

  • 224.0.0.0/4 (multicast)
  • 255.255.255.255/32 (difundido)
  • 127.0.0.0/8 (Loopback)
  • 169.254.0.0/16 (link-local)
  • 168.63.129.16/32 (DNS interno)

• Para ambientes com disponibilidade limitada de endereços IP privados, considere o uso do IPv6. As Redes virtuais pode ser somente IPv4 ou de pilha dupla IPv4+IPv6.

  

• Não crie redes virtuais grandes como /16. Ele garante que o espaço de endereço IP não seja desperdiçado. A menor sub-rede IPv4 com suporte é /29, e a maior é /2 ao usar definições de sub-rede CIDR (roteamento entre domínios) sem classe. As sub-redes IPv6 devem estar exatamente /64 em tamanho.

• Não crie redes virtuais sem planejar o espaço de endereço necessário com antecedência.

• Não use endereços IP públicos para redes virtuais, especialmente se os endereços IP públicos não pertencerem à sua organização.

• Leve em consideração os serviços que você usará, há alguns serviços com IPs reservados (Endereços IP), como AKS com rede CNI

• Use redes virtuais de spoke de zona de aterrissagem não roteável e o serviço Azure Private Link para evitar o esgotamento do IPv4.

Considerações de IPv6

Um número crescente de organizações está adotando o IPv6 em seus ambientes. Essa adoção é impulsionada pelo esgotamento de espaço IPv4 público, pela escassez de IPv4 privado, especialmente em redes de grande escala, e pela necessidade de fornecer conectividade aos clientes somente IPv6. Não há nenhuma abordagem universal para a adoção do IPv6. No entanto, há práticas recomendadas que você pode seguir quando planeja o IPv6 e implementá-lo em suas redes existentes do Azure.

O Microsoft Cloud Adoption Framework para Azure ajuda você a entender as considerações a serem consideradas ao criar sistemas na nuvem. Para saber mais sobre as práticas recomendadas de arquitetura para criar sistemas sustentáveis, consulte os princípios de design da zona de destino do Azure. Para obter recomendações detalhadas e práticas recomendadas sobre sua arquitetura de nuvem, incluindo implantações de arquitetura de referência, diagramas e guias, consulte o guia do Centro de Arquitetura para IPv6.

Considerações sobre design:

• Implemente a adoção do IPv6 em fases. Com base nas suas necessidades comerciais, implemente o IPv6 quando necessário. Lembre-se de que IPv4 e IPv6 podem coexistir o tempo necessário.

• Em cenários em que os aplicativos dependem de serviços iaaS (infraestrutura como serviço) que têm suporte completo do IPv6, como VMs (máquinas virtuais), o uso nativo de ponta a ponta de IPv4 e IPv6 é possível. Essa configuração evita complicações de tradução e fornece a maioria das informações para o servidor e o aplicativo.

  Você pode implantar Basic-SKU balanceadores de carga do Azure voltados para a Internet com um endereço IPv6. Essa configuração permite conectividade IPv6 de ponta a ponta nativa entre a Internet pública e as VMs do Azure por meio do balanceador de carga. Essa abordagem também facilita conexões de saída de ponta a ponta nativas entre VMs e clientes habilitados para IPv6 na Internet pública. Observe que essa abordagem requer todos os dispositivos no caminho para lidar com o tráfego IPv6.

  A abordagem de ponta a ponta nativa é mais útil para comunicação direta de servidor para servidor ou cliente para servidor. Não é útil para a maioria dos serviços Web e aplicativos, que normalmente são protegidos por firewalls, firewalls de aplicativo Web ou proxies reversos.

• Algumas implantações e aplicativos complexos que usam uma combinação de serviços de terceiros, serviços paaS (plataforma como serviço) e soluções de back-end podem não dar suporte ao IPv6 nativo. Nesses casos, você precisa usar NAT/NAT64 ou uma solução de proxy IPv6 para habilitar a comunicação entre IPv6 e IPv4.

• Quando a complexidade da arquitetura do aplicativo ou outros fatores, como os custos de treinamento, forem considerados significativos, talvez você queira continuar usando a infraestrutura somente IPv4 no back-end e implantar um gateway IPv4/IPv6 de pilha dupla de dispositivo virtual de rede (NVA) de terceiros para a prestação de serviços.

  Uma implantação típica que usa uma NVA pode ter esta aparência:

  

Recomendações de design:

Veja mais de perto a aparência de uma arquitetura típica:

• Implante o NVA em Conjuntos de Dimensionamento de Máquinas Virtuais com orquestração flexível (VMSS Flex) para resiliência e exponha-os à Internet por meio do Azure Load-Balancer, que tem um front-end de endereço IP público.

  Os NVAs aceitam o tráfego IPv4 e IPv6 e o convertem no tráfego somente IPv4 para acessar o aplicativo na sub-rede do aplicativo. A abordagem reduz a complexidade da equipe de aplicativos e reduz a superfície de ataque.

• Implante o Azure Front Door para fornecer roteamento global para o tráfego da Web.

  Os recursos do Azure Front Door incluem o proxy de solicitações e tráfego de clientes IPv6 para um back-end somente IPv4, como mostrado aqui:

  

Essas são as principais diferenças entre a abordagem NVA e a abordagem do Azure Front Door:

• As NVAs são gerenciadas pelo cliente, funcionam na Camada 4 do modelo de OSI e podem ser implantadas na mesma rede virtual do Azure que o aplicativo, com uma interface pública e privada.
• O Azure Front Door é um serviço global de PaaS do Azure e opera na Camada 7 (HTTP/HTTPS). O back-end do aplicativo é um serviço voltado para a Internet que pode ser bloqueado para aceitar apenas o tráfego do Azure Front Door.

Em ambientes complexos, você pode usar uma combinação de ambos. Os NVAs são usados em uma implantação regional. O Azure Front Door é usado para rotear o tráfego para uma ou mais implantações regionais em diferentes regiões do Azure ou em outros locais voltados para a Internet. Para determinar a melhor solução, recomendamos que você examine os recursos do Azure Front Door e a documentação do produto.

Blocos CIDR de rede virtual IPv6:

• Você pode associar um único bloco CIDR (Roteamento Entre Domínios Sem Classe) IPv6 ao criar uma nova rede virtual em uma implantação existente do Azure em sua assinatura. O tamanho da sub-rede para IPv6 deve ser /64. Usar esse tamanho garante compatibilidade futura se você decidir habilitar o roteamento da sub-rede para uma rede local. Alguns roteadores podem aceitar apenas rotas IPv6 /64.
• Se você tiver uma rede virtual existente que dê suporte apenas a IPv4 e recursos em sua sub-rede configurados para usar apenas IPv4, você poderá habilitar o suporte IPv6 para sua rede virtual e recursos. A sua rede virtual pode operar no modo dual-stack, permitindo que seus recursos se comuniquem via IPv4, IPv6 ou ambos. A comunicação IPv4 e IPv6 são independentes umas das outras.
• Você não pode desabilitar o suporte ao IPv4 para sua rede virtual e sub-redes. O IPv4 é o sistema de endereçamento IP padrão para redes virtuais do Azure.
• Associe um bloco CIDR IPv6 à sua rede virtual e sub-rede ou BYOIP IPv6. A notação CIDR é um método de representar um endereço IP e sua máscara de rede. Os formatos desses endereços são os seguintes:
  • Um endereço IPv4 individual é de 32 bits, com quatro grupos de até três dígitos decimais. Por exemplo, 10.0.1.0.
  • Um bloco CIDR IPv4 tem quatro grupos de até três dígitos decimais, de 0 a 255, separados por períodos e seguidos por uma barra e um número de 0 a 32. Por exemplo, 10.0.0.0/16.
  • Um endereço IPv6 individual tem 128 bits. Tem oito grupos de quatro dígitos hexadecimais. Por exemplo, 2001:0db8:85a3:0000:0000:8a2e:0370:7334.
  • Um bloco CIDR IPv6 tem quatro grupos de até quatro dígitos hexadecimal, separados por dois-pontos, seguidos por dois-pontos e, em seguida, seguidos por uma barra e um número de 1 a 128. Por exemplo, 2001:db8:1234:1a00::/64.
• Atualize as tabelas de rotas para rotear o tráfego IPv6. Para o tráfego público, crie uma rota que roteia todo o tráfego IPv6 da sub-rede para o Gateway de VPN ou um gateway do Azure ExpressRoute.
• Atualize as regras do grupo de segurança para incluir regras para endereços IPv6. Isso permite que o tráfego IPv6 flua de e para suas instâncias. Se você tiver regras de grupo de segurança de rede para controlar o fluxo de tráfego de e para sua sub-rede, deverá incluir regras para o tráfego IPv6.
• Se o tipo de instância não der suporte ao IPv6, use uma pilha dupla ou implante uma NVA, conforme descrito anteriormente, que se traduz de IPv4 para IPv6.

Ferramentas de IPAM (Gerenciamento de Endereço IP)

O uso de uma ferramenta IPAM pode ajudá-lo com o planejamento de endereço IP no Azure, pois fornece gerenciamento centralizado e visibilidade, evitando sobreposições e conflitos em espaços de endereço IP. Esta seção orienta você por considerações e recomendações essenciais ao adotar uma ferramenta IPAM.

Considerações sobre design:

Várias ferramentas DE IPAM estão disponíveis para sua consideração, dependendo de seus requisitos e do tamanho da sua organização. As opções vão desde ter um inventário básico baseado no Excel até uma solução baseada na comunidade de software livre ou produtos empresariais abrangentes com recursos e suporte avançados.

• Considere esses fatores ao avaliar qual ferramenta IPAM implementar:

  • Recursos mínimos exigidos pela sua organização
  • TCO (custo total de propriedade), incluindo licenciamento e manutenção contínua
  • Trilhas de auditoria, log e controles de acesso baseados em função
  • Autenticação e autorização por meio da ID do Microsoft Entra
  • Acessível por meio da API
  • Integrações com outras ferramentas e sistemas de gerenciamento de rede
  • Suporte da comunidade ativa ou o nível de suporte do provedor de software

• Considere avaliar uma ferramenta DE IPAM de software livre, como o IPAM do Azure. O IPAM do Azure é uma solução leve criada na plataforma do Azure. Ele descobre automaticamente a utilização de endereço IP em seu locatário do Azure e permite que você gerencie tudo isso de uma interface do usuário centralizada ou por meio de uma API RESTful.

• Considere o modelo operacional de suas organizações e a propriedade da ferramenta IPAM. A meta de implementar uma ferramenta IPAM é simplificar o processo de solicitação de novos espaços de endereço IP para equipes de aplicativos sem dependências e gargalos.

• Uma parte importante da funcionalidade da ferramenta IPAM é inventariar o uso do espaço de endereço IP e organizá-lo logicamente.

Recomendações de design:

• O processo de reserva de espaços de endereço IP não sobrepostos deve dar suporte à solicitação de tamanhos diferentes com base nas necessidades das zonas de destino de aplicativo individuais.

  • Por exemplo, você pode adotar o dimensionamento de camisetas para facilitar que as equipes de aplicativos descrevam suas necessidades:
    • Pequenos – /24 – 256 endereços IP
    • Médio - /22 - 1.024 endereços IP
    • Grandes - /20 - 4.096 endereços IP

• Sua ferramenta IPAM deve ter uma API para reservar espaços de endereço IP não sobrepostos para dar suporte a uma abordagem de IaC (Infraestrutura como Código). Esse recurso também é crucial para a integração perfeita do IPAM em seu processo de venda de assinaturas, reduzindo assim o risco de erros e a necessidade de intervenção manual.

  • Um exemplo de abordagem de IaC é o Bicep com sua funcionalidade de script de implantação ou fontes de dados do Terraform para buscar dados dinamicamente da API do IPAM.

• Crie uma disposição sistemática para seus espaços de endereço IP estruturando-os de acordo com regiões do Azure e arquétipos de carga de trabalho, garantindo um inventário de rede limpo e rastreável.

• O processo de descomissionamento para cargas de trabalho deve incluir a remoção de espaços de endereço IP que não são mais usados, que posteriormente podem ser reaproveitados para novas cargas de trabalho futuras, promovendo a utilização eficiente de recursos.