Vnet Integration - Azure

Vou descrever um pouco do recurso Vnet Integration do App Service com cenário prático. Ele permite que um App Service acesse recursos de uma vnet.

Alguns exemplos de uso:

• Key Vaul com acesso público bloqueado. Podemos configurar um service endpoint. Cenário visando segurança.
• Pode ser usado para acessar um servidor SQL IAAS usando um ip privado.
• Acessar de forma segura um recurso em outra vnet configurada com peering.

Deixei um script bash para ser executado no Cloud Shell.

Esse é o cenário que teremos após a conclusão do script. O objetivo será fazer o App Service se comunicar com os recursos da vnet-lan1 e 2 via Vnet Integration. App Service está na mesma região da vnet-lan1.

Acesse App Service e clique no menu Networking. Em Outbound Traffic, clique em Vnet integration.

Clique em Add Vnet.

Antes de seguir para próxima tela, temos dois pontos importantes. O vnet intregation tem duas formas de trabalhar. Tudo vai depender da sua necessidade.

Gateway-required virtual network integration

Existe a possibilidade do App Service se conectar à uma subnet em outra região, mas para isso é necessário um Virtual Network Gateway na região de destino. A conexão deve ser via Point to Site.

Algumas informações sobre o Gateway-required virtual network integration:

• Permite que um aplicativo se conecte a apenas uma rede virtual por vez.
• Permite que até cinco vnets sejam integradas em um plano do App Service.
• Permite que a mesma vnet seja usada por vários aplicativos em um plano do App Service sem afetar o número total que pode ser usado por um plano. Se você tiver seis aplicativos usando a mesma vnet no mesmo plano, isso conta como uma vnet sendo usada.
• O SLA no gateway pode afetar o SLA geral.
• Permite que seus aplicativos usem o DNS com o qual a vnet está configurada.
• Requer um gateway baseado em rota configurado com uma VPN P2S antes de poder ser conectado a um aplicativo.

Mais detalhes no link abaixo:

Voltando para a tela de configuração. Observe que a vnet-lan2 aparece como opção e com a indicação de um Gateway de VPN como requisito. Lembrando que o App Service está na região Korea Central e a vnet-lan2 está em France Central. Não iremos trabalhar com essa opção nesse lab. Escolha vnet-lan1 e avance.

Regional virtual network integration

Dá suporte à conexão a uma rede virtual na mesma região e não requer um gateway. Permite que seu aplicativo acesse:

• Recursos na vnet com a qual você está integrado.
• Recursos em vnets emparelhadas com a vnet à qual seu aplicativo está integrado, incluindo conexões de emparelhamento global.
• Recursos nas conexões do Azure ExpressRoute.
• Serviços protegidos por ponto de extremidade de serviço.
• Serviços habilitados para ponto de extremidade privado.

Não dá suporte:

• A montagem de uma unidade.
• Ingressar em um domínio.
• NetBIOS.

Podemos usar os seguintes recursos de rede do Azure:

• NSG: você pode bloquear o tráfego de saída com um NSG que é colocado em sua sub-rede de integração. As regras de entrada não se aplicam porque você não pode usar a integração de rede virtual para fornecer acesso de entrada ao seu aplicativo.
• UDR: você pode inserir uma tabela de rotas na sub-rede de integração para enviar o tráfego de saída para onde desejar.

Essa é a opção que iremos focar. A subnet que iremos conectar o App Service não pode ter recursos nela. Podemos reparar que a sub-lan, que possui a VM, não fica disponível como opção. Escolha sub-vintegration e salve. O App Service será reiniciado.

Vnet Integration habilitado. Clique no "x" no canto direito superior e iremos voltar para a tela Networking.

Pode ocorrer uma leve confusão no uso do Vnet Integration e essa tela pode ajudar no entendimento. Vimos na tela anterior que o App Service agora pode usar a sub-vintegration para se comunicar com a VM. Nisso pode surgir o pensamento que o App Service ganhou uma placa de rede com um ip privado e pode ser acessado internamente por ela. Na verdade, isso lembra outro recurso existente no Azure. O Private Endpoint (PVE). Ele recebe uma placa de rede e um ip privado de uma subnet para obter conexão de entrada. Já no Vnet Integration, temos um tráfego de saída.

Repare na imagem. Veja que o PVE está em Inbound Traffic e o Vnet Integration em Outbound Traffic. Com a configuração que aparece na tela, o tráfego de entrada só é possível via ip público. Se for necessário ter um tráfego de entrada via ip privado, um PVE precisa ser configurado.

Digamos que por baixo exista uma placa de rede, mas não aparece como um recurso. É possível verificar o ip atribuído pelo console do Kudu. Acesse o menu Advanced Tools e clique em Go.

Clique em Environment e procure a variável WEBSITE_PRIVATE_IP. A documentação informa que esse ip muda e para trabalhar com um NSG, deve informar o intervalo de endereços da subnet delegada para o App Service.

Hora dos testes! Antes quero detalhar algumas configurações feita nas VMs pelo script.

Regras de entrada foram configuradas para comunicação na porta 80. Cada vm tem o IIS instalado.

No App Service, clique no menu Console. O comando tcpping ajuda a testar a conectividade com as VMs. Podemos ver que a comunicação foi feita com sucesso.

Objetivo realizado com sucesso. Espero que tenha sido útil para os estudos.

Até o próximo artigo!

Links de referência: