Evitar o esgotamento do IPv4 no Azure

As redes corporativas normalmente usam espaços de endereços dos intervalos de endereços IPv4 privados definidos pela RFC (Request for Comments) 1918, como 10.0.0.0/8, 172.16.0.0/12e 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 endereços IP. Eles geralmente não priorizam o uso eficiente do espaço de endereçamento IPv4.

Na nuvem, grandes redes são fáceis de construir. Alguns padrões de arquitetura comuns, como microsserviços ou conteinerização, podem levar ao aumento do consumo de endereços IPv4. Portanto, é importante adotar práticas mais conservadoras de gerenciamento de endereços e tratar os endereços IPv4 como um recurso limitado.

Este artigo descreve dois métodos para minimizar o consumo de espaço de endereçamento IPv4 quando você cria grandes redes no Azure. Os métodos dependem de topologias de rede que reutilizam os mesmos blocos de endereços IPv4 em várias redes virtuais ou zonas de aterrissagem.

• Método 1: Use o emparelhamento de sub-rede IPv4 para excluir uma ou mais sub-redes do emparelhamento entre a rede virtual spoke da zona de aterragem e a rede virtual do hub. Pode atribuir os mesmos intervalos de endereços IP não roteáveis às sub-redes excluídas da relação de peering em todas as zonas de destino. Esses intervalos de endereços IP não podem se sobrepor a outros intervalos de endereços IP roteáveis.

• Método 2: Implante aplicativos em redes virtuais isoladas que não estejam conectadas às redes virtuais das zonas de aterrissagem. Associe seus pontos de extremidade aos serviços de Link Privado do Azure. Nas redes virtuais do tipo spoke das zonas de aterrissagem, crie pontos de extremidade privados associados aos serviços de Private Link. As redes virtuais isoladas podem usar qualquer espaço de endereçamento IPv4, mesmo que ele se sobreponha ao espaço de endereçamento roteável da rede corporativa.

O método 1 funciona melhor em ambientes empresariais tradicionais, onde vários sistemas e aplicativos dependem uns dos outros. O método 2 funciona melhor em ambientes de acoplamento flexível onde os aplicativos operam de forma independente.

Alinhamento da zona de aterrissagem do Azure

As recomendações neste artigo aplicam-se a topologias de rede baseadas na arquitetura da zona de aterrissagem do Azure:

• Cada região que hospeda recursos do Azure tem uma rede hub-and-spoke.

• Redes Hub-and-spoke em diferentes regiões se conectam por meio de emparelhamento de rede virtual global.

• As redes Hub-and-spoke conectam-se a sites locais por meio de circuitos de Rota Expressa do Azure ou VPNs site a site.

Na arquitetura da zona de aterrissagem do Azure, cada aplicativo é executado em sua própria rede virtual falada. Cada rede virtual spoke usa um espaço de endereçamento IPv4 exclusivo em toda a rede corporativa.

Todos os recursos em uma zona de pouso podem se conectar das seguintes maneiras:

• Use seu endereço IP para iniciar conexões com quaisquer outros recursos na rede corporativa

• Receba conexões diretas de toda a rede corporativa através de seu endereço IP

No entanto, os recursos nem sempre precisam de acessibilidade de toda a rede corporativa. Por exemplo, em uma zona de aterrissagem que contém um aplicativo Web de três camadas, como um front-end HTTP, lógica de negócios e camada de dados, somente o front-end HTTP deve ser acessível de fora da zona de aterrissagem. As outras camadas devem se conectar entre si e com o front-end, mas não precisam aceitar conexões de clientes. Este exemplo sugere que você pode minimizar o consumo de endereços IPv4 atribuindo os seguintes componentes a cada zona de aterrissagem:

• Um espaço de endereçamento único em toda a rede corporativa. Somente os recursos que devem ser acessíveis de fora de sua zona de pouso usam esse espaço de endereço. Este artigo refere-se a esse espaço de endereçamento como o espaço de endereçamento roteável da zona de pouso.

• Um espaço de endereçamento interno para recursos que só precisam se comunicar com outros recursos dentro de sua própria zona de pouso. Esse espaço de endereçamento não requer acessibilidade direta da rede corporativa. Este artigo refere-se a este espaço de endereçamento como o espaço de endereçamento não encaminhável da zona de aterragem.

Nas seções a seguir, o componente front-end refere-se a um componente de aplicativo que deve ser acessível a partir de toda a rede corporativa. 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 estar acessível dentro de sua própria zona de aterrissagem.

Método 1: Sub-redes não roteáveis em redes virtuais faladas

Você pode usar o emparelhamento de sub-rede IPv4 para restringir uma relação de emparelhamento entre duas redes virtuais a sub-redes específicas. Somente as sub-redes incluídas na configuração de emparelhamento podem rotear tráfego umas para as outras. As sub-redes excluídas da configuração de emparelhamento permanecem invisíveis e inacessíveis a partir da rede virtual de mesmo nível.

Em uma topologia hub-and-spoke, se você excluir uma ou mais sub-redes em cada spoke da configuração de emparelhamento, essas sub-redes permanecerão invisíveis e inacessíveis a partir do hub e de qualquer rede remota conectada ao hub por meio de outros pares, conexões ExpressRoute ou conexões VPN. Portanto, você pode atribuir o mesmo intervalo de endereços a todas as sub-redes excluídas da configuração de emparelhamento em todas as redes virtuais faladas. Esse intervalo deve ser definido como não roteável e não pode ser usado em mais lado nenhum na rede corporativa.

O diagrama a seguir inclui estes componentes:

• O intervalo 10.57.0.0/16 serve como o espaço de endereçamento não roteável.

• A rede virtual do hub e cada rede virtual falada da zona de aterrissagem usam intervalos de endereços IP roteáveis exclusivos (10.0.0.0/24, 10.1.0.0/24e 10.2.0.0/24).

• Cada rede virtual em roda de zona de aterragem contém também uma ou mais sub-redes não roteáveis dentro do intervalo não roteável 10.57.0.0/16. O espaço de endereço de uma rede virtual do Azure pode incluir vários intervalos de endereços IP.

• Essas sub-redes são excluídas da relação de emparelhamento com o hub. Assim, sub-redes não roteáveis em diferentes zonas de destino podem ter os mesmos intervalos de endereços ou intervalos sobrepostos dentro de 10.57.0.0/16.

Descarregue um ficheiro PowerPoint relativo a esta arquitetura.

Essa abordagem preserva a conectividade total dentro da rede virtual falada de uma zona de pouso. Todos os recursos na mesma rede virtual em estrela podem ligar-se entre si, independentemente de residirem em sub-redes roteáveis ou não roteáveis. No entanto, apenas recursos em sub-redes roteáveis podem se conectar a recursos fora de sua própria zona de pouso.

Implantar aplicativos em zonas de aterrissagem

Quando usa peering de sub-redes para construir zonas de aterragem com sub-redes não encaminháveis, pode aplicar diferentes padrões para distribuir os componentes front-end e back-end de uma aplicação entre sub-redes roteáveis e não encaminháveis. As considerações a seguir se aplicam a aplicativos recém-criados e aplicativos migrados de zonas de aterrissagem tradicionais que usam um único espaço de endereçamento totalmente roteável.

• Aplicativos expostos por meio de controladores de entrega de aplicativos Layer-7: Esses controladores de entrega de aplicativos incluem o Gateway de Aplicativo do Azure ou NVAs (dispositivos virtuais de rede) que não são da Microsoft. Somente o endpoint do controlador de entrega de aplicações deve ser conectável a partir de clientes fora da zona de aterrissagem. Portanto, o controlador de entrega de aplicativo é o único componente front-end que deve residir em uma sub-rede roteável.

• Aplicativos expostos por meio de um balanceador de carga do Azure: Se o aplicativo usar um balanceador de carga interno do Azure, as máquinas virtuais no pool de back-end do balanceador de carga deverão residir em uma sub-rede roteável. Podes implantar todos os outros componentes em sub-redes não encaminháveis.

O diagrama a seguir mostra esses padrões:

• A zona de aterrissagem A hospeda um aplicativo Web de três camadas exposto por meio de um controlador de entrega de aplicativo, que é o único componente na sub-rede roteável.

• A zona de aterrissagem B hospeda um aplicativo de três camadas exposto por meio de um balanceador de carga interno do Azure.

Descarregue um ficheiro PowerPoint relativo a esta arquitetura.

Dependências de saída

Os componentes back-end de um aplicativo não precisam receber conexões de entrada da rede corporativa. Mas eles podem precisar iniciar conexões com pontos finais fora de sua zona de pouso. Exemplos típicos incluem resolução de DNS (Sistema de Nomes de Domínio), interação com controladores de domínio dos Serviços de Domínio Ative Directory (AD DS) e acesso a aplicativos em outras zonas de aterrissagem ou serviços compartilhados, como gerenciamento de logs ou sistemas de backup.

Quando recursos em sub-redes não encaminháveis precisam de iniciar ligações a terminais fora da sua zona de aterragem, essas ligações devem usar NAT de origem (SNAT) atrás de um endereço IP roteável. Portanto, você deve implantar um NVA compatível com NAT em uma sub-rede roteável em cada zona de aterrissagem. O diagrama a seguir mostra essa configuração.

Descarregue um ficheiro PowerPoint relativo a esta arquitetura.

As sub-redes não roteáveis devem usar uma tabela de rotas personalizada que encaminhe todo o tráfego destinado fora da zona de pouso para o NVA compatível com NAT. No diagrama anterior, o intervalo 10.57.0.0/16 não é roteável, enquanto outros intervalos dentro 10.0.0.0/8 são roteáveis. A tabela de rotas personalizada para cada subrede não encaminhável deve conter a seguinte rota, definida pelo utilizador (UDR).

A tabela de encaminhamento do sistema da rede virtual já inclui uma rota de sistema para destinos na faixa não encaminhável 10.57.0.0/16. Não é necessário definir UDRs para o tráfego dentro desse intervalo.

As sub-redes roteáveis, incluindo a sub-rede que hospeda o NVA compatível com NAT, devem usar uma tabela de rotas personalizada que encaminhe o tráfego para fora da zona de aterrissagem, normalmente para NVAs na rede virtual do hub. Esses NVAs roteiam o tráfego entre as terminais. Esses NVAs de hub não executam operações NAT. No diagrama anterior, a tabela de rotas personalizada para cada sub-rede roteável deve conter as seguintes UDRs.

O segundo UDR com destino 10.0.0.0/24 garante que as conexões com recursos na rede virtual do hub sejam encaminhadas através do firewall do hub. Alguns aplicativos podem exigir mais UDRs. Se as máquinas virtuais na zona de aterrissagem precisarem de acesso à Internet por meio de NVAs normalmente hospedados no hub, você também deverá definir uma rota padrão de 0.0.0.0/0.

Você pode usar o Firewall do Azure ou NVAs que não sejam da Microsoft como dispositivos compatíveis com NAT. As seções a seguir abrangem ambas as opções. Você não pode usar o Gateway NAT do Azure porque ele só dá suporte ao SNAT para tráfego vinculado à Internet.

Implementar SNAT através do Firewall do Azure

Quando precisar priorizar baixa complexidade e gestão mínima, o Azure Firewall oferece a melhor solução para implementar SNAT para ligações que se originam de sub-redes não encaminháveis. O Firewall do Azure fornece os seguintes benefícios:

• Ciclo de vida totalmente gerenciado
• Disponibilidade elevada incorporada
• Dimensionamento automático com base no volume de tráfego

Ao usar o Firewall do Azure, considere os seguintes fatores:

• Implante o Firewall do Azure em sua própria sub-rede reservada chamada AzureFirewallSubnet, que deve usar um espaço de endereçamento roteável.

• Algumas SKUs ou configurações do Firewall do Azure podem exigir uma segunda sub-rede reservada para gerenciamento de firewall. A sub-rede de gerenciamento não requer um espaço de endereçamento roteável.

• O Firewall do Azure tem três SKUs diferentes. O SNAT não consome muitos recursos, então comece com o SKU básico. Para zonas de chegada que geram grandes volumes de tráfego de saída a partir de sub-redes não roteáveis, considere o SKU Padrão.

• Configure o Firewall do Azure com a opção Executar SNAT definida como Sempre. Cada instância usa as suas portas não privilegiadas para SNAT. Para configurar o Firewall do Azure para implementar o SNAT em todas as conexões recebidas, siga as etapas de configuração do SNAT.

• Associe todas as subredes não encaminháveis a uma tabela de rotas personalizada que encaminhe todo o tráfego destinado para fora da zona de aterragem para o endereço IP privado do firewall.

O diagrama seguinte mostra uma rede hub-and-spoke onde cada spoke utiliza o Azure Firewall para fornecer SNAT para ligações a partir de sub-redes não encaminháveis.

Descarregue um ficheiro PowerPoint relativo a esta arquitetura.

Implementar SNAT através de NVAs não-Microsoft

Você pode encontrar NVAs que não sejam da Microsoft com recursos NAT no Azure Marketplace. Considere usar um NVA que não seja da Microsoft se seus requisitos excederem o que o Firewall do Azure pode suportar. Por exemplo, você pode precisar dos seguintes recursos:

• Controle granular sobre o pool NAT

• Políticas NAT personalizadas, por exemplo, você pode precisar usar endereços NAT diferentes para conexões diferentes

• Controle granular sobre a escalabilidade, incluindo escala de entrada (scale-in) e escala de saída (scale-out)

Ao usar NVAs que não sejam da Microsoft, considere os seguintes fatores:

• Implemente um cluster que possua pelo menos duas NVAs para garantir elevada disponibilidade.

• Use um balanceador de carga padrão SKU Azure para distribuir ligações da rede virtual de raios não roteável para os NVAs. Todas as conexões devem usar SNAT independentemente da porta de destino, portanto, você deve usar regras de balanceamento de carga de alta disponibilidade, também conhecidas como regras de balanceamento de carga de qualquer porta.

• Escolha entre configurações de braço único e braço duplo para NVAs compatíveis com NAT. As configurações de braço único são mais simples e geralmente recomendadas.

O diagrama a seguir mostra agora como implementar o SNAT em uma topologia de rede hub-and-spoke usando NVAs que não sejam da Microsoft.

Descarregue um ficheiro PowerPoint relativo a esta arquitetura.

Usar o Método 1 com a WAN Virtual do Azure

A WAN Virtual do Azure não oferece suporte ao emparelhamento de sub-rede. Assim, não é possível criar redes virtuais de zona de aterrissagem que tenham sub-redes não encaminháveis em redes hub e spoke baseadas em Virtual WAN. No entanto, você ainda pode aplicar o princípio fundamental do Método 1 usando duas redes virtuais emparelhadas para cada zona de pouso.

• Atribua um espaço de endereçamento roteável à primeira rede virtual e conecte-o ao hub WAN Virtual.

• Atribui um espaço de endereçamento não roteável à segunda rede virtual e estabelece uma conexão com a rede virtual roteável.

O diagrama a seguir mostra a topologia resultante.

Descarregue um ficheiro PowerPoint relativo a esta arquitetura.

Essa abordagem não limita a conectividade dentro de uma zona de pouso. As duas redes virtuais na zona de destino são diretamente interligadas, pelo que todos os recursos podem conectar-se entre si, independentemente de residirem numa rede virtual roteável ou não roteável. No entanto, apenas os recursos na rede virtual roteável podem se conectar a recursos fora da zona de pouso.

Do ponto de vista do roteamento, não há diferença entre as seguintes configurações:

• Subredes roteáveis e não roteáveis na mesma rede virtual (descritas na secção anterior para redes tradicionais hub-and-spoke)

• Redes virtuais emparelhadas diretamente (descritas nesta seção para redes hub-and-spoke baseadas em WAN Virtual)

Como resultado, em redes baseadas em WAN virtual, aplicam-se as seguintes orientações:

• Pode distribuir componentes da aplicação entre sub-redes roteáveis e não encaminháveis usando as mesmas considerações descritas nas secções anteriores.

• Você pode gerenciar dependências de saída com NVAs compatíveis com NAT em sub-redes roteáveis.

Método 2: Serviços de link privado

O Private Link permite que os clientes em uma rede virtual consumam aplicativos em uma rede virtual diferente sem configurar a conectividade de camada 3, como emparelhamento de rede virtual ou VPN de rede virtual para rede virtual. As duas redes virtuais podem usar intervalos de endereços IP sobrepostos. O Azure lida de forma transparente com a lógica NAT necessária. Esse método se aplica a redes hub-and-spoke tradicionais e redes baseadas em WAN virtual.

Para expor um aplicativo por meio do Private Link, execute as seguintes etapas:

1. Adicione os pontos de extremidade da aplicação ao pool de back-end de um balanceador de carga interno do Azure com o SKU Standard.

2. Associe o endereço IP front-end do balanceador de carga a um recurso de serviço Private Link.

3. No lado do cliente, crie um recurso de ponto de extremidade privado e associe-o ao serviço de link privado no lado do servidor.

Para consumir a aplicação, os clientes conectam-se ao ponto de extremidade privado. O Azure roteia de forma transparente a conexão para o endereço IP front-end do balanceador de carga associado ao serviço de Link Privado correspondente.

Você pode usar o Private Link para ajudar a reduzir o esgotamento do IPv4 atribuindo duas redes virtuais a cada zona de aterrissagem:

• Uma rede virtual que tem um espaço de endereçamento roteável, conectado à rede corporativa

• Uma rede virtual isolada, que tem um espaço de endereçamento escolhido arbitrariamente, que pode até se sobrepor ao espaço de endereçamento da rede corporativa

Implante aplicativos e os serviços de Link Privado que expõem seus pontos de extremidade nas redes virtuais isoladas. Implante os pontos de extremidade privados, que se conectam a esses serviços, nas redes virtuais roteáveis.

O diagrama a seguir mostra duas zonas de aterrissagem que usam um grande espaço 10.0.0.0/16de endereçamento, que se sobrepõe ao espaço de endereçamento da rede corporativa. Cada zona de aterragem atribui este espaço a uma rede virtual isolada. As aplicações são implantadas nas redes virtuais spoke isoladas e associadas aos serviços de Ligação Privada.

Descarregue um ficheiro PowerPoint relativo a esta arquitetura.

Os clientes na rede corporativa, incluindo clientes em outras zonas de destino, consomem os aplicativos por meio de pontos de extremidade privados associados aos serviços Private Link. O diagrama a seguir mostra como essas conexões são estabelecidas.

Descarregue um ficheiro PowerPoint relativo a esta arquitetura.

Usar um serviço de Link Privado para dependências de saída

Aplicações em redes virtuais isoladas não podem iniciar conexões com endereços de rede na rede corporativa. Portanto, o Método 2 funciona melhor para cenários em que aplicativos em diferentes zonas de pouso operam de forma independente e não dependem de sistemas na rede corporativa. No entanto, ainda pode aplicar este método quando aplicações em redes virtuais isoladas precisam aceder a endpoints específicos fora da sua zona de destino.

O diagrama a seguir mostra como um serviço de Link Privado permite que o aplicativo na rede virtual isolada na zona de aterrissagem A consuma um serviço compartilhado na rede virtual do hub e um ponto de extremidade do aplicativo na zona de aterrissagem B.

Descarregue um ficheiro PowerPoint relativo a esta arquitetura.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Principais autores:

• Federico Guerrini - Brasil | Arquiteto Sênior de Soluções na Nuvem, Líder Técnico EMEA Azure Networking
• Khush Kaviraj - Brasil | Arquiteto de Soluções Cloud
• Jack Tracey - Brasil | Arquiteto de Soluções Cloud Sênior

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Próximos passos

• Configurar emparelhamento de sub-rede
• 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
• Link Privado
• Balanceador de Carga do Azure
• Emparelhamento de rede virtual
• Topologia de rede hub-and-spoke

Recursos relacionados

• Design de arquitetura de rede
• Abordagens arquitetônicas para redes em soluções multilocatárias