Opções de rede do Funções do Azure

Este artigo descreve as funcionalidades de rede disponíveis nas opções de alojamento do Funções do Azure. As seguintes opções de rede podem ser categorizadas como recursos de rede de entrada e saída. Os recursos de entrada permitem que você restrinja o acesso ao seu aplicativo, enquanto os recursos de saída permitem que você conecte seu aplicativo a recursos protegidos por uma rede virtual e controle como o tráfego de saída é roteado.

Os modelos de hospedagem têm diferentes níveis de isolamento de rede disponíveis. Escolher o correto ajuda você a atender aos requisitos de isolamento de rede.

Caraterística Plano de consumo Flex Plano de consumo Plano Premium Plano dedicado/ASE Aplicações de Contentor1
Restrições de acesso de entrada ✅ ✅ ✅ ✅ ✅ 2
Endpoints privados (entrada) ✅ ❌ ✅ ✅ ❌
Endpoints de serviço (de entrada) ✅ ❌ ✅ ✅ ✅
Integração com redes virtuais (saída) ✅ ❌ ✅ ✅ 3 ✅
Ligações Híbridas ❌ ❌ ✅ (apenas Windows) ✅ (apenas Windows) ✅ (apenas Windows)
  1. Para mais informações, consulte Networking in Azure Container Apps environment.
  2. Gerido através da configuração de entrada do ambiente Container Apps.
  3. O plano Dedicado/ASE também suporta integração de rede virtual necessária pelo gateway.

Recursos de início rápido

Use os seguintes recursos para começar rapidamente com cenários de rede do Funções do Azure. Esses recursos são referenciados ao longo do artigo.

Restrições de acesso de entrada

Pode usar restrições de acesso para definir uma lista ordenada por prioridade dos endereços IP que são permitidos ou recusados à sua aplicação. A lista pode incluir endereços IPv4 e IPv6 ou sub-redes de rede virtual específicas usando pontos de extremidade de serviço. No final da lista, quando existem uma ou mais entradas, há uma regra implícita de "negar tudo". As restrições de IP funcionam com todas as opções de hospedagem de funções.

Nota

Com as restrições de rede em vigor, só pode implementar a partir da sua rede virtual, ou quando coloca o endereço IP da máquina que está a usar para aceder ao portal Azure na lista Destinatários Seguros. No entanto, você ainda pode gerenciar a função usando o portal.

Para saber mais, consulte Serviço de Aplicações do Azure restrições de acesso estática.

Quando é executado em Aplicações de Contentores, o acesso de entrada é gerido através da configuração de entrada do ambiente de Aplicações de Contentores, em vez de restrições de acesso do Serviço de Aplicações. Para mais informações, consulte restrições IP em Azure Container Apps.

Endpoints privados (inbound)

Azure Private Endpoint é uma interface de rede que o liga de forma privada e segura a um serviço alimentado pela Azure Private Link. O Ponto Final Privado utiliza um endereço IP privado a partir da rede virtual, o que leva de forma eficaz o serviço até à sua rede virtual.

Você pode usar o Private Endpoint para suas funções hospedadas nos planos Flex Consumption, Elastic Premium e Dedicated (App Service).

Se você quiser fazer chamadas para pontos finais privados, deve certificar-se de que suas pesquisas DNS resolvem para o ponto final privado. Você pode impor esse comportamento de uma das seguintes maneiras:

  • Integrar com zonas privadas de DNS do Azure. Quando sua rede virtual não tem um servidor DNS personalizado, isso é feito automaticamente.
  • Gerencie o ponto de extremidade privado no servidor DNS usado pelo seu aplicativo. Para gerenciar um ponto de extremidade privado, você deve saber o endereço do ponto de extremidade e usar um registro A para fazer referência ao ponto de extremidade que está tentando alcançar.
  • Configura o teu próprio servidor DNS para encaminhar para zonas privadas DNS do Azure.

Para saber mais, consulte o uso de Pontos Finais Privados para Aplicações Web.

Para chamar outros serviços que tenham uma conexão de endpoint privado, como armazenamento ou barramento de serviço, certifique-se de configurar sua aplicação para fazer chamadas de saída para endpoints privados. Para obter mais detalhes sobre como usar pontos de extremidade privados com a conta de armazenamento para seu aplicativo de função, visite restringir sua conta de armazenamento a uma rede virtual.

Endpoints de serviço (de entrada)

Usando os endpoints de serviço, pode restringir muitos dos serviços da Azure a sub-redes virtuais selecionadas, proporcionando um nível de segurança mais elevado. A integração da rede virtual regional permite que a sua aplicação de funções aceda a serviços Azure que estão protegidos com endpoints de serviço. Esta configuração é suportada em todos os planos que suportam a integração de rede virtual. Siga estas etapas para aceder a um endpoint de serviço seguro:

  1. Configure a integração de rede virtual regional com seu aplicativo de função para se conectar a uma sub-rede específica.
  2. Vá para o serviço de destino e configure os endpoints de serviço na sub-rede de integração.

Para saber mais, consulte Pontos de extremidade de serviço de rede virtual.

Usar pontos de extremidade de serviço

Para restringir o acesso a uma sub-rede específica, crie uma regra de restrição com um tipo Rede Virtual. Em seguida, você pode selecionar a assinatura, a rede virtual e a sub-rede à qual deseja permitir ou negar acesso.

Se os endpoints de serviço ainda não estiverem ativados com Microsoft.Web para a sub-rede que selecionou, serão automaticamente ativados, a menos que selecione a caixa de seleção Ignorar falta de endpoints de serviço Microsoft.Web. O cenário em que você pode querer habilitar pontos de extremidade de serviço no aplicativo, mas não na sub-rede, depende principalmente se você tem as permissões para habilitá-los na sub-rede.

Se precisar que outra pessoa ative os endpoints de serviço na sub-rede, selecione a caixa de seleção Ignorar endpoints de serviço Microsoft.Web em falta. Seu aplicativo está configurado para pontos de extremidade de serviço, que você habilita posteriormente na sub-rede.

Captura de ecrã do painel

Não é possível usar endpoints de serviço para restringir o acesso a aplicações que correm num Ambiente do Serviço de Aplicações. Quando a sua aplicação está num Ambiente do Serviço de Aplicações, pode controlar o acesso aplicando regras de acesso IP.

Para saber como configurar endpoints de serviço, consulte Estabeleça acesso privado ao site do Funções do Azure.

Integração com redes virtuais (saída)

Esta seção detalha os recursos suportados pelo Functions para controlar a saída de dados do seu aplicativo.

A integração de rede virtual dá ao seu aplicativo de função acesso a recursos em sua rede virtual. Uma vez integrado, seu aplicativo roteia o tráfego de saída através da rede virtual. Isso permite que a sua aplicação aceda a extremidades ou recursos privados com regras que permitem o tráfego apenas de sub-redes selecionadas. Quando o destino é um endereço IP fora da rede virtual, o IP de origem continuará a ser enviado a partir de um dos endereços listados nas propriedades da sua app, a menos que tenha configurado um NAT Gateway.

O Funções do Azure suporta integração de redes virtuais regionais, que é a abordagem recomendada. Para saber como configurar a integração de rede virtual, consulte Habilitar integração de rede virtual.

O Funções do Azure suporta dois tipos de integração de redes virtuais:

Para saber como configurar a integração de rede virtual, consulte Habilitar integração de rede virtual.

Integração com redes virtuais regionais (saída)

O uso da integração de rede virtual regional permite que seu aplicativo acesse:

  • Recursos na mesma rede virtual que seu aplicativo.
  • Recursos em redes virtuais emparelhados com a rede virtual à qual seu aplicativo está integrado.
  • Serviços protegidos por endpoint de serviço.
  • Recursos através das conexões Azure ExpressRoute.
  • Recursos através de ligações peer, que incluem ligações Azure ExpressRoute.
  • Pontos finais privados.

Quando utiliza a integração de rede virtual regional, pode utilizar as seguintes funcionalidades de rede do Azure:

  • Grupos de segurança de rede (NSGs): você pode bloquear o tráfego de saída com um NSG 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.
  • Tabelas de rotas (UDRs): Você pode colocar uma tabela de rotas na sub-rede de integração para enviar o tráfego de saída para onde quiser.

Nota

Quando você roteia todo o tráfego de saída para sua rede virtual, ele está sujeito aos NSGs e UDRs aplicados à sua sub-rede de integração. Quando a rede virtual está integrada, o tráfego de saída da sua app de funções para endereços IP públicos continua a ser enviado a partir dos endereços listados nas propriedades da sua aplicação, a menos que forneça rotas que direcionem o tráfego para outros locais.

A integração de rede virtual regional não pode usar a porta 25.

Considerações para o plano Flex Consumption:

  • A aplicação e a rede virtual têm de estar na mesma região.
  • Certifique-se de que o fornecedor de recursos Azure Microsoft.App está ativado para a sua subscrição, seguindo estas instruções. Isso é necessário para a delegação de subnet. O portal Azure e o CLI do Azure impõem este registo quando cria uma aplicação Flex Consumption, uma vez que a integração com a rede virtual pode ser ativada a qualquer momento após a criação da aplicação.
  • A delegação de sub-redes necessária ao executar num plano de Consumo Flexível é Microsoft.App/environments. Isso difere dos planos Elastic Premium e Dedicated (App Service), que têm um requisito de delegação diferente.
  • Você pode planear para usar no máximo 40 endereços IP para uma aplicação de função, mesmo que a aplicação escale além de 40. Por exemplo, se você tiver 15 aplicativos da função Flex Consumption integrados na mesma sub-rede, deverá planejar 15x40 = 600 endereços IP usados no máximo. Este limite está sujeito a alterações e não é aplicado.
  • A sub-rede ainda não pode estar em uso para outros fins (como pontos de extremidade privados ou de serviço, ou delegados a qualquer outro plano ou serviço de hospedagem). Embora você possa compartilhar a mesma sub-rede com vários aplicativos Flex Consumption, os recursos de rede são compartilhados entre esses aplicativos de função, o que pode levar a que um aplicativo afete o desempenho de outros na mesma sub-rede.
  • Não é possível compartilhar a mesma sub-rede entre um ambiente Container Apps e um aplicativo Flex Consumption.
  • Atualmente, o plano Flex Consumption não suporta sub-redes com nomes que contenham caracteres de sublinhado (_).

Considerações para os planos Elastic Premium, Dedicado (Serviço de Aplicativo) e Aplicativos de Contêiner :

  • O recurso está disponível para Elastic Premium e App Service Premium V2 e Premium V3. Ele também está disponível na versão Standard, mas apenas em implantações mais recentes do Azure App Service. Se estiver a utilizar uma implementação mais antiga, só pode usar a funcionalidade de um plano de Serviço de Aplicações Premium V2. Se você quiser ter certeza de que pode usar o recurso em um plano do Serviço de Aplicativo Padrão, crie seu aplicativo em um plano do Serviço de Aplicativo Premium V3. Esses planos só são suportados em nossas implantações mais recentes. Você pode reduzir se desejar depois disso.
  • Aplicações de planos isoladas que estão num Ambiente do Serviço de Aplicações não podem usar a funcionalidade.
  • A aplicação e a rede virtual têm de estar na mesma região.
  • A funcionalidade requer uma sub-rede que seja /28 ou maior numa rede virtual do Azure Resource Manager.
  • Vários planos de App Service podem usar a sub-rede de integração.
  • Você pode ter até duas integrações regionais de rede virtual por plano do Serviço de Aplicativo. Vários aplicativos no mesmo plano do Serviço de Aplicativo podem usar a mesma sub-rede de integração.
  • A sub-rede escolhida já não pode ser usada para outros fins, como com pontos finais privados ou pontos finais de serviço ou ser delegada para qualquer outro plano ou serviço de alojamento.
  • Pode partilhar a mesma sub-rede com mais do que uma aplicação num plano de Serviço de Aplicações. Como os recursos de rede são compartilhados entre todos os aplicativos, um aplicativo de função pode afetar o desempenho de outros na mesma sub-rede.
  • Não é possível excluir uma rede virtual com um aplicativo integrado. Remova a integração antes de excluir a rede virtual.
  • Não é possível alterar a assinatura de um aplicativo ou plano enquanto houver um aplicativo que esteja usando a integração de rede virtual regional.

Habilite a integração de rede virtual

  1. Na tua aplicação de funções no portal Azure, em Settings seleciona Networking. Depois, em Integração de Rede Virtual selecione Não configurado para adicionar.

  2. Selecione Adicionar integração de rede virtual.

    Captura de ecrã da página de integração de rede virtual onde pode ativar a integração de rede virtual na sua aplicação.

  3. A lista suspensa contém todas as redes virtuais do Azure Resource Manager na sua subscrição na mesma região. Selecione a rede virtual com a qual deseja integrar.

    Selecione a rede virtual

    • Os planos de hospedagem Flex Consumption e Elastic Premium suportam apenas a integração de rede virtual regional. Se a rede virtual estiver na mesma região, crie uma nova sub-rede ou selecione uma sub-rede vazia e pré-existente.

    • Para selecionar uma rede virtual em outra região, você deve ter um gateway de rede virtual provisionado com ponto a site habilitado. A integração de rede virtual entre regiões só é suportada para planos dedicados, mas as conexões globais funcionam com integração de rede virtual regional.

Durante a integração, seu aplicativo é reiniciado. Quando a integração estiver concluída, você verá detalhes na rede virtual com a qual está integrado. Por padrão, o Route All está habilitado e todo o tráfego é roteado para sua rede virtual.

Se preferir que apenas o seu tráfego privado (RFC1918) seja encaminhado, siga os passos neste artigo do Serviço de Aplicações.

Sub-redes

A integração de rede virtual depende de uma sub-rede dedicada. Quando se provisiona uma subrede, o Azure reserva os primeiros cinco endereços IP para uso interno. A forma como os endereços IP restantes são consumidos depende do seu plano de hospedagem. Como o tamanho da sub-rede não pode ser alterado após a atribuição, use uma sub-rede grande o suficiente para acomodar qualquer escala que seu aplicativo possa alcançar.

A tabela seguinte resume os requisitos de sub-redes para cada plano de alojamento:

Plano de alojamento Integração da VNet Tamanho mínimo da sub-rede Tamanho recomendado da sub-rede Delegação de sub-rede
Consumo Flexível Suportado /27 /27 (aplicação única), /26 (várias aplicações) Microsoft.App/environments
Elastic Premium (Windows) Suportado /28 /24 Microsoft.Web/serverFarms
Elastic Premium (Linux) Suportado /28 /26 Microsoft.Web/serverFarms
Dedicado (Serviço de Aplicativo) Suportado /28 /26 ou superior Microsoft.Web/serverFarms
Container Apps Gerido pelo ambiente Ver Rede de Aplicações de Contentores Ver Rede de Aplicações de Contentores Microsoft.App/environments
Consumo Não suportado N/A N/A N/A

Certifique-se de selecionar o seu plano de alojamento no topo do artigo para detalhes específicos do plano.

Quando a correr em Azure Container Apps, a integração da rede virtual é gerida através do ambiente Container Apps. O dimensionamento e a configuração da sub-rede são determinados pelo ambiente Container Apps, não diretamente pela function app. Para mais informações, consulte Networking in Azure Container Apps environment.

Nos planos Elastic Premium e Dedicated (Serviço de Aplicativo), cada instância em execução do seu aplicativo de função consome um endereço IP da sub-rede. Ao escalar para cima ou para baixo, o espaço de endereços necessário pode temporariamente duplicar para acomodar a transição. Se vários aplicativos compartilharem a mesma sub-rede, o uso total do endereço IP será a soma de todas as instâncias nesses aplicativos, além da duplicação temporária durante eventos de dimensionamento.

Cenários de Consumo de PI

Scenario Consumo de Endereço IP
Uma aplicação, uma instância Um endereço IP
Uma aplicação, cinco instâncias Cinco endereços IP
Uma aplicação, escalando de cinco a dez instâncias Até 20 endereços IP (temporários, durante a operação em escala)
Três apps, cinco instâncias cada 15 endereços IP

Recomendações de Campos CIDR

Tamanho do bloco CIDR Máximo de endereços disponíveis Escala horizontal máxima (instâncias)1
/28 11 5
/27 27 13
/26 59 29
/25 123 612
/24 251 1253
  1. Assume que precisas de aumentar ou diminuir o tamanho ou o SKU em algum momento.
  2. Embora o número de endereços IP suporte 61 instâncias, as aplicações individuais no plano Dedicado têm um máximo de 30 instâncias.
  3. Embora o número de endereços IP suporte 125 instâncias, as aplicações individuais no plano Elastic Premium têm um máximo de 100 instâncias.

Considerações adicionais

  • Para evitar problemas de capacidade de sub-redes para planos Functions Elastic Premium, deve usar um /24 com 256 endereços para Windows e um /26 com 64 endereços para Linux. Ao criar subredes no portal do Azure como parte da integração com a rede virtual, é exigido um tamanho mínimo de /24 e /26 para Windows e Linux, respetivamente.
  • Cada plano do Serviço de Aplicativo pode suportar até duas sub-redes que podem ser usadas para integração de redes virtuais. Vários aplicativos de um único plano do Serviço de Aplicativo podem ingressar na mesma sub-rede, mas os aplicativos de um plano diferente não podem usar essa mesma sub-rede.

No plano Flex Consumption, o tráfego de rede de saída das instâncias da function app é encaminhado através de gateways partilhados dedicados à sub-rede. No máximo, são usados 27 gateways partilhados (27 endereços IP) por subrede, independentemente do número de aplicações integradas. Quando uma sub-rede é usada para demasiadas instâncias ou para aplicações que realizam cargas de trabalho intensivas em I/O, podem surgir problemas de capacidade da rede, como aumento da latência e timeouts. A escala horizontal das aplicações não será afetada.

Importante

A integração de aplicativos da função Flex Consumption com um tamanho de sub-rede menor que /27 ou a integração de vários aplicativos com uma sub-rede de tamanho /27 reduz a capacidade de rede de saída disponível para eles. Se planeia fazê-lo, teste as suas aplicações com cargas de trabalho em escala de produção para garantir que as limitações de capacidade da rede não são respeitadas.

Recomendações de Campos CIDR

Tamanho do bloco CIDR Endereços utilizáveis Instâncias máximas Recommendation
/27 27 1,000 Recomendado para uma aplicação de função única
/26 59 1,000+ Recomendado para múltiplas aplicações, ou quando se escala para além de 1.000 instâncias*

* Contacte o grupo de produtos para solicitar um aumento do seu número máximo de instâncias.

Grupos de segurança de rede

Você pode usar grupos de segurança de rede para controlar o tráfego entre recursos em sua rede virtual. Por exemplo, você pode criar uma regra de segurança que impeça o tráfego de saída do seu aplicativo de alcançar um recurso em sua rede virtual ou sair da rede. Essas regras de segurança se aplicam a aplicativos que configuraram a integração de rede virtual. Para bloquear o tráfego para endereços públicos, você deve ter a integração de rede virtual e o Route All habilitado. As regras de entrada em um NSG não se aplicam ao seu aplicativo porque a integração de rede virtual afeta apenas o tráfego de saída do seu aplicativo.

Para controlar o tráfego de entrada para seu aplicativo, use o recurso Restrições de acesso. Um NSG aplicado à sua sub-rede de integração está em vigor, independentemente de quaisquer rotas que sejam aplicadas a essa sub-rede. Se o seu aplicativo de função estiver integrado à rede virtual com o Route All habilitado e você não tiver nenhuma rota que afete o tráfego de endereço público em sua sub-rede de integração, todo o tráfego de saída ainda estará sujeito a NSGs atribuídos à sua sub-rede de integração. Quando o Route All não está habilitado, os NSGs são aplicados apenas ao tráfego RFC1918.

Rotas

Você pode usar tabelas de rotas para rotear o tráfego de saída do seu aplicativo para onde quiser. Por padrão, as tabelas de rotas afetam apenas o tráfego RFC1918 de destino. Quando a opção Rotear Tudo está ativada, todas as suas chamadas de saída são afetadas. Quando desativa o Route All, as tabelas de roteamento afetam apenas o tráfego privado (RFC1918). As rotas definidas na sub-rede de integração não afetarão as respostas às solicitações de entrada do aplicativo. Destinos comuns podem incluir dispositivos de firewall ou gateways.

Se quiser rotear todo o tráfego de saída local, você pode usar uma tabela de rotas para enviar todo o tráfego de saída para o gateway da Rota Expressa. Se você rotear o tráfego para um gateway, certifique-se de definir rotas na rede externa para enviar as respostas de volta.

As rotas BGP (Border Gateway Protocol) também afetam o tráfego do aplicativo. Se tiver rotas BGP de algo como um gateway ExpressRoute, o tráfego de saída da sua aplicação será afetado. Por padrão, as rotas BGP afetam apenas o tráfego RFC1918 de destino. Quando a sua aplicação de função está integrada à rede virtual com o Route All habilitado, todo o tráfego de saída pode ser afetado pelas suas rotas BGP.

Restrições de IP de saída

Pode configurar restrições de saída para a rede virtual onde o seu Ambiente do Serviço de Aplicações está implementado.

Quando você integra um aplicativo funcional em um plano Elastic Premium ou um plano do Serviço de Aplicativo com uma rede virtual, o aplicativo ainda pode fazer chamadas de saída para a Internet por padrão. Ao integrar seu aplicativo de função com uma rede virtual com o Route All habilitado, você força todo o tráfego de saída a ser enviado para sua rede virtual, onde as regras do grupo de segurança de rede podem ser usadas para restringir o tráfego. Para o Flex Consumption, todo o tráfego já é encaminhado através da rede virtual, e o Route All não é necessário.

Para aprender a controlar o IP de saída usando uma rede virtual, veja Tutorial: Controlar Funções do Azure IP de saída com um gateway NAT de rede virtual Azure.

Zonas privadas do DNS do Azure

Depois de a sua aplicação se integrar com a sua rede virtual, ela utiliza o mesmo servidor DNS com que a sua rede virtual está configurada e irá funcionar com as zonas privadas do DNS do Azure ligadas à rede virtual.

Automatização

As APIs a seguir permitem gerenciar programaticamente integrações de rede virtual regional:

  • CLI do Azure: Use os comandos az functionapp vnet-integration para adicionar, listar ou remover uma integração regional de rede virtual.
  • templates ARM: A integração regional de rede virtual pode ser ativada usando um modelo do Azure Resource Manager. Para obter um exemplo completo, consulte este modelo de início rápido do Functions.

Ligações Híbridas

Hybrid Connections é uma funcionalidade do Azure Relay que pode usar para aceder a recursos de aplicação noutras redes. Fornece acesso da sua aplicação a um ponto final da aplicação. Você não pode usá-lo para acessar seu aplicativo.

Como usado no Funções do Azure, cada ligação híbrida correlaciona-se com uma única combinação de host TCP e porta. Isso significa que o ponto de extremidade da conexão híbrida pode estar em qualquer sistema operacional e qualquer aplicativo, desde que você esteja acessando uma porta de escuta TCP. O recurso Conexões híbridas não sabe nem se importa com o que é o protocolo do aplicativo ou o que você está acessando. Ele apenas fornece acesso à rede.

Para saber mais, consulte a documentação do Serviço de Aplicativo para Conexões Híbridas. Estes mesmos passos de configuração suportam o Funções do Azure.

Importante

As Conexões Híbridas só são suportadas quando a sua aplicação funcional está a correr no Windows. Não há suporte para aplicativos Linux.

Ligação aos Serviços Azure através de uma rede virtual

A integração de rede virtual permite que seu aplicativo de função acesse recursos em uma rede virtual. Esta seção apresenta uma visão geral de coisas que você deve considerar ao tentar conectar seu aplicativo a determinados serviços.

Restringir a conta de armazenamento a uma rede virtual

Nota

Para implementar rapidamente uma aplicação de funções com pontos finais privados ativados na conta de armazenamento, consulte o seguinte modelo: Aplicação de funções com pontos finais privados do Armazenamento do Azure.

Ao criar uma aplicação funcional, deve criar ou ligar a uma conta Armazenamento do Azure de uso geral que suporte armazenamento Blob, Queue e Table. Você poderá substituir esta conta de armazenamento por uma que seja protegida com endpoints de serviço ou privados.

Para saber como configurar seu aplicativo de função com uma conta de armazenamento protegida por uma rede virtual, consulte Restringir sua conta de armazenamento a uma rede virtual.

Deve garantir que o encaminhamento de partilha privada de conteúdo está configurado. Para saber como configurar seu aplicativo de função com uma conta de armazenamento protegida por uma rede virtual, consulte Restringir sua conta de armazenamento a uma rede virtual.

Para saber como configurar seu aplicativo de função com uma conta de armazenamento protegida por uma rede virtual, consulte Restringir sua conta de armazenamento a uma rede virtual.

Utilize referências do Key Vault

Pode usar referências do Azure Key Vault para usar segredos do Azure Key Vault na sua aplicação Funções do Azure sem necessidade de alterações de código. Azure Key Vault é um serviço que fornece gestão centralizada de segredos, com controlo total sobre as políticas de acesso e o histórico de auditorias.

Se a integração com a rede virtual estiver configurada para a app, referências Key Vault podem ser usadas para obter segredos de um cofre restrito à rede.

Gatilhos de rede virtual (não HTTP)

Sua carga de trabalho pode exigir que seu aplicativo seja acionado a partir de uma fonte de eventos protegida por uma rede virtual.

Nota

Quando é executado no Azure Container Apps, os gatilhos de rede virtual são geridos através da configuração de rede do ambiente Container Apps. Para mais informações, consulte Networking in Azure Container Apps environment.

O plano Flex Consumption suporta nativamente gatilhos de rede virtual. A sua aplicação de funções pode ser acionada a partir de fontes de eventos protegidas por uma rede virtual sem necessidade de configuração adicional para monitorização de escala em tempo de execução.

O plano Elastic Premium permite-lhe criar funções que ativam serviços protegidos por uma rede virtual. Esses gatilhos não-HTTP são conhecidos como gatilhos de rede virtual.

O plano Elastic Premium permite-lhe criar funções que ativam serviços protegidos por uma rede virtual.

Por padrão, os gatilhos de rede virtual não fazem com que o seu aplicativo de função seja dimensionado além da contagem de instâncias pré-inicializadas. No entanto, certas extensões suportam gatilhos de rede virtual que fazem com que seu aplicativo de função seja dimensionado dinamicamente. Você pode habilitar esse monitoramento de escala dinâmica em seu aplicativo de função para extensões suportadas de uma destas maneiras:

  1. No portal Azure, navegue até à sua aplicação de funções.

  2. Em Configurações, selecione Configuração e, na guia Configurações de tempo de execução da função, defina Monitoramento de escala de tempo de execução como Ativado.

  3. Selecione Salvar para atualizar a configuração do aplicativo de função e reinicie o aplicativo.

VNETToggle

Gorjeta

Habilitar o monitoramento de gatilhos de rede virtual pode afetar o desempenho do seu aplicativo, embora o impacto provavelmente seja pequeno.

O suporte para o monitoramento de escala dinâmica de gatilhos de rede virtual não está disponível na versão 1.x do runtime do Functions.

As extensões nesta tabela suportam o monitoramento de escala dinâmica de gatilhos de rede virtual. Para obter o melhor desempenho de dimensionamento, você deve atualizar para versões que também ofereçam suporte ao dimensionamento baseado em destino.

Extensão (versão mínima) Somente monitoramento de escala de tempo de execução Com escalabilidade baseada em metas
Microsoft.Azure. WebJobs.Extensions.CosmosDB > 3.0.5 > 4.1.0
Microsoft.Azure. WebJobs.Extensions.DurableTask > 2.0.0 n/d
Microsoft.Azure. WebJobs.Extensions.EventHubs > 4.1.0 > 5.2.0
Microsoft.Azure. WebJobs.Extensions.ServiceBus > 3.2.0 > 5.9.0
Microsoft.Azure. WebJobs.Extensions.Storage > 3.0.10 > 5.1.0*

* Apenas armazenamento em fila.

Importante

Quando você habilita o monitoramento de gatilhos de rede virtual, somente gatilhos para essas extensões podem fazer com que seu aplicativo seja dimensionado dinamicamente. Você ainda pode usar gatilhos de extensões que não estão nesta tabela, mas eles não causarão dimensionamento além da contagem de instâncias pré-aquecidas. Para obter uma lista completa de todas as extensões de gatilho e vinculação, consulte Gatilhos e associações.

Quando a sua aplicação de funções é executada num plano de Serviço de Aplicações ou num Ambiente do Serviço de Aplicações, pode escrever funções que são ativadas por recursos protegidos por uma rede virtual. Para que suas funções sejam acionadas corretamente, seu aplicativo deve estar conectado a uma rede virtual com acesso ao recurso definido na conexão de gatilho.

Por exemplo, suponha que quer configurar o Azure Cosmos DB para aceitar tráfego apenas de uma rede virtual. Nesse caso, você deve implantar seu aplicativo de função em um plano do Serviço de Aplicativo que forneça integração de rede virtual com essa rede virtual. A integração permite que esse recurso do Azure Cosmos DB dispare uma função.

Testar endpoints privados

Ao testar funções em um aplicativo de função com pontos de extremidade privados, você deve fazer o teste de dentro da mesma rede virtual, como em uma máquina virtual (VM) nessa rede. Para usar a opção Código + Teste no portal dessa VM, você precisa adicionar as seguintes origens CORS ao seu aplicativo de função:

  • https://functions-next.azure.com
  • https://functions-staging.azure.com
  • https://functions.azure.com
  • https://portal.azure.com

Quando se restringe o acesso à sua aplicação de funções com pontos finais privados ou qualquer outra restrição de acesso, também deve adicionar a etiqueta de serviço AzureCloud à lista de permissões. Para atualizar a lista de permitidos:

  1. Navegue até à sua função app e selecione Definições>Configurações de Rede. Em Configuração >Acesso público à rede, selecione Ativado sem restrições de acesso.

  2. Certifique-se de que Acesso à rede pública está definido como Ativado a partir de redes virtuais e endereços IP selecionados.

  3. Adicione uma regra em Acesso ao site e regras:

    1. Selecione Service Tag como Tipo de configurações de origem e AzureCloud como Etiqueta de serviço.

    2. Certifique-se de que a ação é Permitir e defina o nome e a prioridade desejados.

Resolução de Problemas

O recurso é fácil de configurar, mas isso não significa que sua experiência será livre de problemas. Se você tiver problemas para acessar o ponto de extremidade desejado, há alguns utilitários que você pode usar para testar a conectividade a partir do console do aplicativo. Há dois consoles que você pode usar. Uma é a consola Kudu, e a outra é a consola no portal Azure. Para aceder à consola Kudu a partir da sua aplicação, aceda a Ferramentas>Kudu. Você também pode acessar o console do Kudo em [sitename].scm.azurewebsites.net. Depois de o site carregar, vai ao separador Debug console. Para aceder à consola hospedada no portal Azure a partir da sua aplicação, vá a Tools>Console.

Ferramentas

Em aplicações nativas Windows, as ferramentas ping, nslookup e tracert não funcionam através da consola devido a restrições de segurança (funcionam em contentores Windows personalizados <>). Para preencher o vazio, duas ferramentas separadas são adicionadas. Para testar a funcionalidade do DNS, adicionámos uma ferramenta denominada nameresolver.exe. A sintaxe é:

nameresolver.exe hostname [optional: DNS Server]

Você pode usar nameresolver para verificar os nomes de host dos quais seu aplicativo depende. Desta forma, pode testar se tem algo mal configurado com o seu DNS ou talvez não tenha acesso ao seu servidor DNS. Você pode ver o servidor DNS que seu aplicativo usa no console observando as variáveis ambientais WEBSITE_DNS_SERVER e WEBSITE_DNS_ALT_SERVER.

Nota

A ferramenta nameresolver.exe atualmente não funciona em contentores personalizados Windows.

Você pode usar a próxima ferramenta para testar a conectividade TCP com uma combinação de host e porta. Esta ferramenta é chamada tcpping e a sintaxe é:

tcpping.exe hostname [optional: port]

O utilitário tcpping informa se você pode alcançar um host e uma porta específicos. Ele pode mostrar sucesso somente se houver um aplicativo escutando na combinação de host e porta, e houver acesso à rede do seu aplicativo para o host e a porta especificados.

Depurar o acesso a recursos hospedados na rede virtual

Várias coisas podem impedir que seu aplicativo alcance um host e uma porta específicos. Na maioria das vezes é uma destas coisas:

  • Um firewall está no caminho. Se um firewall estiver a interferir, atinges o tempo limite de TCP. Neste caso, o tempo limite do TCP é de 21 segundos. Utilize a ferramenta tcpping para testar a conectividade. Os tempos limite de TCP podem ser causados por muitas coisas além dos firewalls, mas comece por aí.
  • O DNS não está acessível. O tempo limite de DNS é de 3 segundos por servidor DNS. Se você tiver dois servidores DNS, o tempo limite é de 6 segundos. Use nameresolver para ver se o DNS está funcionando. Você não pode usar nslookup, porque isso não usa o DNS com o qual sua rede virtual está configurada. Se inacessível, você pode ter um firewall ou NSG bloqueando o acesso ao DNS ou ele pode estar inativo.

Se esses itens não responderem aos seus problemas, procure primeiro por coisas como:

Integração regional de redes virtuais

  • O seu destino é um endereço não RFC1918 e não tem o Route All ativado?
  • Existe um NSG bloqueando a saída da sua sub-rede de integração?
  • Se estiver a passar pelo Azure ExpressRoute ou por uma VPN, o seu gateway local está configurado para encaminhar tráfego de volta para o Azure? Se você puder alcançar pontos de extremidade em sua rede virtual, mas não localmente, verifique suas rotas.
  • Você tem permissões suficientes para definir a delegação na sub-rede de integração? Durante a configuração da integração da rede virtual regional, a sua sub-rede de integração é delegada à Microsoft. Web/serverFarms. A interface de integração do VNet delega a sub-rede à Microsoft. Web/serverFarms automaticamente. Se sua conta não tiver permissões de rede suficientes para definir a delegação, você precisará de alguém que possa definir atributos em sua sub-rede de integração para delegar a sub-rede. Para delegar manualmente a sub-rede de integração, vá à interface da sub-rede Rede Virtual do Azure e defina a delegação para a Microsoft. Web/serverFarms.

Integração de rede virtual com gateway necessário

  • O intervalo de endereços ponto-a-site está nos intervalos RFC 1918 (10.0.0.0-10.255.255.255 / 172.16.0.0-172.31.255.255 / 192.168.0.0-192.168.255.255)?
  • O gateway aparece como estando em funcionamento no portal? Se o seu gateway estiver inativo, então coloque-o novamente online.
  • Os certificados são apresentados como estando sincronizados ou suspeita que a configuração de rede foi alterada? Se os certificados estiverem fora de sincronia ou se suspeitar que foi feita uma alteração na configuração da rede virtual que não foi sincronizada com os ASPs, selecione Sincronizar rede.
  • Se estiver a passar por uma VPN, o gateway local está configurado para encaminhar tráfego de volta para o Azure? Se você puder alcançar pontos de extremidade em sua rede virtual, mas não localmente, verifique suas rotas.
  • Você está tentando usar um gateway de coexistência que suporte ponto a site e ExpressRoute? Os gateways de coexistência não são compatíveis com a integração de rede virtual.

Depurar problemas de rede é um desafio porque você não pode ver o que está bloqueando o acesso a uma combinação específica host:port. Algumas causas incluem:

  • Você tem um firewall instalado no seu host que impede o acesso à porta da aplicação a partir do intervalo de IP ponto-a-site. O cruzamento de sub-redes geralmente requer acesso público.
  • Seu host alvo está inativo.
  • Seu aplicativo está inativo.
  • Você tinha o IP ou nome de host errado.
  • Seu aplicativo está escutando em uma porta diferente do que você esperava. Você pode associar o seu ID de processo com a porta de escuta utilizando "netstat -aon" no servidor de destino.
  • Os seus grupos de segurança de rede estão configurados de tal forma que impedem o acesso ao host e à porta do aplicativo desde o intervalo de IP ponto a site.

Você não sabe qual endereço seu aplicativo realmente usa. Pode ser qualquer endereço na sub-rede de integração ou no intervalo de endereços ponto-a-site, portanto, precisas permitir o acesso de todo o intervalo de endereços.

Outros passos de depuração incluem:

  • Conecte-se a uma VM em sua rede virtual e tente acessar seu recurso host:port a partir daí. Para testar o acesso TCP, use o comando do PowerShell Test-NetConnection. A sintaxe é:
Test-NetConnection hostname [optional: -Port]
  • Abra um aplicativo em uma VM e teste o acesso a esse host e porta do console do seu aplicativo usando tcpping.

Recursos locais

Se a sua aplicação não conseguir aceder a um recurso no local, verifique se consegue aceder ao recurso a partir da sua rede virtual. Use o comando PowerShell Test-NetConnection para verificar o acesso TCP. Se sua VM não puder acessar seu recurso local, sua conexão VPN ou ExpressRoute pode não estar configurada corretamente.

Se sua VM hospedada na rede virtual puder acessar seu sistema local, mas seu aplicativo não puder, a causa provavelmente será um dos seguintes motivos:

  • Suas rotas não estão configuradas com sua sub-rede ou intervalos de endereços ponto a site em seu gateway local.
  • Seus grupos de segurança de rede estão bloqueando o acesso para seu intervalo de IP ponto a site.
  • Seus firewalls locais estão bloqueando o tráfego do seu intervalo de IP ponto-a-site.
  • Você está tentando alcançar um endereço não RFC 1918 usando o recurso de integração de rede virtual regional.

Eliminar o plano do Serviço de Aplicações ou a aplicação Web antes de desconectar a integração com a rede virtual

Se você excluiu o aplicativo Web ou o plano do Serviço de Aplicativo sem desconectar a integração da rede virtual primeiro, não poderá fazer nenhuma operação de atualização/exclusão na rede virtual ou sub-rede que foi usada para a integração com o recurso excluído. Uma delegação de sub-rede 'Microsoft.Web/serverFarms' permanecerá atribuída à sua sub-rede e impedirá as operações de atualização/eliminação.

Para fazer a atualização/exclusão da sub-rede ou rede virtual novamente, você precisa recriar a integração VNet e, em seguida, desconectá-la:

  1. Recrie o plano do Serviço de Aplicativo e o aplicativo Web (é obrigatório usar exatamente o mesmo nome do aplicativo Web como antes).
  2. Navegue até a folha 'Rede' no aplicativo Web e configure a integração de rede virtual.
  3. Depois que a integração da rede virtual estiver configurada, selecione o botão 'Desconectar'.
  4. Exclua o plano do Serviço de Aplicativo ou o aplicativo Web.
  5. Atualizar/excluir a sub-rede ou rede virtual.

Se ainda tiver problemas com a integração do VNet após seguir os passos acima, por favor contacte o Suporte da Microsoft.

Resolução de problemas de rede

Também pode utilizar a Resolução de problemas de Rede para resolver problemas de ligação. Para abrir o solucionador de problemas de rede, vá à aplicação no portal do Azure. Selecione Diagnosticar e resolver problema e, em seguida, procure por Resolução de problemas de rede.

Problemas de conexão - Verifica o status da integração de rede virtual, incluindo a verificação se o IP privado foi atribuído a todas as instâncias do plano e as configurações de DNS. Se não estiver configurado um DNS personalizado, aplica-se o DNS do Azure predefinido. O solucionador de problemas também verifica dependências comuns de aplicações de função, incluindo conectividade com o Armazenamento do Azure e outras dependências de associações.

Captura de ecrã que mostra a executar o resolutor de problemas para questões de ligação.

Problemas de configuração - Esta resolução de problemas verifica se a sua sub-rede é válida para integração de rede virtual.

Captura de ecrã que mostra um solucionador de problemas em execução para resolver problemas de configuração.

Problema de exclusão de sub-rede/VNet - Esta solução de problemas verifica se sua sub-rede tem algum bloqueio e se tem algum link de associação de serviço não utilizado que possa estar bloqueando a exclusão da VNet/sub-rede.

Para saber mais sobre redes e Funções do Azure:

  • Last updated on