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 de design:

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

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

  

• Você pode adicionar espaço de endereço depois de criar uma rede virtual. Esse processo não precisa de 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. Leve em consideração esses endereços ao dimensionar 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 em regiões do Azure e locais locais com antecedência.

• Use endereços IP da alocação de endereços para Internet privada, conhecidos 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 (difusão)
  • 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 podem ser somente IPv4 ou IPv4+IPv6 de pilha dupla.

  

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

• Não crie redes virtuais sem planejar o espaço de endereçamento 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 reservados (Endereços IP), como AKS com rede CNI

• Use redes virtuais não roteáveis faladas em zona de aterrissagem 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, pela escassez de IPv4 privado, especialmente em redes de grande escala, e pela necessidade de fornecer conectividade a clientes somente IPv6. Não há uma abordagem universal para adotar o IPv6. No entanto, existem 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 para Azure ajuda-o a compreender as considerações a ter em conta quando cria sistemas na nuvem. Para saber mais sobre as práticas recomendadas de arquitetura para projetar sistemas sustentáveis, consulte Princípios de design da zona de aterrissagem do Azure. Para obter recomendações detalhadas e práticas recomendadas em relação à sua arquitetura de nuvem, incluindo implantações, diagramas e guias de arquitetura de referência, consulte o guia do Centro de arquitetura para IPv6.

Considerações de design:

• Faseie sua adoção do IPv6. Com base nas suas necessidades de negócios, implemente o IPv6 onde necessário. Lembre-se de que o IPv4 e o IPv6 podem coexistir enquanto 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 permite 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 todos os dispositivos no caminho para lidar com o tráfego IPv6.

  A abordagem end-to-end nativa é mais útil para comunicação direta de servidor para servidor ou cliente-para-servidor. Não é útil para a maioria dos serviços e aplicativos da Web, que normalmente são protegidos por firewalls, firewalls de aplicativos da 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 os custos de treinamento, forem considerados significativos, convém 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 entrega de serviços.

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

  

Recomendações de design:

Aqui está um olhar mais atento sobre como uma arquitetura típica pode parecer:

• Implante o NVA em conjuntos de escala de máquina virtual com orquestração flexível (VMSS Flex) para resiliência e exponha à 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 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 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 da Porta da Frente do Azure.

Em ambientes complexos, você pode usar uma combinação de ambos. Os NVAs são usados dentro de 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 routers podem aceitar apenas rotas IPv6 /64.
• Se tiver uma rede virtual existente que suporte apenas IPv4 e recursos na sua sub-rede configurados para utilizar apenas IPv4, pode ativar o suporte IPv6 para a 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. A comunicação 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 BYOIP IPv6. Notação CIDR é um método de representar um endereço IP e sua máscara de rede. Os formatos destes 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 de Rota Expressa do Azure.
• 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 seu tipo de instância não suportar IPv6, use pilha dupla ou implante um NVA, conforme descrito anteriormente, que se traduz de IPv4 para IPv6.

Ferramentas de Gerenciamento de Endereço IP (IPAM)

O uso de uma ferramenta 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 de design:

Várias ferramentas do IPAM estão disponíveis para sua consideração, dependendo dos seus requisitos e do tamanho da sua organização. As opções vão 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 avançados e suporte.

• 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 através do Microsoft Entra ID
  • Acessível via API
  • Integrações com outras ferramentas e sistemas de gestão de rede
  • Suporte ativo da comunidade ou o nível de suporte do fornecedor 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 do endereço 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 da sua organização e a propriedade da ferramenta IPAM. O objetivo da implementação de uma ferramenta do IPAM é agilizar o processo de solicitação de novos espaços de endereços 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 tamanho da camiseta para facilitar que as equipes de aplicativos descrevam suas necessidades:
    • 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 dar suporte a uma abordagem de infraestrutura como código (IaC). Este recurso também é crucial para a integração perfeita do IPAM em seu processo de venda automática de assinaturas, 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 um arranjo sistemático 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 reaproveitados posteriormente para novas cargas de trabalho futuras, promovendo a utilização eficiente de recursos.