Este artigo descreve como minimizar o consumo de espaço de endereço privado ao criar grandes redes no Azure. Talvez seja necessário minimizar o consumo de espaço de endereço se as políticas de alocação adequadas não forem estabelecidas e você ficar sem endereços IP privados para atribuir às redes virtuais do Azure. Este artigo apresenta dois métodos para o gerenciamento adequado de endereços IP no Azure.
Detalhes do cenário
As redes corporativas normalmente usam espaços de endereço que estão nos intervalos de endereços IPv4 privados definidos na RFC 1918. Os intervalos de endereços são 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16. Em ambientes locais, esses intervalos fornecem endereços IP suficientes para atender aos requisitos até mesmo das maiores redes. Consequentemente, muitas organizações desenvolvem práticas de gerenciamento de endereços que priorizam configurações de roteamento simples e processos ágeis para alocação de IP. O uso eficiente do espaço de endereço não é uma prioridade.
Na nuvem, grandes redes híbridas são fáceis de se construir, e alguns padrões de arquitetura comuns, como microsserviços ou conteinerização, podem levar ao aumento do consumo de endereços IP. Por isso, é importante ajustar essas práticas de gerenciamento de endereços. Em um ambiente de nuvem, trate endereços IPv4 privados como um recurso limitado.
Intervalos de endereços IP na Rede Virtual do Azure
Em suas redes virtuais do Azure, é recomendável usar os blocos de endereços definidos pela RFC 1918. Esses blocos de endereços são para redes privadas de uso geral e não são roteáveis na Internet pública.
Você pode usar outros intervalos, mas antes de usá-los em sua rede virtual, leia a documentação da IANA (Autoridade para Atribuição de Números da Internet) para entender as possíveis implicações para o seu ambiente. Você pode usar os seguintes intervalos:
- Espaço de endereço compartilhado definido pela RFC 6598 para NAT (conversão de endereços de rede) de nível de operadora que é tratado como espaço de endereço privado na Rede Virtual do Azure. O bloco de endereços é 100.64.0.0/10.
- Endereços IP públicos roteáveis pela Internet que a sua organização não possui. Essa prática é recomendada, pois os recursos na rede virtual não podem acessar pontos de extremidade da Internet expostos pelos endereços IP públicos.
- Blocos de endereços especiais definidos pela IANA, como 192.0.0.0/24, 192.0.2.0/24, 192.88.99.0/24, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24 e 233.252.0.0/24.
Observação
O intervalo de endereços IP Classe E 240.0.0.0/4 é impedido pelo Windows de ser atribuído a uma NIC e tem problemas de compatibilidade no caso do Linux. Portanto, embora seja possível atribuir de modo programático o intervalo a uma rede virtual, seu uso não é recomendável em redes virtuais do Azure.
Observação
Os intervalos anteriores não fornecem uma solução de longo prazo para organizações que têm problemas de esgotamento do IPv4. Nesse caso, você deve minimizar o consumo do espaço de endereço privado.
Não é possível usar os seguintes intervalos de endereços IP em redes virtuais do Azure:
- 224.0.0.0/4 (Multicast)
- 255.255.255.255/32 (Broadcast)
- 127.0.0.0/8 (Loopback)
- 169.254.0.0/16 (Link-local)
- 168.63.129.16/32 (DNS interno)
Alinhamento da zona de destino do Azure
As recomendações neste artigo são para cenários baseados na arquitetura de zona de destino do Azure. As diretrizes pressupõem que:
- Cada região tem uma topologia hub-and-spoke.
- As redes de hub e spoke que estão em regiões diferentes são conectadas umas às outras por meio de emparelhamento de rede virtual global ou conexões com os mesmos circuitos do Azure ExpressRoute.
- As redes hub-and-spoke são conectadas a sites locais por meio de uma combinação de circuitos do ExpressRoute e de VPNs site a site.
O diagrama a seguir mostra um exemplo de arquitetura. As recomendações são igualmente aplicáveis a redes criadas sobre a WAN Virtual do Azure, que também tem redes hub-and-spoke em cada região.
Baixe um arquivo do PowerPoint dessa arquitetura.
Em um cenário baseado na arquitetura da zona de destino do Azure, os aplicativos são implantados em sua própria zona de destino. Cada zona de destino contém uma rede virtual spoke que é emparelhada a um hub regional. As redes virtuais spoke fazem parte da rede corporativa e recebem endereços IPv4 roteáveis. Esses endereços são exclusivos em toda a rede corporativa. Portanto, todos os componentes de arquitetura implantados na Rede Virtual do Azure consomem endereços IPv4 no espaço de endereço da rede corporativa, mesmo que apenas alguns componentes exponham pontos de extremidade que devam ser acessíveis em toda a rede corporativa. Esses componentes de arquitetura podem ser máquinas virtuais, NVAs (dispositivos virtuais de rede) próprios ou de terceiros, ou serviços de PaaS (plataforma como serviço) injetados em rede virtual.
No restante deste artigo, componente front-end refere-se a um componente de aplicativo que pode ser acessado em toda a rede corporativa ou de fora da zona de destino do componente. Componente back-end refere-se a um componente de aplicativo que não expõe pontos de extremidade na rede corporativa e precisa ser acessível apenas de dentro de sua própria zona de destino. Por exemplo, um aplicativo Web que expõe um ponto de extremidade é um componente front-end e um banco de dados que não expõe um ponto de extremidade é um componente back-end.
As seções a seguir descrevem dois métodos para minimizar o consumo do espaço de endereço privado quando você cria redes grandes no Azure.
Método 1: Redes virtuais spoke de zona de destino não roteáveis
O RFC 1918 retira os blocos de endereços IP do espaço de endereço IPv4 de 32 bits e os torna não roteáveis na Internet pública, para que você possa reutilizá-los em várias redes privadas para comunicação interna. Esse método é baseado no mesmo princípio que se aplica ao espaço de endereço privado. Um ou mais intervalos de endereços são formados em todo o espaço de endereço privado usado pela sua organização e declarados não roteáveis na rede corporativa da sua organização. Os intervalos de endereços são reutilizados em várias zonas de destino. Como resultado, cada zona de destino:
- Recebe um espaço de endereço roteável que é composto por um ou mais intervalos de endereços. Sua organização gerencia centralmente os intervalos de endereços e os atribui exclusivamente a uma zona de destino para comunicação com a rede corporativa. Os endereços no espaço roteável são atribuídos a componentes front-end.
- Pode usar o espaço de endereço não roteável, que são os intervalos de endereços que a sua organização declara não roteáveis na rede corporativa. Você pode usar esses intervalos reservados para comunicação interna em todas as zonas de destino. Os endereços no espaço não roteável são atribuídos a componentes back-end.
Em uma rede hub-and-spoke do Azure gerenciada pelo cliente ou baseada em WAN Virtual, duas ou mais redes virtuais spoke não podem ter espaços de endereços IP sobrepostos. Blocos de endereços não roteáveis não podem ser atribuídos a um spoke da zona de destino. O emparelhamento de rede virtual é intransitivo, portanto, uma rede virtual spoke de zona de destino pode ser emparelhada com uma rede virtual spoke de segundo nível que tenha um espaço de endereço não roteável. O diagrama a seguir mostra a topologia de rede virtual dupla para zonas de destino.
Baixe um arquivo do PowerPoint dessa arquitetura.
Cada zona de destino do aplicativo contém duas redes virtuais emparelhadas. Uma rede virtual tem endereços IP roteáveis e hospeda componentes front-end. A outra rede virtual tem endereços IP não roteáveis e hospeda componentes back-end. A zona de destino roteável spoke emparelha com o hub regional. O spoke da zona de destino não roteável emparelha com o spoke da zona de destino roteável. O emparelhamento de rede virtual é intransitivo, portanto, prefixos não roteáveis não ficam visíveis para o hub regional ou o restante da rede corporativa. As redes virtuais roteáveis não podem usar os intervalos de endereços não roteáveis. Algumas organizações têm espaço de endereço fragmentado que já está atribuído a redes roteáveis. Pode ser um desafio identificar grandes blocos de endereços não utilizados e declará-los não roteáveis. Nesse caso, considere endereços não utilizados que não estão incluídos no espaço de endereço RFC 1918. O diagrama anterior fornece um exemplo de endereços NAT de nível de operadora, como RFC 6598, em redes virtuais spoke não roteáveis.
Migração da zona de destino de rede virtual única
O emparelhamento de rede virtual fornece conectividade completa de camada 3 entre duas redes virtuais emparelhadas. Os componentes de aplicativo implantados em zonas de destino de rede virtual única tradicionais que se comunicam entre si por IP podem ser transferidos livremente entre redes virtuais roteáveis e não roteáveis em uma zona de destino. Esta seção descreve dois padrões típicos de migração.
Os seguintes aplicativos são expostos por meio de controladores de entrega de aplicativo de camada 7:
Baixe um arquivo do PowerPoint dessa arquitetura.
Os aplicativos expostos por meio de controladores de entrega de aplicativo da camada 7 podem ser movidos para o spoke não roteável. O controlador de entrega de aplicativo é o único componente front-end que deve residir no spoke da zona de destino roteável.
Os seguintes aplicativos são expostos por meio de um balanceador de carga do Azure:
Baixe um arquivo do PowerPoint dessa arquitetura.
Se um aplicativo expuser seus pontos de extremidade por meio de um balanceador de carga do Azure, as instâncias de computação que fazem parte do pool de back-end do balanceador de carga deverão permanecer na mesma rede virtual. Os balanceadores de carga do Azure dão suporte apenas a instâncias de back-end em sua própria rede virtual.
Dependências de saída
Os componentes back-end de um aplicativo não precisam estar acessíveis nem receber conexões de entrada, da rede corporativa, mas, geralmente, eles têm dependências de saída. Os componentes de back-end podem precisar se conectar a pontos de extremidade que estão fora de suas zonas de destino em instâncias como resolução de DNS, Controladores de domínio do Active Directory Domain Services, acessar pontos de extremidade de aplicativos expostos por outras zonas de destino ou acessar recursos de registro em log ou de backup.
Observação
A comunicação de Controladores de Domínio (DCs) do cliente para Active Directory Domain Services (ADDS) sobre NAT foi testada e é suportada, a comunicação de DC para DC não foi testada e não é suportada conforme detalhado em Descrição dos limites de suporte para o Active Directory sobre NAT
Quando os serviços iniciam conexões em redes virtuais spoke não roteáveis, você deve implementar a SNAT (NAT de origem) para conexões por trás de um endereço IP roteável. Para implementar a SNAT, implante um dispositivo compatível com NAT na rede virtual spoke roteável. Cada zona de destino executa seu próprio NVA NAT dedicado. Há duas opções para implementar a SNAT em uma zona de destino: Firewall do Azure ou NVAs de terceiros. Em ambos os casos, todas as sub-redes no spoke não roteável devem ser associadas a uma tabela de rotas personalizada. Conforme mostrado no diagrama a seguir, a tabela de rotas encaminha o tráfego para destinos fora da zona de destino para o dispositivo SNAT. O Gateway da NAT do Azure não dá suporte à SNAT para tráfego destinado ao espaço de endereço IP privado, como o espaço RFC 1918.
Baixe um arquivo do PowerPoint dessa arquitetura.
Implementar a SNAT pelo Firewall do Azure
Firewall do Azure:
- Fornece alta disponibilidade.
- Fornece escalabilidade nativa e três SKUs diferentes. A SNAT não é uma tarefa que consome muitos recursos, portanto, considere o SKU básico primeiro. Para zonas de destino que exigem grandes volumes de tráfego de saída do espaço de endereço não roteável, use o SKU padrão.
- Executa SNAT para tráfego por trás dos endereços IP privados de qualquer uma de suas instâncias. Cada instância pode usar todas as portas sem privilégios.
O diagrama a seguir mostra o layout da zona de destino para implementação da SNAT em uma topologia de rede hub-and-spoke usando o Firewall do Azure.
Baixe um arquivo do PowerPoint dessa arquitetura.
Você deve associar todas as sub-redes no spoke não roteável a uma tabela de rotas personalizada para enviar tráfego a destinos fora da zona de destino para o Firewall do Azure.
O diagrama a seguir mostra o layout da zona de destino para implementação da SNAT em uma rede de hub-and-spoke baseada em WAN Virtual usando o Firewall do Azure.
Baixe um arquivo do PowerPoint dessa arquitetura.
Você deve associar todas as sub-redes no spoke não roteável, ou os spokes que não estão conectados à WAN Virtual, a uma tabela de rotas personalizada para enviar tráfego aos destinos fora da zona de destino para o Firewall do Azure.
Em ambos os layouts, para fornecer recursos no acesso spoke não roteável a endereços IP roteáveis fora de sua zona de destino, você deve implantar o Firewall do Azure com a opção Executar SNAT definida como Sempre no spoke roteável de cada zona de destino. É possível encontrar instruções sobre como configurar o Firewall do Azure para implementação da SNAT em todas as conexões recebidas na documentação pública. A captura de tela a seguir mostra a configuração necessária para usar o Firewall do Azure como um dispositivo NAT para conexões iniciadas por recursos em redes virtuais spoke não roteáveis.
Implementar a SNAT por meio de NVAs de terceiros
NVAs de terceiros com recursos NAT estão disponíveis no Azure Marketplace. Elas fornecem:
- Controle granular sobre a redução e a expansão.
- Controle granular do pool de NAT.
- Políticas NAT personalizadas, como o uso de endereços NAT diferentes, dependendo das propriedades da conexão de entrada, como o endereço IP de origem ou de destino.
Considere as seguintes recomendações:
- Para alta disponibilidade, implante clusters com pelo menos dois NVAs. Use um balanceador de carga do Azure para distribuir conexões de entrada da rede virtual spoke não roteável para os NVAs. Uma regra de balanceamento de carga de porta de alta disponibilidade é necessária, pois o cluster implementa a SNAT em todas as conexões que saem da zona de destino. O Azure Standard Load Balancer dá suporte a regras de balanceamento de carga de porta de alta disponibilidade.
- A pilha de SDN do Azure dá suporte a NVAs de braço único e braço duplo. Os NVAs de braço único são preferidos porque reduzem o consumo de espaço de endereço nas redes virtuais spoke roteáveis.
O diagrama a seguir mostra o layout da zona de destino para implementação da SNAT em uma topologia de rede hub-and-spoke usando NVAs de terceiros.
Baixe um arquivo do PowerPoint dessa arquitetura.
O diagrama a seguir mostra o layout da zona de destino para implementação da SNAT em uma topologia de rede hub-and-spoke baseada em WAN Virtual usando NVAs de terceiros.
Baixe um arquivo do PowerPoint dessa arquitetura.
Para ambos os layouts de NVA de terceiros, você deve implantar várias instâncias por trás de um balanceador de carga do Azure para fornecer alta disponibilidade. É necessário o SKU Standard do Azure Load Balancer.
Método 2: serviços de Link Privado do Azure
O Link Privado fornece acesso a aplicativos implantados em uma rede virtual que não está conectada à sua rede virtual. Na rede virtual do servidor, ou do aplicativo, um serviço de Link Privado é implantado e associado a um ponto de extremidade de aplicativo exposto no endereço IP do front-end de um balanceador de carga interno de SKU Standard do Azure. Na rede virtual do cliente, um recurso de ponto de extremidade privado é implantado e associado ao serviço de Link Privado. O ponto de extremidade privado expõe o ponto de extremidade do aplicativo em suas redes virtuais. O Link Privado fornece o túnel e a lógica NAT para rotear o tráfego entre o lado do cliente e o lado do servidor. Para obter mais informações, confira O que é o Link Privado do Azure?
O Link Privado não requer uma conexão de camada 3 entre a rede virtual do cliente e a rede virtual do servidor. As duas redes virtuais podem ter espaços de endereços IP sobrepostos. O Link Privado permite a implantação de aplicativos em redes virtuais dedicadas e isoladas, todas elas usando o mesmo espaço de endereço não roteável. Os aplicativos são expostos como serviços de Link Privado na rede corporativa, que usa um espaço de endereço roteável. No contexto da arquitetura da zona de destino do Azure, a topologia da zona de destino resultante tem:
- Uma rede virtual isolada que hospeda todo o aplicativo e o serviço de Link Privado associado aos pontos de extremidade do aplicativo. A equipe do aplicativo define o espaço de endereço de rede virtual.
- Uma rede virtual spoke com um espaço de endereço roteável que hospeda o ponto de extremidade privado associado ao serviço de Link Privado. A rede virtual spoke é diretamente emparelhada com o hub regional.
O diagrama a seguir mostra a topologia da zona de destino habilitada para Link Privado.
Baixe um arquivo do PowerPoint dessa arquitetura.
Usar um serviço de Link Privado para dependências de saída
Ao implantar aplicativos em redes virtuais spoke isoladas, use um serviço de Link Privado para dependências de saída. Defina pontos de extremidade privados na rede virtual spoke isolada e associe-os a um serviço de Link Privado em redes virtuais roteáveis. O seguinte diagrama mostra a abordagem conceitual.
Baixe um arquivo do PowerPoint dessa arquitetura.
Em implementações reais em larga escala, o método de Link Privado poderá não se aplicar:
- Se os aplicativos implantados na rede virtual isolada tiverem várias dependências de saída. Quando você implanta um serviço de Link Privado e um ponto de extremidade privado para cada uma das dependências de saída; isso aumenta a complexidade e as necessidades de gerenciamento.
- Se a dependência de saída incluir pontos de extremidade na rede roteável que não possam fazer parte de um pool de back-end do Azure Load Balancer, o Link Privado não será aplicável.
Para superar essas duas limitações, implante uma solução de proxy/NAT no spoke roteável e torne-a acessível a partir da rede virtual isolada usando o Link Privado.
Baixe um arquivo do PowerPoint dessa arquitetura.
Use um único ponto de extremidade privado ou serviço de Link Privado para expor uma solução de proxy/NAT implantada na rede roteável. As regras de conversão de endereço e de porta são definidas nos NVAs. Essas regras permitem o uso de um único ponto de extremidade privado na rede virtual isolada para acessar várias dependências na rede roteável.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Principais autores:
- Federico Guerrini | Líder Técnico EMEA
- Khush Kaviraj | Arquiteto de Solução em Nuvem
- Jack Tracey | Arquiteto Sênior de Solução em Nuvem
Outros colaboradores:
- Jodi Martis | Redator Técnico
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.
Próximas etapas
- Implantar o Firewall do Azure em uma rede virtual
- Configurar a SNAT no Firewall do Azure
- Endereços IP com suporte na Rede Virtual do Azure
- Link Privado do Azure
- Azure Load Balancer
- Emparelhamento de rede virtual