Considerações sobre a rede para o Ambiente de Serviço de Aplicações

Importante

Este artigo é sobre o Ambiente do Serviço de Aplicativo v2, que é usado com os planos do Serviço de Aplicativo Isolado. O Ambiente do Serviço de Aplicativo v1 e v2 foi desativado a partir de 31 de agosto de 2024. Há uma nova versão do Ambiente do Serviço de Aplicativo que é mais fácil de usar e é executada em uma infraestrutura mais poderosa. Para saber mais sobre a nova versão, comece com a Introdução ao Ambiente do Serviço de Aplicativo. Se você estiver usando o Ambiente do Serviço de Aplicativo v1, siga as etapas neste artigo para migrar para a nova versão.

A partir de 31 de agosto de 2024, o Contrato de Nível de Serviço (SLA) e os Créditos de Serviço não se aplicam mais às cargas de trabalho do Ambiente do Serviço de Aplicativo v1 e v2 que continuam em produção, pois são produtos desativados. A desativação do hardware do Ambiente do Serviço de Aplicativo v1 e v2 começou, e isso pode afetar a disponibilidade e o desempenho de seus aplicativos e dados.

Você deve concluir a migração para o Ambiente do Serviço de Aplicativo v3 imediatamente ou seus aplicativos e recursos podem ser excluídos. Tentaremos migrar automaticamente qualquer Ambiente do Serviço de Aplicativo restante v1 e v2 com base no melhor esforço usando o recurso de migração in-loco, mas a Microsoft não faz nenhuma reivindicação ou garantia sobre a disponibilidade do aplicativo após a migração automática. Talvez seja necessário executar a configuração manual para concluir a migração e otimizar a escolha de SKU do plano do Serviço de Aplicativo para atender às suas necessidades. Se a migração automática não for viável, seus recursos e dados de aplicativos associados serão excluídos. Exortamo-lo vivamente a agir agora para evitar qualquer um destes cenários extremos.

Se você precisar de tempo adicional, podemos oferecer um período de carência único de 30 dias para que você conclua sua migração. Para obter mais informações e solicitar esse período de carência, revise a visão geral do período de carência e vá para o portal do Azure e visite a folha Migração para cada um dos seus Ambientes do Serviço de Aplicativo.

Para obter as informações mais atualizadas sobre a desativação do Ambiente do Serviço de Aplicativo v1/v2, consulte a atualização de desativação do Ambiente do Serviço de Aplicativo v1 e v2.

O Ambiente do Serviço de Aplicativo é uma implantação do Serviço de Aplicativo do Azure em uma sub-rede em sua rede virtual do Azure. Há dois tipos de implantação para um Ambiente do Serviço de Aplicativo:

• Externo: esse tipo de implantação expõe os aplicativos hospedados usando um endereço IP acessível na Internet. Para obter mais informações, consulte Criar um ambiente externo do Serviço de Aplicativo.
• Balanceador de carga interno: esse tipo de implantação expõe os aplicativos hospedados em um endereço IP dentro de sua rede virtual. O ponto de extremidade interno é um balanceador de carga interno. Para obter mais informações, consulte Criar e usar um ambiente interno do Serviço de Aplicativo do balanceador de carga.

Nota

Este artigo é sobre o Ambiente do Serviço de Aplicativo v2, que é usado com planos isolados do Serviço de Aplicativo.

Independentemente do tipo de implantação, todos os Ambientes do Serviço de Aplicativo têm um IP virtual público (VIP). Esse VIP é usado para o tráfego de gerenciamento de entrada e como o endereço quando você está fazendo chamadas do Ambiente do Serviço de Aplicativo para a Internet. Essas chamadas saem da rede virtual por meio do VIP atribuído ao Ambiente do Serviço de Aplicativo.

Se os aplicativos fizerem chamadas para recursos em sua rede virtual ou através de uma VPN, o IP de origem será um dos IPs na sub-rede. Como o Ambiente do Serviço de Aplicativo está dentro da rede virtual, ele também pode acessar recursos dentro da rede virtual sem qualquer configuração adicional. Se a rede virtual estiver conectada à sua rede local, os aplicativos também terão acesso aos recursos sem configuração adicional.

Se você tiver um Ambiente do Serviço de Aplicativo com uma implantação externa, o VIP público também será o ponto de extremidade para o qual seus aplicativos serão resolvidos para o seguinte:

• HTTP/S
• FTP/S
• Implementação na Web
• Depuração remota

Se você tiver um Ambiente do Serviço de Aplicativo com uma implantação de balanceador de carga interno, o endereço interno será o ponto de extremidade para HTTP/S, FTP/S, implantação na Web e depuração remota.

Tamanho da sub-rede

Depois que o Ambiente do Serviço de Aplicativo for implantado, não será possível alterar o tamanho da sub-rede usada para hospedá-lo. O Ambiente do Serviço de Aplicativo usa um endereço para cada função de infraestrutura, bem como para cada instância isolada do plano do Serviço de Aplicativo. Além disso, a rede do Azure usa cinco endereços para cada sub-rede criada.

Um Ambiente do Serviço de Aplicativo sem planos do Serviço de Aplicativo usará 12 endereços antes de criar um aplicativo. Se você usar a implantação do balanceador de carga interno, ela usará 13 endereços antes de criar um aplicativo. À medida que você expande, esteja ciente de que as funções de infraestrutura são adicionadas a cada múltiplo de 15 e 20 instâncias do seu plano do Serviço de Aplicativo.

Importante

Nada mais pode estar na sub-rede além do Ambiente do Serviço de Aplicativo. Certifique-se de escolher um espaço de endereço que permita o crescimento futuro. Não é possível alterar essa configuração posteriormente. Recomendamos um tamanho de /24 com 256 endereços.

Quando você aumenta ou diminui a escala, novas funções do tamanho apropriado são adicionadas e, em seguida, suas cargas de trabalho são migradas do tamanho atual para o tamanho de destino. As VMs originais são removidas somente depois que as cargas de trabalho são migradas. Por exemplo, se você tinha um Ambiente do Serviço de Aplicativo com 100 instâncias do plano do Serviço de Aplicativo, há um período de tempo em que você precisa dobrar o número de VMs.

Dependências de entrada e saída

As seções a seguir abordam as dependências a serem observadas no seu Ambiente do Serviço de Aplicativo. Outra seção discute as configurações de DNS.

Dependências de entrada

Apenas para que o Ambiente do Serviço de Aplicações funcione, as seguintes portas têm de estar abertas:

Utilizar	De	Para
Gestão	Endereços de gerenciamento do Serviço de Aplicativo	Sub-rede do Ambiente do Serviço de Aplicativo: 454, 455
Comunicação interna do Ambiente do Serviço de Aplicativo	Sub-rede do Ambiente do Serviço de Aplicativo: Todas as portas	Sub-rede do Ambiente do Serviço de Aplicativo: Todas as portas
Permitir entrada do balanceador de carga do Azure	Balanceador de carga do Azure	Sub-rede do Ambiente do Serviço de Aplicativo: 16001

As portas 7564 e 1221 podem aparecer como abertas em uma varredura de porta. Eles respondem com um endereço IP, e nada mais. Você pode bloqueá-los se quiser.

O tráfego de gerenciamento de entrada fornece comando e controle do Ambiente do Serviço de Aplicativo, além do monitoramento do sistema. Os endereços de origem desse tráfego estão listados em Endereços de gerenciamento do Ambiente do Serviço de Aplicativo. A configuração de segurança de rede precisa permitir o acesso a partir dos endereços de gerenciamento do Ambiente do Serviço de Aplicativo nas portas 454 e 455. Se você bloquear o acesso desses endereços, seu Ambiente do Serviço de Aplicativo ficará não íntegro e, em seguida, será suspenso. O tráfego TCP que entra nas portas 454 e 455 deve voltar do mesmo VIP, ou você terá um problema de roteamento assimétrico.

Dentro da sub-rede, há muitas portas usadas para comunicação de componentes internos e elas podem mudar. Isso requer que todas as portas na sub-rede sejam acessíveis a partir da sub-rede.

Para comunicação entre o balanceador de carga do Azure e a sub-rede do Ambiente do Serviço de Aplicativo, as portas mínimas que precisam ser abertas são 454, 455 e 16001. Se você estiver usando uma implantação de balanceador de carga interno, poderá bloquear o tráfego apenas para as portas 454, 455, 16001. Se você estiver usando uma implantação externa, precisará levar em conta as portas normais de acesso ao aplicativo. Mais especificamente, são eles:

Utilizar	Portas
HTTP/HTTPS	80, 443
FTP/FTPS	21, 990, 10001-10020
Depuração remota do Visual Studio	4020, 4022, 4024
Serviço de implantação da Web	8172

Se você bloquear as portas do aplicativo, seu Ambiente do Serviço de Aplicativo ainda poderá funcionar, mas seu aplicativo não. Se você estiver usando endereços IP atribuídos a aplicativos com uma implantação externa, precisará permitir o tráfego dos IPs atribuídos aos seus aplicativos para a sub-rede. No portal do Ambiente do Serviço de Aplicativo, vá para endereços IP e veja as portas das quais você precisa permitir o tráfego.

Dependências de saída

Para acesso de saída, um Ambiente do Serviço de Aplicativo depende de vários sistemas externos. Muitas dessas dependências do sistema são definidas com nomes DNS e não são mapeadas para um conjunto fixo de endereços IP. Assim, o Ambiente do Serviço de Aplicativo requer acesso de saída da sub-rede a todos os IPs externos, em uma variedade de portas.

O Ambiente do Serviço de Aplicativo se comunica com endereços acessíveis pela Internet nas seguintes portas:

Utilizações	Portas
DNS	53
NTP	123
CRL, atualizações do Windows, dependências do Linux, serviços do Azure	80/443
SQL do Azure	1433
Monitorização	12000

As dependências de saída estão listadas em Bloqueando um Ambiente do Serviço de Aplicativo. Se o Ambiente do Serviço de Aplicativo perder o acesso às suas dependências, ele parará de funcionar. Quando isso acontece por um período de tempo suficiente, é suspenso.

DNS do cliente

Se a rede virtual estiver configurada com um servidor DNS definido pelo cliente, as cargas de trabalho do locatário a usarão. O Ambiente do Serviço de Aplicativo usa o DNS do Azure para fins de gerenciamento. Se a rede virtual estiver configurada com um servidor DNS selecionado pelo cliente, o servidor DNS deverá estar acessível a partir da sub-rede.

Nota

Montagens de armazenamento ou imagens de contêiner no Ambiente do Serviço de Aplicativo v2 não podem usar o DNS definido pelo cliente na rede virtual ou por meio da configuração do WEBSITE_DNS_SERVER aplicativo.

Para testar a resolução de DNS a partir da sua aplicação Web, pode utilizar o comando nameresolverda consola . Vá para a janela de depuração no seu scm site para o seu aplicativo ou vá para o aplicativo no portal e selecione console. No prompt do shell, você pode emitir o comando nameresolver, juntamente com o nome DNS que deseja pesquisar. O resultado que você recebe de volta é o mesmo que seu aplicativo obteria ao fazer a mesma pesquisa. Se você usar nslookupo , fará uma pesquisa usando o DNS do Azure.

Se você alterar a configuração DNS da rede virtual em que seu Ambiente do Serviço de Aplicativo está, será necessário reinicializar. Para evitar a reinicialização, é recomendável definir as configurações de DNS para sua rede virtual antes de criar o Ambiente do Serviço de Aplicativo.

Dependências do portal

Além das dependências descritas nas seções anteriores, há algumas considerações extras que você deve estar ciente de que estão relacionadas à experiência do portal. Alguns dos recursos no portal do Azure dependem do acesso direto ao site do gerenciador de controle do código-fonte (SCM). Para cada aplicativo no Serviço de Aplicativo do Azure, há duas URLs. O primeiro URL é para acessar seu aplicativo. A segunda URL é para acessar o site SCM, que também é chamado de console Kudu. Os recursos que usam o site do SCM incluem:

• WebJobs
• Funções
• Transmissão em fluxo de registo
• Kudu
• Extensões
• Explorador de Processos
• Consola

Quando você usa um balanceador de carga interno, o site do SCM não é acessível de fora da rede virtual. Alguns recursos não funcionam no portal do aplicativo porque exigem acesso ao site do SCM de um aplicativo. Você pode se conectar ao site do SCM diretamente, em vez de usar o portal.

Se o balanceador de carga interno for o nome contoso.appserviceenvironment.netde domínio e o nome do aplicativo for testapp, o aplicativo será alcançado em testapp.contoso.appserviceenvironment.net. O site do SCM que o acompanha é alcançado em testapp.scm.contoso.appserviceenvironment.net.

Endereços IP

Um Ambiente do Serviço de Aplicativo tem alguns endereços IP para estar ciente. Eles são:

• Endereço IP de entrada público: usado para tráfego de aplicativo em uma implantação externa e tráfego de gerenciamento em implantações internas e externas.
• IP público de saída: usado como o IP "de" para conexões de saída que saem da rede virtual. Essas conexões não são roteadas por uma VPN.
• Endereço IP do balanceador de carga interno: esse endereço só existe em uma implantação interna.
• Endereços TLS/SSL baseados em IP atribuídos a aplicativos: esses endereços só são possíveis com uma implantação externa e quando a vinculação TLS/SSL baseada em IP é configurada.

Todos esses endereços IP são visíveis no portal do Azure a partir da interface do usuário do Ambiente do Serviço de Aplicativo. Se você tiver uma implantação interna, o IP do balanceador de carga interno será listado.

Nota

Esses endereços IP não são alterados, desde que seu Ambiente do Serviço de Aplicativo esteja em execução. Se o Ambiente do Serviço de Aplicativo for suspenso e restaurado, os endereços usados serão alterados. A causa normal para uma suspensão é se você bloquear o acesso de gerenciamento de entrada ou bloquear o acesso a uma dependência.

Endereços IP atribuídos a aplicativos

Com uma implantação externa, você pode atribuir endereços IP a aplicativos individuais. Não é possível fazer isso com uma implantação interna. Para obter mais informações sobre como configurar seu aplicativo para ter seu próprio endereço IP, consulte Proteger um nome DNS personalizado com uma associação TLS/SSL no Serviço de Aplicativo do Azure.

Quando um aplicativo tem seu próprio endereço SSL baseado em IP, o Ambiente do Serviço de Aplicativo reserva duas portas para mapear para esse endereço IP. Uma porta é para tráfego HTTP e a outra porta é para HTTPS. Essas portas estão listadas na seção Endereços IP do portal do Ambiente do Serviço de Aplicativo. O tráfego deve poder chegar a esses portos a partir do VIP. Caso contrário, os aplicativos ficam inacessíveis. Esse requisito é importante lembrar quando você configura grupos de segurança de rede (NSGs).

Grupos de segurança de rede

Os NSGs fornecem a capacidade de controlar o acesso à rede dentro de uma rede virtual. Quando você usa o portal, há uma regra de negação implícita na prioridade mais baixa para negar tudo. O que você constrói são suas regras de permissão.

Você não tem acesso às VMs usadas para hospedar o próprio Ambiente do Serviço de Aplicativo. Eles estão em uma assinatura gerenciada pela Microsoft. Se você quiser restringir o acesso aos aplicativos, defina NSGs na sub-rede. Ao fazê-lo, preste muita atenção às dependências. Se você bloquear quaisquer dependências, o Ambiente do Serviço de Aplicativo para de funcionar.

Você pode configurar NSGs por meio do portal do Azure ou do PowerShell. As informações aqui mostram o portal do Azure. Você cria e gerencia NSGs no portal como um recurso de nível superior em Rede.

As entradas necessárias em um NSG são para permitir o tráfego:

Entrada

• TCP da etiqueta AppServiceManagement de serviço IP nas portas 454, 455
• TCP do balanceador de carga na porta 16001
• Da sub-rede Ambiente do Serviço de Aplicativo para a sub-rede Ambiente do Serviço de Aplicativo em todas as portas

Saída

• UDP para todos os IPs na porta 53
• UDP para todos os IPs na porta 123
• TCP para todos os IPs nas portas 80, 443
• TCP para a etiqueta Sql de serviço IP na porta 1433
• TCP para todos os IPs na porta 12000
• Para a sub-rede Ambiente do Serviço de Aplicativo em todas as portas

Essas portas não incluem as portas que seus aplicativos exigem para um uso bem-sucedido. Por exemplo, suponha que seu aplicativo precise chamar um servidor MySQL na porta 3306. Network Time Protocol (NTP) na porta 123 é o protocolo de sincronização de tempo usado pelo sistema operacional. Os pontos de extremidade NTP não são específicos do Serviço de Aplicativo, podem variar de acordo com o sistema operacional e não estão em uma lista bem definida de endereços. Para evitar problemas de sincronização de tempo, você precisa permitir o tráfego UDP para todos os endereços na porta 123. O tráfego TCP de saída para a porta 12000 destina-se ao suporte e análise do sistema. Os pontos de extremidade são dinâmicos e não estão em um conjunto bem definido de endereços.

As portas normais de acesso ao aplicativo são:

Utilizar	Portas
HTTP/HTTPS	80, 443
FTP/FTPS	21, 990, 10001-10020
Depuração remota do Visual Studio	4020, 4022, 4024
Serviço de implantação da Web	8172

Uma regra padrão permite que os IPs na rede virtual conversem com a sub-rede. Outra regra padrão permite que o balanceador de carga, também conhecido como VIP público, se comunique com o Ambiente do Serviço de Aplicativo. Para ver as regras padrão, selecione Regras padrão (ao lado do ícone Adicionar ).

Se você colocar uma regra de negação de tudo o resto antes das regras padrão, impedirá o tráfego entre o VIP e o Ambiente do Serviço de Aplicativo. Para evitar que o tráfego venha de dentro da rede virtual, adicione sua própria regra para permitir a entrada. Use uma origem igual a AzureLoadBalancer, com um destino de Any e um intervalo de portas de *. Como a regra NSG é aplicada à sub-rede, você não precisa ser específico no destino.

Se você atribuiu um endereço IP ao seu aplicativo, certifique-se de manter as portas abertas. Para ver as portas, selecione Endereços IP do Ambiente>do Serviço de Aplicativo.  

Depois que os NSGs forem definidos, atribua-os à sub-rede. Se você não se lembrar da rede virtual ou sub-rede, poderá vê-la no portal do Ambiente do Serviço de Aplicativo. Para atribuir o NSG à sua sub-rede, vá para a interface do usuário da sub-rede e selecione o NSG.

Rotas

O túnel forçado é quando você define rotas em sua rede virtual para que o tráfego de saída não vá diretamente para a Internet. Em vez disso, o tráfego vai para outro lugar, como um gateway do Azure ExpressRoute ou um dispositivo virtual. Se você precisar configurar seu Ambiente do Serviço de Aplicativo dessa maneira, consulte Configurando seu Ambiente do Serviço de Aplicativo com túnel forçado.

Ao criar um Ambiente do Serviço de Aplicativo no portal, você cria automaticamente um conjunto de tabelas de rotas na sub-rede. Essas rotas simplesmente dizem para enviar tráfego de saída diretamente para a internet.

Para criar as mesmas rotas manualmente, siga estas etapas:

1. Vá para o portal do Azure e selecione Tabelas de Rotas de Rede>.

2. Crie uma nova tabela de rotas na mesma região da sua rede virtual.

3. Na interface do usuário da tabela de rotas, selecione Adicionar rotas>.

4. Defina o tipo de salto seguinte como Internet e o prefixo Endereço como 0.0.0.0/0. Selecione Guardar.

   Em seguida, você verá algo como o seguinte:

   

5. Depois de criar a nova tabela de rotas, vá para a sub-rede. Selecione sua tabela de rotas na lista no portal. Depois de salvar a alteração, você verá os NSGs e as rotas anotadas com sua sub-rede.

   

Pontos finais de serviço

Os pontos de extremidade de serviço permitem restringir o acesso a serviços multilocatários a um conjunto de redes virtuais e sub-redes do Azure. Para obter mais informações, consulte Pontos de extremidade de serviço de Rede Virtual.

Quando você habilita pontos de extremidade de serviço em um recurso, há rotas criadas com prioridade mais alta do que todas as outras rotas. Se você usar pontos de extremidade de serviço em qualquer serviço do Azure, com um Ambiente do Serviço de Aplicativo com túnel forçado, o tráfego para esses serviços não será encapsulado à força.

Quando os pontos de extremidade de serviço são habilitados em uma sub-rede com uma instância do Azure SQL, todas as instâncias SQL do Azure conectadas a partir dessa sub-rede devem ter pontos de extremidade de serviço habilitados. Se quiser aceder a várias instâncias do SQL do Azure a partir da mesma sub-rede, não poderá ativar pontos finais de serviço numa instância do SQL do Azure e não na outra. Nenhum outro serviço do Azure se comporta como o Azure SQL em relação aos pontos de extremidade de serviço. Ao habilitar pontos de extremidade de serviço com o Armazenamento do Azure, você bloqueia o acesso a esse recurso de sua sub-rede. No entanto, você ainda pode acessar outras contas de Armazenamento do Azure, mesmo que elas não tenham pontos de extremidade de serviço habilitados.