Considerações de rede para um Ambiente do Serviço de Aplicativo

Importante

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

Desde 29 de janeiro de 2024, você não pode mais criar recursos do Ambiente do Serviço de Aplicativo v2 usando um dos métodos disponíveis, incluindo os modelos do ARM/Bicep, o portal do Azure, a CLI do Azure ou a API REST. Você precisará migrar para o Ambiente do Serviço de Aplicativo v3 antes de 31 de agosto de 2024 para evitar a exclusão de recursos e a perda de dados.

O Ambiente do Serviço de Aplicativo é uma implantação do Serviço de Aplicativo do Azure em uma sub-rede da 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 do Serviço de Aplicativo externo.
• Balanceador de carga interno: esse tipo de implantação expõe os aplicativos hospedados em um endereço IP dentro da sua rede virtual. O ponto de extremidade interno é um balanceador de carga interno. Para obter mais informações, confira Criar e usar um Ambiente do Serviço de Aplicativo de balanceador de carga Interno.

Observação

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

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

Se os aplicativos fizerem chamadas a recursos na sua rede virtual ou por uma VPN, o IP de origem será um dos IPs na sub-rede. Como o Ambiente do Serviço de Aplicativo é na rede virtual, também pode acessar recursos na rede virtual sem nenhuma configuração adicional. Se a rede virtual estiver conectada à sua rede local, os aplicativos também terão acesso aos recursos de lá 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 os aplicativos serão resolvidos para o seguinte:

• HTTP/S
• FTP/S
• Implantação da Web
• Depuração remota

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

Tamanho da sub-rede

Depois que Ambiente do Serviço de Aplicativo é implantado, você não pode 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 de plano do serviço de aplicativo isolado. Além disso, a rede do Azure usa cinco endereços para cada sub-rede criada.

Um Ambiente do Serviço de Aplicativo sem nenhum plano 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, ele usará 13 endereços antes de criar um aplicativo. Conforme você escala horizontalmente, lembre-se de que as funções de infraestrutura são adicionadas a cada múltiplo de 15 e de 20 de suas instâncias do Plano do Serviço de Aplicativo.

Importante

Nada mais pode existir na sub-rede além do Ambiente do Serviço de Aplicativo. Escolha um espaço de endereço que possibilite crescimento futuro. Você não poderá alterar essa configuração mais tarde. É recomendável um tamanho de /24 com 256 endereços.

Quando você escala ou reduz verticalmente, são adicionadas novas funções de tamanho apropriado 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ê tiver um Ambiente do Serviço de Aplicativo com 100 instâncias de plano do Serviço de Aplicativo, haverá um período no qual você precisará do dobro do número de VMs.

Dependências de entrada e de saída

As seções a seguir abrangem as dependências das quais você deve estar ciente para o Ambiente do Serviço de Aplicativo. Outra seção aborda as configurações de DNS.

Dependências de entrada

As seguintes portas devem estar abertas apenas para o Ambiente do Serviço de Aplicativo operar:

Uso	De	Para
Gerenciamento	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 a entrada do Azure Load Balancer	Azure Load Balancer	Sub-rede do Ambiente do Serviço de Aplicativo: 16001

As portas 7564 e 1221 podem aparecer como abertas em uma verificação de porta. Elas respondem com um endereço IP e nada mais. Você pode bloqueá-las se quiser.

O tráfego de gerenciamento de entrada fornece o comando e o controle do Ambiente do Serviço de Aplicativo, além de monitoramento do sistema. Os endereços de origem desse tráfego são listados no documento Endereços de gerenciamento do Ambiente do Serviço de Aplicativo. A configuração de segurança de rede deve permitir o acesso 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 deixará de ser íntegro e será suspenso. O tráfego TCP que chega 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 a comunicação interna do componente e elas podem mudar. Isso exige que todas as portas na sub-rede estejam acessíveis por meio 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 e 455 de 16001. Se estiver usando uma implantação interna do balanceador de carga, você poderá bloquear o tráfego apenas para as portas 454, 455 e 16001. Se estiver usando uma implantação externa, você precisará levar em conta as portas de acesso do aplicativo normal. Especificamente, são elas:

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

Caso você bloqueie as portas do aplicativo, o Ambiente do Serviço de Aplicativo ainda pode funcionar, mas talvez seu aplicativo não funcione. Se você estiver usando os endereços IP com uma implantação externa atribuídos pelo aplicativo, será necessário permitir o tráfego dos IPs atribuídos a seus aplicativos à sub-rede. No portal Ambiente do Serviço de Aplicativo, acesse endereços IP e veja as portas das quais precisa para 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 para 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:

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

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

DNS do cliente

Se a rede virtual for configurada com um servidor DNS definido pelo cliente, as cargas de trabalho de locatário usarão esse servidor DNS. 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á ser acessível pela sub-rede.

Observação

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

Para testar a resolução do DNS do seu aplicativo Web, você pode usar o comando de console nameresolver. Vá até a janela de depuração no site do scm do seu aplicativo ou vá até o aplicativo no portal e selecione o console. No prompt de shell, você pode emitir o comando nameresolver junto com o nome DNS que deseja pesquisar. O resultado obtido é o mesmo que o seu aplicativo obteria ao fazer a mesma pesquisa. Se você usar nslookup, faça uma pesquisa usando o DNS do Azure.

Se você alterar a configuração de DNS da rede virtual em que seu Ambiente do Serviço de Aplicativo se encontra, será preciso reiniciar. Para evitar a reinicialização, é recomendável definir as configurações de DNS da 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 adicionais que você deve saber que estão relacionadas à experiência do portal. Alguns dos recursos no portal do Azure dependem do acesso direto ao site do SCM (gerenciador do controle do código-fonte). Para cada aplicativo no Serviço de Aplicativo do Azure, há duas URLs. A primeira URL é para acessar seu aplicativo. A segunda URL é para acessar o site do SCM, que também é chamado de console Kudu. Recursos que usam o site do SCM incluem:

• Trabalhos da Web
• Funções
• Streaming de log
• Kudu
• Extensões
• Gerenciador de Processos
• Console

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, pois 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 de domínio contoso.appserviceenvironment.net 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 dos quais você deve estar ciente. Eles são:

• Endereço IP público de entrada: usado para o tráfego de aplicativo em uma implantação externa e o tráfego de gerenciamento em implantações internas e externas.
• IP público de saída: usado como o IP “de” das 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: este endereço só existe em uma implantação interna.
• Endereços TLS/SSL com base em IP atribuídos ao aplicativo: estes endereços são possíveis somente com uma implantação externa e quando a associação TLS/SSL baseada em IP está configurada.

Todos esses endereços IP ficam visíveis no portal do Azure, na 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.

Observação

Esses endereços IP não mudam, desde que seu Ambiente do Serviço de Aplicativo esteja sendo executado. Se o Ambiente do Serviço de Aplicativo for suspenso e, em seguida, restaurado, os endereços usados serão alterados. Normalmente, uma suspensão será causada se você bloquear o acesso do gerenciamento de entrada ou o acesso a uma dependência.

Endereços IP atribuídos ao aplicativo

Com uma implantação externa, você pode atribuir endereços IP a aplicativos individuais. Isso não é possível com uma implantação interna. Para obter mais informações sobre como configurar seu aplicativo para ter seu próprio endereço IP, confira 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 com base em IP, o Ambiente do Serviço de Aplicativo reserva duas portas para mapear para esse endereço IP. Uma porta é para o tráfego HTTP e a outra porta é para HTTPS. Essas portas são listadas na seção Endereços IP do portal do Ambiente do Serviço de Aplicativo. O tráfego deverá ser capaz de alcançar essas portas do VIP ou. Caso contrário, os aplicativos estarão inacessíveis. É importante lembrar-se desse requisito ao configurar NSGs (grupos de segurança de rede).

Grupos de segurança de rede

Os Grupos de Segurança de Rede permitem controlar o acesso de rede em uma rede virtual. Quando você usa o portal, há uma regra de negação implícita a prioridade mais baixa para negar tudo. O que você cria são suas regras de permissão.

Você não tem acesso às VMs usadas para hospedar o Ambiente do Serviço de Aplicativo em si. Elas estão em uma assinatura que a Microsoft gerencia. Se você quiser restringir o acesso aos aplicativos, defina NSGs na sub-rede. Ao fazer isso, preste muita atenção às dependências. Se você bloquear qualquer dependência, o Ambiente do Serviço de Aplicativo deixará de funcionar.

Você pode configurar os NSGs meio do portal do Azure ou por meio do PowerShell. As informações aqui mostram o portal do Azure. Crie e gerencie os 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 marca de serviço IP AppServiceManagement nas portas 454, 455
• TCP do balanceador de carga na porta 16001
• Da sub-rede do Ambiente do Serviço de Aplicativo para a sub-rede do 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 marca de serviço IP Sql na porta 1433
• TCP para todos os IPs na porta 12000
• Para a sub-rede do Ambiente do Serviço de Aplicativo em todas as portas

Essas portas não incluem aquelas que seus aplicativos exigem para uso bem-sucedido. Por exemplo, suponhamos que seu aplicativo precise chamar um servidor MySQL na porta 3306. O protocolo NTP na porta 123 é o protocolo de sincronização de tempo usado pelo sistema operacional. Os pontos de extremidade do NTP não são específicos para o Serviço de Aplicativo, podem variar 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, é preciso permitir o tráfego UDP para todos os endereços na porta 123. O tráfego de saída TCP para a porta 12000 é para a análise e o suporte 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 de acesso normais do aplicativo são:

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

Uma regra padrão permite que os IPs na rede virtual comuniquem-e com a sub-rede. Outra regra padrão permite que o balanceador de carga, também conhecido como o VIP público, comunique-se 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 para negar tudo antes das regras padrão, impedirá o tráfego entre o VIP e o Ambiente do Serviço de Aplicativo. Para evitar o tráfego proveniente de dentro da rede virtual, adicione suas próprias regras para permitir a entrada. Usar uma fonte igual ao AzureLoadBalancer com um destino de Qualquer e um intervalo de portas de *. Como a regra NSG é aplicada à sub-rede, você não precisa ser específico quanto ao destino.

Se você tiver atribuído um endereço IP ao seu aplicativo, mantenha as portas abertas. Para ver as portas, selecione Ambiente de Serviço de Aplicativo>Endereços IP.  

Depois que seus NSGs estiverem definidos, atribua-os à sub-rede. Caso não se lembre da sub-rede ou rede virtual, você poderá visualizá-los a partir do portal do Ambiente do Serviço de Aplicativo. Para atribuir o NSG à sua sub-rede, vá para a sub-rede da interface do usuário e selecione o NSG.

Rotas

O túnel forçado é quando você define rotas na rede virtual para que o tráfego de saída não vá diretamente para a Internet. Em vez disso, o tráfego passa para outro lugar, como um gateway de ExpressRoute do Azure ou um dispositivo virtual. Se precisar configurar o Ambiente do Serviço de Aplicativo dessa maneira, confira Configurar 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 informam para enviar o 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 Rede>Tabelas de Rotas.

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

3. Dentro da interface do usuário da tabela de rota, selecione Rotas>Adicionar.

4. Defina o Tipo do próximo salto como Internet e o Prefixo de endereço como 0.0.0.0/0. Selecione Salvar.

   Então você verá algo semelhante ao que se segue:

   

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

   

Pontos de extremidade de serviço

Os pontos de extremidade de serviço permitem restringir o acesso aos serviços de vários locatários para um conjunto de sub-redes e redes virtuais do Azure. Para obter mais informações, confira Pontos de extremidade de serviço de rede virtual.

Quando você habilita pontos de extremidade de serviço em um recurso, existem rotas criadas com prioridade mais alta 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 em túnel forçado, o tráfego para esses serviços não será em túnel forçado.

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