Este artigo descreve como minimizar o consumo de espaço de endereçamento privado quando você cria grandes redes no Azure. Talvez seja necessário minimizar o consumo de espaço de endereçamento 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. Como resultado, 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çamento não é uma prioridade.
Na nuvem, grandes redes híbridas são fáceis de 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 da Rede Virtual do Azure
Em suas redes virtuais do Azure, recomendamos que você use os blocos de endereço definidos pela RFC 1918. Estes blocos de endereços destinam-se a redes privadas de uso geral e não são roteáveis na Internet pública.
Você pode usar outros intervalos, mas antes de usar esses intervalos em sua rede virtual, leia a documentação da Internet Assigned Numbers Authority (IANA) para entender as possíveis implicações para seu ambiente. Você pode usar os seguintes intervalos:
- Espaço de endereçamento partilhado 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çamento privado na Rede Virtual do Azure. O bloco de endereço é 100.64.0.0/10.
- Endereços IP públicos roteáveis pela Internet que sua organização não possui. Essa prática é desencorajada porque os recursos na rede virtual não podem acessar pontos de extremidade da Internet que são expostos através dos 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.
Nota
O intervalo de endereços IP de Classe E 240.0.0.0/4 é impedido pelo Windows de atribuí-lo a uma NIC e tem problemas de compatibilidade no caso do Linux. Portanto, embora seja possível atribuir programaticamente o intervalo a uma rede virtual, não recomendamos seu uso em redes virtuais do Azure.
Nota
Os intervalos anteriores não fornecem uma solução de longo prazo para organizações que têm problemas de exaustão IPv4. Nesse caso, você deve minimizar o consumo de espaço de endereçamento privado.
Não é possível usar os seguintes intervalos de endereços IP nas redes virtuais do Azure:
- 224.0.0.0/4 (Multicast)
- 255.255.255.255/32 (Transmissão)
- 127.0.0.0/8 (Loopback)
- 169.254.0.0/16 (Link-local)
- 168.63.129.16/32 (DNS interno)
Alinhamento da zona de aterrissagem do Azure
As recomendações neste artigo são para cenários baseados na arquitetura da zona de aterrissagem do Azure. As orientações partem do princípio de que:
- Cada região tem uma topologia hub-and-spoke.
- As redes Hub-and-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 o mesmo circuito ou circuitos da Rota Expressa do Azure.
- As redes Hub-and-spoke são conectadas a sites locais por meio de uma combinação de circuitos de Rota Expressa e 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.
Transfira um ficheiro PowerPoint desta arquitetura.
Em um cenário baseado na arquitetura da zona de aterrissagem do Azure, os aplicativos são implantados em sua própria zona de aterrissagem. Cada zona de pouso contém uma rede virtual falada que é peered para um hub regional. As redes virtuais Spoke são parte integrante da rede corporativa e recebem endereços IPv4 roteáveis. Esses endereços são únicos em toda a rede corporativa. Assim, todos os componentes de arquitetura implantados na Rede Virtual do Azure consomem endereços IPv4 no espaço de endereçamento da rede corporativa, mesmo que apenas alguns componentes exponham pontos de extremidade que devem ser acessíveis de toda a rede corporativa. Esses componentes de arquitetura podem ser máquinas virtuais, NVAs (dispositivos virtuais de rede) primários ou de terceiros ou serviços de plataforma como serviço (PaaS) injetados em rede virtual.
Para o restante deste artigo, componente front-end refere-se a um componente de aplicativo que pode ser acessado de toda a rede corporativa ou de fora da zona de aterrissagem do componente. O componente back-end refere-se a um componente de aplicativo que não expõe pontos de extremidade na rede corporativa e só precisa ser acessível 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 de espaço de endereçamento privado quando você cria grandes redes no Azure.
Método 1: Redes virtuais não roteáveis faladas na zona de aterrissagem
O RFC 1918 esculpiu os blocos de endereços IP fora do espaço de endereçamento 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. Este método baseia-se no mesmo princípio que se aplica ao espaço de endereçamento privado. Um ou mais intervalos de endereços são esculpidos fora de todo o espaço de endereço privado que é usado pela sua organização e declarado não roteável dentro da rede corporativa da sua organização. Os intervalos de endereços são reutilizados em várias zonas de pouso. Como resultado, cada zona de desembarque:
- É atribuído um espaço de endereçamento roteável que é feito de 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 se comunicar com a rede corporativa. Os endereços no espaço roteável são atribuídos aos componentes front-end.
- Pode usar o espaço de endereço não roteável, que são os intervalos de endereços que 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 pouso. 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ço IP sobrepostos. Blocos de endereço não roteáveis não podem ser atribuídos a uma zona de aterrissagem falada. O emparelhamento de rede virtual não é transitivo, portanto, uma rede virtual falada em zona de aterrissagem pode emparelhar com uma rede virtual falada de segundo nível que tenha um espaço de endereçamento não roteável. O diagrama a seguir mostra a topologia de rede virtual dupla para zonas de aterrissagem.
Transfira um ficheiro PowerPoint desta arquitetura.
Cada zona de aterrissagem de 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 pouso roteável conversou com o hub regional. A zona de pouso não roteável falava com a zona de pouso roteável. O emparelhamento de rede virtual não é transitivo, portanto, os prefixos não roteáveis não são visíveis para o hub regional ou para o resto 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çamento fragmentado que já está atribuído a redes roteáveis. Pode ser um desafio identificar blocos de endereços grandes 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çamento RFC 1918. O diagrama anterior fornece um exemplo de endereços NAT de nível de operadora, como RFC 6598, em redes virtuais não roteáveis.
Migração de zona de aterrissagem de rede virtual única
O emparelhamento de rede virtual fornece conectividade de camada 3 completa entre duas redes virtuais emparelhadas. Os componentes de aplicativos implantados em zonas de aterrissagem de rede virtual única tradicional que se comunicam entre si por IP podem ser movidos livremente entre redes virtuais roteáveis e não roteáveis em uma zona de aterrissagem. 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 aplicativos de camada 7:
Transfira um ficheiro PowerPoint desta arquitetura.
Os aplicativos expostos por meio de controladores de entrega de aplicativos de camada 7 podem ser movidos para o raio não roteável. O controlador de entrega de aplicativos é o único componente front-end que deve residir na zona de aterrissagem roteável falada.
Os seguintes aplicativos são expostos por meio de um balanceador de carga do Azure:
Transfira um ficheiro PowerPoint desta arquitetura.
Se um aplicativo expõe 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 devem permanecer na mesma rede virtual. Os balanceadores de carga do Azure dão suporte apenas a instâncias 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 ou receber conexões de entrada da rede corporativa, mas geralmente têm dependências de saída. Os componentes back-end podem precisar se conectar a pontos de extremidade que estão fora de suas zonas de aterrissagem em instâncias como resolução DNS, controladores de domínio dos Serviços de Domínio Ative Directory, acesso a pontos de extremidade de aplicativos expostos por outras zonas de aterrissagem ou acesso a recursos de log ou backup.
Nota
A comunicação entre cliente e controladores de domínio (DCs) dos Serviços de Domínio Ative Directory (ADDS) por NAT foi testada e é suportada, a comunicação entre DC e DC não foi testada e não é suportada, conforme detalhado em Descrição dos limites de suporte para o Ative Directory sobre NAT
Quando os serviços iniciam conexões em redes virtuais não roteáveis, você deve implementar o NAT de origem (SNAT) para conexões atrás de um endereço IP roteável. Para implementar o SNAT, implante um dispositivo compatível com NAT na rede virtual routable spoke. Cada zona de pouso executa seu próprio NVA NAT dedicado. Há duas opções para implementar o SNAT em uma zona de aterrissagem: Firewall do Azure ou NVAs de terceiros. Em ambos os casos, todas as sub-redes na fala não roteável devem ser associadas a uma tabela de rotas personalizada. Como mostrado no diagrama a seguir, a tabela de rotas encaminha o tráfego para destinos fora da zona de pouso para o dispositivo SNAT. O Gateway NAT do Azure não suporta SNAT para tráfego destinado ao espaço de endereço IP privado, como o espaço RFC 1918.
Transfira um ficheiro PowerPoint desta arquitetura.
Implementar SNAT através do Firewall do Azure
Firewall do Azure:
- Fornece alta disponibilidade.
- Fornece escalabilidade nativa e três SKUs diferentes. SNAT não é uma tarefa que consome muitos recursos, então considere o SKU básico primeiro. Para zonas de aterrissagem que exigem grandes volumes de tráfego de saída do espaço de endereçamento não roteável, use a SKU padrão.
- Executa SNAT para o 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 aterrissagem para implementar o SNAT em uma topologia de rede hub-and-spoke usando o Firewall do Azure.
Transfira um ficheiro PowerPoint desta arquitetura.
Você deve associar todas as sub-redes na fala não roteável a uma tabela de rotas personalizada para enviar tráfego para destinos fora da zona de aterrissagem para o Firewall do Azure.
O diagrama a seguir mostra o layout da zona de aterrissagem para implementar o SNAT em uma rede hub-and-spoke baseada em WAN virtual usando o Firewall do Azure.
Transfira um ficheiro PowerPoint desta arquitetura.
Você deve associar todas as sub-redes no raio não roteável, ou os raios que não estão conectados à WAN Virtual, a uma tabela de rotas personalizada para enviar tráfego para destinos fora da zona de aterrissagem para o Firewall do Azure.
Para ambos os layouts, para fornecer recursos no acesso falado não roteável a endereços IP roteáveis fora de sua zona de aterrissagem, você deve implantar o Firewall do Azure com a opção Executar SNAT definida como Sempre no raio roteável de cada zona de aterrissagem. Você pode encontrar instruções sobre como configurar o Firewall do Azure para implementar o 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 não roteáveis.
Implemente o 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 scale-in e scale-out.
- Controle granular do pool 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 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 não roteável para os NVAs. Uma regra de balanceamento de carga de porta de alta disponibilidade é necessária porque o cluster implementa o SNAT em todas as conexões que saem da zona de aterrissagem. O Azure Standard Load Balancer dá suporte a regras de balanceamento de carga de porta de alta disponibilidade.
- A pilha SDN do Azure suporta NVAs de braço único e duplo. Os NVAs de braço único são preferidos porque reduzem o consumo de espaço de endereçamento nas redes virtuais de raios roteáveis.
O diagrama a seguir mostra o layout da zona de aterrissagem para implementar o SNAT em uma topologia de rede hub-and-spoke usando NVAs de terceiros.
Transfira um ficheiro PowerPoint desta arquitetura.
O diagrama a seguir mostra o layout da zona de aterrissagem para implementar o SNAT em uma topologia de rede hub-and-spoke baseada em WAN virtual usando NVAs de terceiros.
Transfira um ficheiro PowerPoint desta arquitetura.
Para ambos os layouts NVA de terceiros, você deve implantar várias instâncias atrás de um balanceador de carga do Azure para fornecer alta disponibilidade. O SKU padrão do Azure Load Balancer é necessário.
Método 2: Serviços de Link Privado do Azure
O Private Link fornece acesso a aplicativos implantados em uma rede virtual que não está conectada à sua rede virtual. Na rede virtual do lado do servidor, ou aplicativo, um serviço de Link Privado é implantado e associado a um ponto de extremidade do aplicativo exposto no endereço IP front-end de um balanceador de carga SKU padrão interno do Azure. Na rede virtual do lado 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 Private Link fornece o encapsulamento 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, consulte O que é o Azure Private Link?
O Private Link não requer uma conexão de camada 3 entre a rede virtual do lado do cliente e a rede virtual do lado do servidor. As duas redes virtuais podem ter espaços de endereços IP sobrepostos. O Private Link permite a implantação de aplicativos em redes virtuais dedicadas e isoladas, todas elas usando o mesmo espaço de endereçamento 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çamento roteável. No contexto da arquitetura da zona de aterrissagem do Azure, a topologia da zona de aterrissagem resultante tem:
- Uma rede virtual isolada que hospeda todo o aplicativo e o serviço Private Link associado aos pontos de extremidade do aplicativo. A equipe do aplicativo define o espaço de endereço da rede virtual.
- Uma rede virtual spoke com um espaço de endereçamento roteável que hospeda o ponto de extremidade privado associado ao serviço Private Link. A rede virtual falada é diretamente emparelhada com o hub regional.
O diagrama a seguir mostra a topologia da zona de aterrissagem habilitada para Link Privado.
Transfira um ficheiro PowerPoint desta arquitetura.
Usar um serviço de Link Privado para dependências de saída
Ao implantar aplicativos em redes virtuais de raios isolados, use um serviço de Link Privado para dependências de saída. Defina pontos de extremidade privados na rede virtual de raios isolados e associe-os a um serviço de Link Privado em redes virtuais roteáveis. O diagrama a seguir mostra a abordagem conceitual.
Transfira um ficheiro PowerPoint desta arquitetura.
Em implementações reais de grande escala, o método Private Link pode 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 podem fazer parte de um pool de back-end do Balanceador de Carga do Azure, o Private Link não será aplicável.
Para superar essas duas limitações, implante uma solução proxy/NAT no raio roteável e torne-a acessível a partir da rede virtual isolada usando o Private Link.
Transfira um ficheiro PowerPoint desta arquitetura.
Use um único ponto de extremidade privado ou serviço de Link Privado para expor uma solução proxy/NAT implantada na rede roteável. As regras de tradução de portas e de endereços 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.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Principais autores:
- Federico Guerrini - Brasil | Líder Técnico EMEA
- Khush Kaviraj - Brasil | Arquiteto de Soluções Cloud
- Jack Tracey - Brasil | Arquiteto de Soluções Cloud Sênior
Outros contribuidores:
- Jodi Martis - Brasil | Redator Técnico
Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.
Próximos passos
- Implantar o Firewall do Azure em uma rede virtual
- Configurar o SNAT no Firewall do Azure
- Endereços IP suportados na Rede Virtual do Azure
- Azure Private Link
- Balanceador de Carga do Azure
- Peering de rede virtual