Planejar o endereçamento IP

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

Considerações sobre o design:

• A sobreposição de espaços de endereço IP entre 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 está disponível em geral na WAN Virtual do Azure e no Gateway de VPN do Azure autônomo.

  

• É possível adicionar espaço de endereço depois de criar uma rede virtual. Esse processo não precisará de uma paralisaçã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.

• É possível 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 que têm disponibilidade limitada de endereços IP privados, considere o uso de 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 perdido. 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 ter exatamente /64 de 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ê vai usar, existem alguns serviços com IPs (endereços IP) reservados, como AKS com rede CNI

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

Considerações sobre IPv6

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

O Microsoft Cloud Adoption Framework for Azure ajuda você a entender as considerações a serem levadas em conta ao criar sistemas na nuvem. Para saber mais sobre as práticas recomendadas de arquitetura para projetar sistemas sustentáveis, consulte Princípios de design de zona de aterrissagem 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 o design:

• Faseie sua adoção do IPv6. Com base nas necessidades do seu negócio, implemente o IPv6 onde for necessário. Lembre-se de que IPv4 e IPv6 podem coexistir pelo tempo que for necessário.

• Em cenários em que os aplicativos dependem de serviços de infraestrutura como serviço (IaaS) que têm suporte total a IPv6, como máquinas virtuais (VMs), 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 balanceadores de carga do Azure voltados para a Internet Basic-SKU com um endereço IPv6. Essa configuração habilita a conectividade IPv6 nativa de ponta a ponta 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 nativas de ponta a ponta entre VMs e clientes habilitados para IPv6 na Internet pública. Observe que essa abordagem requer que todos os dispositivos no caminho manipulem o tráfego IPv6.

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

• Algumas implantações e aplicativos complexos que usam uma combinação de serviços de terceiros, serviços de plataforma como serviço (PaaS) e soluções de back-end podem não oferecer suporte a 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 custos de treinamento, são considerados significativos, convém continuar usando a infraestrutura somente IPv4 no back-end e implantar um gateway IPv4/IPv6 de pilha dupla NVA (Network Virtual Appliance) de terceiros para entrega de serviços.

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

  

Recomendações de design:

Aqui está uma visão mais detalhada de como uma arquitetura típica pode parecer:

• Implante o NVA em Conjuntos de Dimensionamento de Máquina Virtual 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 tráfego IPv4 e IPv6 e o convertem em tráfego somente IPv4 para acessar o aplicativo na sub-rede do aplicativo. A abordagem reduz a complexidade para a 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 proxy de solicitações de cliente IPv6 e tráfego para um back-end somente IPv4, conforme mostrado aqui:

  

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

• Os NVAs são gerenciados pelo cliente, funcionam na Camada 4 do modelo OSI e podem ser implantados na mesma rede virtual do Azure que o aplicativo, com uma interface privada e pública.
• O Azure Front Door é um serviço PaaS global 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 outros locais voltados para a Internet. Para determinar a melhor solução, recomendamos que você revise 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. O uso desse 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 ofereça suporte apenas a IPv4 e recursos em sua sub-rede configurados para usar somente IPv4, poderá habilitar o suporte a IPv6 para sua rede virtual e recursos. Sua rede virtual pode operar no modo de pilha dupla, o que permite que seus recursos se comuniquem por IPv4, IPv6 ou ambos. As comunicações IPv4 e IPv6 são independentes uma da outra.
• Não é possível desativar o suporte a 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 IPv6 BYOIP. 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 pontos 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 é de 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 hexadecimais, separados por dois pontos, seguidos por dois pontos duplos e, em seguida, seguidos por uma barra e um número de 1 a 128. Por exemplo, 2001:db8:1234:1a00::/64.
• Atualize suas tabelas de rotas para rotear o tráfego IPv6. Para tráfego público, crie uma rota que roteie todo o tráfego IPv6 da sub-rede para o Gateway 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 oferecer suporte a IPv6, use pilha dupla ou implante um NVA, conforme descrito anteriormente, que traduza de IPv4 para IPv6.

Ferramentas de Gerenciamento de Endereço IP (IPAM)

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

Considerações sobre o design:

Várias ferramentas do IPAM estão disponíveis para sua consideração, dependendo de seus requisitos e do tamanho de sua organização. As opções abrangem desde ter um inventário básico baseado em Excel até uma solução de código aberto orientada pela comunidade ou produtos empresariais abrangentes com recursos e suporte avançados.

• Considere estes fatores ao avaliar qual ferramenta do IPAM implementar:

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

• Considere avaliar uma ferramenta de IPAM de código aberto como o Azure IPAM. O Azure IPAM é uma solução leve criada na plataforma Azure. Ele descobre automaticamente a utilização de endereços IP em seu locatário do Azure e permite que você gerencie tudo a partir 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. O objetivo da implementação de uma ferramenta IPAM é agilizar 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ços IP não sobrepostos deve suportar a solicitação de tamanhos diferentes com base nas necessidades das zonas de aterrissagem de aplicativos individuais.

  • Por exemplo, você pode adotar o dimensionamento de camisetas para facilitar a descrição de suas necessidades pelas equipes de aplicativos:
    • Pequeno - /24 - 256 endereços IP
    • Médio - /22 - 1.024 endereços IP
    • Grande - /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 oferecer suporte a uma abordagem IaC (Infraestrutura como Código). Esse recurso também é crucial para a integração perfeita do IPAM em seu processo de venda automática de assinatura, reduzindo assim o risco de erros e a necessidade de intervenção manual.

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

• Crie uma organização sistemática para seus espaços de endereço IP estruturando-os de acordo com as 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 podem ser posteriormente reaproveitados para novas cargas de trabalho futuras, promovendo a utilização eficiente de recursos.