Fase de projeto 3: Conectividade de entrada com a Internet
As escolhas feitas durante essa fase de design são determinadas pelos requisitos dos aplicativos em execução na Solução VMware do Azure que devem estar acessíveis por endereços IP públicos. Quase invariavelmente, os aplicativos voltados para a Internet são publicados por meio de dispositivos de rede que fornecem segurança (firewalls de última geração, firewalls de aplicativos Web) e balanceamento de carga (balanceadores de carga de Camada 3 ou Camada 4, controladores de entrega de aplicativos). Você pode implantar esses dispositivos na própria nuvem privada ou em uma rede virtual do Azure conectada à nuvem privada. Sua escolha é baseada nestas considerações:
- Para otimização de custos e consistência, você pode usar NVAs pré-existentes implantados em redes virtuais do Azure (como firewalls e controladores de entrega de aplicativos) para publicar aplicativos em execução em suas nuvens privadas.
- Os serviços de PaaS do Azure que podem ser usados para publicar aplicativos voltados para a Internet, como o Firewall do Azure (quando implantado em uma rede virtual gerenciada pelo cliente e quando implantado em um hub de WAN Virtual do Azure) e o Gateway de Aplicativo do Azure, podem ajudar a reduzir a sobrecarga de gerenciamento.
- Você pode implantar firewalls e controladores de entrega de aplicativos como dispositivos virtuais na Solução VMware do Azure, se isso for suportado pelo fornecedor.
O fluxograma a seguir resume como abordar essa fase:
NVAs hospedados em uma rede virtual do Azure
A publicação de aplicativos da Solução VMware do Azure por meio de serviços do Azure (Firewall do Azure, Gateway de Aplicativo) ou NVAs de terceiros hospedados em uma rede virtual requer apenas conectividade de Camada 3 entre a rede virtual e a nuvem privada da Solução VMware do Azure. Para obter mais informações, consulte Fase de design 2: conectividade com redes virtuais do Azure.
As seções a seguir fornecem orientações para cada opção.
Considerações sobre o Firewall do Azure
O Firewall do Azure é a opção preferencial para expor pontos de extremidade TCP ou UDP genéricos por meio de um dispositivo Microsoft Layer 3 ou layer 4. Para publicar um aplicativo da Solução VMware do Azure por meio do Firewall do Azure, você precisa configurar uma regra de Conversão de Endereço de Rede de Destino (DNAT) que mapeie um dos IPs públicos do firewall para o IP privado do ponto de extremidade do aplicativo Solução VMware do Azure. O Firewall do Azure usa automaticamente a Conversão de Endereço de Rede de Origem (SNAT) para converter endereços IP recebidos da Internet para seu próprio endereço IP privado. Como resultado, as máquinas virtuais (VMs) da Solução VMware do Azure recebem tráfego cujo endereço IP de origem é o IP do firewall. Para obter mais informações, consulte Filtrar o tráfego de entrada da Internet com o DNAT do Firewall do Azure usando o portal do Azure.
Considerações sobre o Gateway de Aplicativo do Azure
O Gateway de Aplicativo é a opção preferencial para expor aplicativos HTTP(S) em execução na Solução VMware do Azure. Este proxy reverso HTTP da Microsoft fornece:
- Roteamento de solicitação HTTP.
- Recursos de WAF (Web Application Firewall).
Quando você usa o Gateway de Aplicativo, os servidores de aplicativos em execução na nuvem privada da Solução VMware do Azure recebem tráfego cujo endereço IP de origem é o IP do gateway de aplicativo. O endereço IP do cliente pode ser transportado em solicitações HTTP (normalmente como um cabeçalho x-forwarded-for personalizado) se a lógica do aplicativo exigir acesso a essas informações. Para obter mais informações, consulte este artigo sobre como publicar um aplicativo de solução VMware do Azure por meio do Gateway de Aplicativo.
Observação
O Gateway de Aplicativo é atualmente o único balanceador de carga da Microsoft que você pode usar para expor aplicativos Web em execução em VMs de Solução VMware do Azure. Isso ocorre porque ele permite que você aponte diretamente para os endereços IP privados de VMs em execução no Azure VMware Solution ao configurar os pools de back-end das VMs.
Considerações sobre NVAs de terceiros
NVAs de terceiros podem fornecer recursos de firewall de Camada 3 ou Camada 4 ou recursos de proxy reverso/WAF de Camada 7. Siga as orientações do fornecedor NVA para implantar o dispositivo nas redes virtuais do Azure. Orientações detalhadas sobre como criar clusters altamente disponíveis de NVAs no Azure estão além do escopo deste guia. As seguintes considerações de alto nível são gerais o suficiente para se aplicar a qualquer tecnologia NVA:
- A alta disponibilidade (HA) é de sua responsabilidade. Os clusters NVA devem incluir duas ou mais instâncias NVA ativas (o modelo N-active HA). Você deve evitar HA ativo-passivo porque impede a escalabilidade horizontal.
- Você deve distribuir todas as conexões de entrada da Internet para todas as instâncias em execução usando um SKU padrão do Azure Load Balancer.
- Os NVAs de Camada 3 e Camada 4 devem ser configurados para usar o DNAT para converter conexões de entrada da Internet para o IP privado do aplicativo Solução VMware do Azure que você deseja publicar.
- Para preservar a simetria do fluxo, você precisa configurar os NVAs de Camada 3 e Camada 4 para usar o SNAT para converter conexões de entrada da Internet para o endereço IP privado da interface de saída.
- Os NVAs de camada 7 atuam como proxies reversos e mantêm duas sessões TCP distintas para cada conexão de cliente de entrada: uma entre o cliente e o NVA e outra entre o NVA e o servidor de aplicativos upstream. A última sessão se origina do endereço IP privado da interface de saída NVA. Os aplicativos HTTP(S) permitem que os NVAs de Camada 7 passem o endereço IP público do cliente para os servidores de aplicativos em cabeçalhos de solicitação HTTP.
NVAs hospedados na Solução VMware do Azure (IP público na borda do data center NSX-T)
Para publicar aplicativos da Solução VMware do Azure por meio de NVAs de terceiros implantados na Solução VMware do Azure, você precisa habilitar o IP Público na Borda do Data Center NSX-T para a nuvem privada. Esse recurso associa IPs Públicos do Azure de um prefixo IP Público do Azure à nuvem privada e configura o backbone da Microsoft para rotear o tráfego da Internet destinado a esses IPs para os gateways NSX-T T0 ou T1 da nuvem privada. Os gateways T1 podem ser configurados para usar DNAT para converter conexões de entrada para IPs privados de NVAs conectados a segmentos NSX-T. Para obter orientação sobre como configurar o IP público na borda do data center NSX-T e configurar regras DNAT para conectividade de entrada com a Internet, consulte Habilitar IP público na borda do data center NSX-T. Quando você usa a Solução VMware do Azure com IP Público na Borda do Data Center NSX-T, as seguintes considerações se aplicam:
- Execute NAT em gateways T1, não em gateways T0. Nas nuvens privadas do Azure VMware Solution, os gateways T0 são pares de dispositivos ativos-ativos, portanto, não podem lidar com sessões NAT com monitoração de estado.
- Você precisa associar IPs Públicos a um prefixo de IP Público do Azure. No momento, não há suporte para o uso de IPs de prefixos de endereço IP personalizados (BYOIP).
- Quando uma nuvem privada da Solução VMware do Azure é configurada com IP Público na Borda do Data Center NSX-T, uma rota padrão é instalada nos gateways T0/T1. Ele roteia conexões de internet de saída através da borda do backbone da Microsoft. Como resultado, o uso de IP público na borda do data center NSX-T para conectividade de entrada com a Internet também determina a opção de implementação para conectividade de saída, que é abordada no próximo artigo deste guia.
Próximas etapas
Saiba mais sobre a conectividade de saída com a Internet.