Opções de rede do Azure Functions

Este artigo descreve os recursos de rede disponíveis nas opções de hospedagem para o Azure Functions. Todas as opções de rede a seguir oferecem a você uma capacidade de acessar recursos sem usar endereços roteáveis pela Internet ou restringir o acesso à Internet a um aplicativo de funções.

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

Você pode hospedar aplicativos de funções de duas maneiras:

  • Escolha entre opções de plano executadas em uma infraestrutura multilocatário, com vários níveis de conectividade de rede virtual e opções de dimensionamento:
    • O plano de Consumo é dimensionado dinamicamente em resposta à carga e oferece opções de isolamento de rede mínimas.
    • O Plano Premium também é dimensionado dinamicamente e oferece isolamento de rede mais abrangente.
    • O plano do Serviço de Aplicativo do Azure opera em uma escala fixa e oferece isolamento de rede semelhante ao plano Premium.
  • Execute funções em um Ambiente do Serviço de Aplicativo. Esse método implanta sua função em sua rede virtual e oferece controle e isolamento de rede total.

Matriz de recursos de rede

Recurso Plano de Consumo Plano Premium Plano dedicado ASE Kubernetes
Restrições de IP de entrada e acesso ao site privado ✅Sim ✅Sim ✅Sim ✅Sim ✅Sim
Integração de rede virtual ❌Não ✅Sim (Regional) ✅Sim (regional e gateway) ✅Sim ✅Sim
Gatilhos de rede virtual (não HTTP) ❌Não ✅Sim ✅Sim ✅Sim ✅Sim
Conexões híbridas (somente Windows) ❌Não ✅Sim ✅Sim ✅Sim ✅Sim
Restrições de IP de saída ❌Não ✅Sim ✅Sim ✅Sim ✅Sim

Restrições de acesso de entrada

Você pode usar restrições de acesso para definir uma lista ordenada de prioridades dos endereços IP que podem ou não acessar o seu aplicativo. A lista pode incluir endereços IPv4 e IPv6 ou sub-redes específicas da rede virtual usando pontos de extremidade de serviço. Quando há uma ou mais entradas, há uma negação implícita de tudo no final da lista. As restrições de IP funcionam com todas as opções de hospedagem de função.

As restrições de acesso estão disponíveis no Serviço Premium, Consumoe Serviço de Aplicativo.

Observação

Com as restrições de rede em vigor, você pode implantar somente de dentro de sua rede virtual ou quando tiver colocado o endereço IP do computador que está usando para acessar o portal do Azure na lista de destinatários seguros. No entanto, você ainda pode gerenciar a função usando o portal.

Para saber mais, confira Restrições de acesso ao serviço do Serviço de Aplicativo do Azure.

Conexões de ponto de extremidade privado

O Ponto de Extremidade Privado do Azure é um adaptador de rede que conecta você de maneira privada e segura a um serviço que conta com o Link Privado do Azure. O Ponto de Extremidade Privado usa um endereço IP privado da rede virtual, colocando efetivamente o serviço na sua rede virtual.

É possível usar o ponto de extremidade privado para suas funções hospedadas nos planos de Serviço de aplicativo e Premium.

Ao criar uma conexão de ponto de extremidade privada de entrada para funções, você também precisará de um registro DNS para resolver o endereço privado. Por padrão, um registro DNS privado será criado para você ao criar um ponto de extremidade privado usando o portal do Azure.

Para saber mais, confira usar Pontos de extremidade privados para Aplicativos Web.

Para chamar outros serviços que têm uma conexão de ponto de extremidade privada, como armazenamento ou barramento de serviço, certifique-se de configurar o aplicativo para fazer chamadas de saída para pontos de extremidade privados.

Usar pontos de extremidade de serviço

Usando os pontos de extremidade de serviço, você pode restringir o acesso às sub-redes selecionadas da rede virtual do Azure. Para restringir o acesso a uma sub-rede específica, crie uma regra de restrição com um tipo de Rede Virtual. Você pode selecionar a assinatura, a rede virtual e a sub-rede às quais deseja permitir ou negar acesso.

Se os pontos de extremidade de serviço ainda não estiverem habilitados com o Microsoft.Web para a sub-rede que você selecionou, eles serão habilitados automaticamente, a menos que você marque a caixa de seleção Ignorar pontos de extremidade do serviço Microsoft.Web ausentes. 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 de você ter as permissões para habilitá-los na sub-rede.

Se você precisar que outra pessoa habilite os pontos de extremidade de serviço na sub-rede, marque a caixa de seleção Ignorar pontos de extremidade do serviço Microsoft.Web ausentes. O seu aplicativo será configurado para pontos de extremidade de serviço antecipando que eles serão habilitados mais tarde na sub-rede.

Captura de tela do painel "Adicionar restrição de IP" com o tipo Rede Virtual selecionado.

Você não pode usar pontos de extremidade de serviço para restringir o acesso a aplicativos que são executados em um Ambiente do Serviço de Aplicativo. Quando o seu aplicativo estiver em um Ambiente do Serviço de Aplicativo, você poderá controlar o acesso a ele aplicando as regras de acesso de IP.

Para saber como configurar os pontos de extremidade de serviço, consulte Estabelecer acesso ao site privado do Azure Functions.

Integração de rede virtual

A integração de rede virtual permite que seu aplicativo de funções acesse recursos dentro de uma rede virtual. O Azure Functions dá suporte a dois tipos de integração de rede virtual:

  • Os tipos de preço de computação dedicados, que incluem Básico, Standard, Premium, Premium v2 e Premium v3.
  • O Ambiente do Serviço de Aplicativo, que é implantado diretamente em sua rede virtual com infraestrutura de suporte dedicada e está usando os tipos de preço Isolado e Isolado v2.

O recurso de integração de VNet é usado em tipos de preço de computação dedicada do Serviço de Aplicativo do Azure. Se o aplicativo está em um Ambiente do Serviço de Aplicativo, ele já está em uma rede virtual e não exige o uso do recurso de Integração de VNet para acessar recursos na mesma rede virtual. Para obter mais informações sobre todos os recursos de rede, confira Recursos de rede do Serviço de Aplicativo.

A Integração de rede virtual concede ao seu aplicativo acesso a recursos da sua rede virtual, mas não permite acesso privado de entrada ao seu aplicativo por meio da rede virtual. Acesso ao site privado significa tornar seu aplicativo acessível somente de uma rede privada, como de dentro de uma rede virtual do Azure. A integração de rede virtual é usada apenas para fazer chamadas de saída do aplicativo para a rede virtual. O recurso de integração de rede virtual se comporta de maneira diferente quando é usado com redes virtuais na mesma região e com redes virtuais em outras regiões. O recurso Integração VNet tem duas variações:

  • Integração de rede virtual regional: quando se conecta a redes virtuais na mesma região, você precisa ter uma sub-rede dedicada na rede virtual com a qual está se integrando.
  • Integração de rede virtual exigida pelo gateway: quando se conecta diretamente à rede virtual em outras regiões ou a uma rede virtual clássica na mesma região, você precisa de um gateway de Rede Virtual do Azure criado na rede virtual de destino.

O recurso da Integração VNet:

  • Exige um tipo de preço de Serviço de Aplicativo Standard, Premium, Premium v2, Premium v3 ou Premium Elástico.
  • Dá suporte a TCP e UDP.
  • Funciona com aplicativos do Serviço de Aplicativo e aplicativos de funções.

Há algumas coisas às quais a integração de rede virtual não dá suporte, incluindo:

  • A montagem de uma unidade.
  • Integração do Windows Server Active Directory.
  • NetBIOS.

A integração de rede virtual necessária para o gateway fornece acesso a recursos somente na rede virtual de destino ou em redes conectadas à rede virtual de destino com emparelhamento ou VPNs. A integração de rede virtual exigida pelo gateway não habilita o acesso aos recursos disponíveis nas conexões do Azure ExpressRoute nem trabalha com pontos de extremidade de serviço.

Independentemente da versão usada, a integração de rede virtual concede ao seu aplicativo acesso a recursos da sua rede virtual, mas não permite acesso privado de entrada ao seu aplicativo por meio da rede virtual. Acesso ao site privado significa tornar seu aplicativo acessível somente de uma rede privada, como de dentro de uma rede virtual do Azure. A integração de rede virtual é usada apenas para fazer chamadas de saída do aplicativo para a rede virtual.

A integração de rede virtual no Azure Functions usa a infraestrutura compartilhada com aplicativos Web do Serviço de Aplicativo. Para saber mais sobre os dois tipos de integração de rede virtual, confira:

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

Habilitar a Integração VNET

  1. Vá para a folha Rede no portal do Aplicativo de Funções. Em Integração VNET, selecione Clique aqui para configurar.

  2. Selecione Adicionar VNet.

    Selecionar a Integração VNET

  3. A lista suspensa contém todas as redes virtuais do Azure Resource Manager na sua assinatura na mesma região. Selecione a VNET à qual deseja fazer a integração.

    Selecionar a VNET

    • O plano premium do Azure Functions dá suporte apenas à integração de VNet regional. Se a VNet estiver na mesma região, crie uma sub-rede ou selecione uma sub-rede preexistente vazia.
    • Para selecionar uma VNET em outra região, você precisará ter um gateway de VNET provisionado com o ponto a site habilitado. A integração VNet entre regiões só tem suporte para planos dedicados.

Durante a integração, o aplicativo é reiniciado. Quando a integração for concluída, você verá detalhes sobre a VNET à qual está integrado. Por padrão, Route All será habilitado e todo o tráfego será roteado para sua VNet.

Se você quiser que apenas o tráfego privado(tráfego RFC1918) seja roteado, siga as etapas na documentação do serviço de aplicativo.

Integração de rede virtual regional

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

  • Recursos em uma VNet na mesma região que seu aplicativo.
  • Recursos em VNets emparelhados com a VNet à qual seu aplicativo está integrado.
  • Serviços protegidos por ponto de extremidade de serviço.
  • Recursos nas conexões do Azure ExpressRoute.
  • Recursos na VNet com a qual você está integrado.
  • Recursos nas conexões emparelhadas, que incluem conexões do Azure ExpressRoute.
  • Pontos de extremidade privados

Ao usar a integração VNet com VNets na mesma região, você pode usar as seguintes funcionalidades de rede do Azure:

  • NSGs (grupos de segurança de rede) : 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 VNet para fornecer acesso de entrada ao seu aplicativo.
  • UDRs (tabelas de rotas) : você pode inserir uma tabela de rotas na sub-rede de integração para enviar o tráfego de saída para onde desejar.

Observação

Quando você roteia todo o tráfego de saída para sua VNet, ele está sujeito aos NSGs e UDRs que são aplicados à sua sub-rede de integração. Quando a VNet é integrada, o tráfego de saída do aplicativo de funções para endereços IP públicos ainda é enviado dos endereços listados nas propriedades do aplicativo, a menos que você forneça rotas que direcionam o tráfego para outro lugar.

A integração VNet regional não é capaz de usar a porta 25.

Há algumas limitações no uso da integração com VNets na mesma região:

  • Você não pode acessar recursos nas conexões de emparelhamento global.
  • A funcionalidade está disponível em todas as unidades de escala do Serviço de Aplicativo em Premium V2 e Premium v3. Também está disponível em Standard, mas somente em unidades de escala do Serviço de Aplicativo mais recentes. Se você estiver em uma unidade de escala mais antiga, só poderá usar a funcionalidade em um plano do Serviço de Aplicativo Premium V2. Se você quiser ter certeza de que pode usar a funcionalidade em um plano do Serviço de Aplicativo Standard, crie seu aplicativo em um plano do Serviço de Aplicativo Premium V3. Esses planos têm suporte apenas em nossas unidades de escala mais recentes. Se quiser, você poderá reduzir verticalmente depois disso.
  • A sub-rede de integração pode ser usada por apenas um plano do Serviço de Aplicativo.
  • A funcionalidade não pode ser usada por aplicativos de plano isolado que estejam em um Ambiente do Serviço de Aplicativo.
  • A funcionalidade requer uma sub-rede não utilizada que seja /28 ou maior em uma VNet do Azure Resource Manager.
  • O aplicativo e a VNet devem estar na mesma região.
  • Você não pode excluir uma VNet com um aplicativo integrado. Remova a integração antes de excluir a VNet.
  • Você só pode ter uma integração de VNet regional por plano do Serviço de Aplicativo. Vários aplicativos no mesmo plano do Serviço de Aplicativo podem usar a mesma VNET.
  • Você não pode alterar a assinatura de um aplicativo ou plano enquanto há um aplicativo usando a integração de VNet regional.
  • Seu aplicativo não pode resolver endereços em Zonas Privadas do DNS do Azure sem alterações de configuração.

Sub-redes

A integração de VNet depende de uma sub-rede dedicada. Quando você provisiona uma sub-rede, a sub-rede do Azure perde cinco IPs desde o início. Um endereço da sub-rede de integração é usado para cada instância do plano. Quando você dimensiona seu aplicativo para quatro instâncias, são usados quatro endereços.

Quando você aumenta ou reduz verticalmente, o espaço de endereço necessário é dobrado por um curto período de tempo. Isso afeta as instâncias reais disponíveis, com suporte, para um determinado tamanho de sub-rede. A tabela a seguir mostra o máximo de endereços disponíveis por bloco CIDR e o impacto que isso tem na escala horizontal:

Tamanho do bloco CIDR Máximo de endereços disponíveis: Escala horizontal máxima (instâncias)*
/ 28 11 5
/ 27 27 13
/ 26 59 29

* Pressupõe que você precisará aumentar ou reduzir verticalmente em qualquer tamanho ou SKU em algum momento.

Como o tamanho da sub-rede não pode ser alterado após a atribuição, use uma sub-rede que seja grande o suficiente para acomodar qualquer escala que seu aplicativo possa alcançar. Para evitar problemas com a capacidade de sub-rede para funções Premium planos, você deve usar um/24 com endereços 256 para Windows e a/26 com endereços 64 para Linux.

Quando você quiser que seus aplicativos em outro plano alcancem uma VNet que já esteja conectada por aplicativos em outro plano, selecione uma sub-rede diferente daquela que está sendo usada pela integração de VNet pré-existente.

A funcionalidade tem suporte total para aplicativos Windows e Linux, incluindo contêineres personalizados. Todos os comportamentos agem da mesma entre aplicativos do Windows e aplicativos do Linux.

Pontos de extremidade de serviço

Para fornecer um nível mais alto de segurança, você pode restringir vários serviços do Azure a uma rede virtual usando pontos de extremidade de serviço. A integração VNet regional permite que seu aplicativo de funções alcance serviços do Azure que são protegidos com pontos de extremidade de serviço. Essa configuração tem suporte em todos os planos que dão suporte à integração de rede virtual. Para acessar um serviço protegido de ponto de extremidade de serviço, você deve fazer o seguinte:

  1. Configure a integração VNet regional com seu aplicativo de funções para se conectar a uma sub-rede específica.
  2. Vá para o serviço de destino e configure os pontos de extremidade de serviço em relação à sub-rede de integração.

Para obter mais detalhes, confira Pontos de extremidade de serviço de rede virtual.

Grupos de segurança de rede

Você pode usar grupos de segurança de rede para bloquear o tráfego de entrada e saída para recursos em uma VNet. Um aplicativo que usa a Integração VNET regional pode usar um grupo de segurança de rede para bloquear o tráfego de saída para recursos na VNet ou na Internet. Para bloquear o tráfego para endereços públicos, você deve ter integração VNet com a rota todos habilitada. As regras de entrada em um NSG não se aplicam ao seu aplicativo porque a integração de VNet afeta apenas o tráfego de saída de seu aplicativo.

Para controlar o tráfego de entrada para seu aplicativo, use a funcionalidade de Restrições de acesso. Um NSG aplicado à sua sub-rede de integração estará em vigor independentemente de quaisquer rotas aplicadas à sua sub-rede de integração. Se seu aplicativo de funções for VNet integrado com a rota All habilitada 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ído à sua sub-rede de integração. Quando a rota All não está habilitada, os NSGs são aplicados somente 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 de destino RFC1918. Quando a rota All está habilitada, todas as suas chamadas de saída são afetadas. Quando Route All está desabilitada, somente o tráfego privado (RFC1918) é afetado pelas tabelas de rotas. As rotas definidas em sua sub-rede de integração não afetarão as respostas a solicitações de aplicativo de entrada. Os destinos comuns podem incluir dispositivos de firewall ou gateways.

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

As rotas de BGP (Border Gateway Protocol) também afetam o tráfego do aplicativo. Se você tiver rotas de BGP de, por exemplo, um gateway de ExpressRoute, o tráfego de saída do aplicativo será afetado. Por padrão, as rotas de BGP afetam apenas o tráfego de destino RFC1918. Quando seu aplicativo de funções é integrado à VNet com a rota All habilitada, todo o tráfego de saída pode ser afetado por suas rotas BGP.

Zonas privadas do DNS do Azure

Depois que o aplicativo se integra à sua VNet, ele usa o mesmo servidor DNS com o qual sua VNet está configurada. Por padrão, seu aplicativo não funcionará com as zonas privadas do DNS do Azure. Para que funcione com as zonas privadas do DNS do Azure, você precisa adicionar as seguintes configurações de aplicativo:

  • WEBSITE_VNET_ROUTE_ALL com valor 1

Essa configuração envia todas as suas chamadas de saída do seu aplicativo para sua VNet e permite que seu aplicativo acesse uma zona privada de DNS do Azure. Com essas configurações, seu aplicativo pode usar o DNS do Azure consultando a zona privada de DNS no nível de trabalho.

Pontos de extremidade privados

Se você quiser fazer chamadas para Pontos de extremidade privados, deverá certificar-se de que suas pesquisas de DNS sejam resolvidas em relação ao ponto de extremidades privado. Você pode impor esse comportamento de uma das seguintes maneiras:

  • Integrar com as zonas privadas do DNS do Azure. Quando sua VNet não tem um servidor DNS personalizado, isso é feito automaticamente.
  • Gerenciar o ponto de extremidade privado no servidor DNS usado pelo seu aplicativo. Para fazer isso, você precisa saber o endereço do ponto de extremidade privado e apontar o ponto de extremidade que está tentando acessar para esse endereço usando um registro A.
  • Configure seu próprio servidor DNS para encaminhar para as zonas privadas do DNS do Azure.

Restringir a sua conta de armazenamento a uma rede virtual

Quando você cria um aplicativo de funções, é necessário criar ou vincular uma conta de Armazenamento do Azure de uso geral que dá ao armazenamento de Tabelas, Blobs e Filas. Você pode substituir essa conta de armazenamento por uma que seja protegida por pontos de extremidade de serviço ou pontos de extremidade privados.

Há suporte para esse recurso em todas as SKUs compatíveis com rede virtual do Windows no plano Dedicado (Serviço de Aplicativo) e nos planos Premium. Também há suporte de DNS privado para SKUs compatíveis com rede virtual do Linux. Não há suporte para o plano de consumo e o DNS personalizado em planos do Linux. Para saber como configurar uma função com uma conta de armazenamento restrita a uma rede privada, consulte Restringir a conta de armazenamento a uma rede virtual.

Usar referências de Key Vault

Você pode usar referências do Azure Key Vault para usar segredos do Azure Key Vault no seu aplicativo Azure Functions sem exigir alterações de código. O Azure Key Vault é um serviço que fornece gerenciamento centralizado de segredos, com controle total sobre políticas de acesso e histórico de auditoria.

Se a integração de rede virtual estiver configurada para o aplicativo, as referências do Key Vault poderão ser usadas para retirar segredos de um cofre restrito à rede.

Gatilhos de rede virtual (não HTTP)

No momento, você pode usar funções de gatilho não HTTP de dentro de uma rede virtual de duas maneiras:

  • Execute seu aplicativo de funções em um plano Premium e habilite o suporte ao gatilho de rede virtual.
  • Execute seu aplicativo de funções em um plano do Serviço de Aplicativo ou Ambiente de Serviço de Aplicativo.

Plano Premium com gatilhos de rede virtual

Ao executar um plano Premium, você poderá conectar funções de gatilho não HTTP a serviços que são executados dentro de uma rede virtual. Para fazer isso, você deverá habilitar o suporte ao gatilho de rede virtual para seu aplicativo de funções. A configuração Monitoramento de Escala de Runtime está localizada no portal do Azure em Configuração > Configurações de runtime de função.

VNETToggle

Você também pode habilitar gatilhos de rede virtual usando o seguinte comando de CLI do Azure:

az resource update -g <resource_group> -n <function_app_name>/config/web --set properties.functionsRuntimeScaleMonitoringEnabled=1 --resource-type Microsoft.Web/sites

Dica

A habilitação dos gatilhos de rede virtual pode ter um impacto sobre o desempenho do aplicativo, pois as instâncias do plano Serviço de Aplicativo precisarão monitorar seus gatilhos para determinar quando escalar. Esse impacto é provavelmente muito pequeno.

Os gatilhos de rede virtual têm suporte na versão 2.x e superior do tempo de execução do Functions. Há suporte para os seguintes tipos de gatilho não HTTP.

Extensão Versão mínima
Microsoft.Azure.WebJobs.Extensions.Storage 3.0.10 ou superior
Microsoft.Azure.WebJobs.Extensions.EventHubs 4.1.0 ou superior
Microsoft.Azure.WebJobs.Extensions.ServiceBus 3.2.0 ou superior
Microsoft.Azure.WebJobs.Extensions.CosmosDB 3.0.5 ou superior
Microsoft.Azure.WebJobs.Extensions.DurableTask 2.0.0 ou superior

Importante

Quando você habilita o suporte ao gatilho de rede virtual, somente os tipos de gatilho mostrados na tabela anterior são dimensionados dinamicamente com seu aplicativo. Você ainda pode usar gatilhos que não estão na tabela, mas eles não são dimensionados além da contagem de instâncias previamente inicializadas. Para obter a lista completa de gatilhos, confira Gatilhos e associações.

Plano do Serviço de Aplicativo e Ambiente do Serviço de Aplicativo com gatilhos de rede virtual

Quando seu aplicativo de funções é executado em um plano do Serviço de Aplicativo ou em um Ambiente do Serviço de Aplicativo, você pode usar funções de gatilho não HTTP. Para que suas funções sejam disparadas corretamente, você deverá estar conectado a uma rede virtual com acesso ao recurso definido na conexão do gatilho.

Por exemplo, suponha que você deseja configurar o Azure Cosmos DB para aceitar o tráfego somente de uma rede virtual. Nesse caso, você deve implantar seu aplicativo de funções em um plano do Serviço de Aplicativo que fornece integração de rede virtual com essa rede virtual. A integração permite que uma função seja disparada por esse recurso do Azure Cosmos DB.

Conexões Híbridas

Conexões Híbridas é um recurso da Retransmissão do Azure que você pode usar para acessar recursos do aplicativo em outras redes. Ele fornece acesso de seu aplicativo para um ponto de extremidade do aplicativo. Não é possível usá-lo para acessar seu aplicativo. O recurso Conexões Híbridas está disponível para funções executadas no Windows em todos os planos, exceto no plano de Consumo.

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

Para saber mais, confira a Documentação do Serviço de Aplicativo para Conexões Híbridas. Essas mesmas etapas de configuração dão suporte ao Azure Functions.

Importante

Só há suporte para Conexões Híbridas em planos do Windows. Não há suporte para o Linux.

Restrições de IP de saída

As restrições de IP de saída estão disponíveis em um plano Premium, plano do Serviço de Aplicativo ou Ambiente do Serviço de Aplicativo. Você pode configurar as restrições de saída para a rede virtual em que seu Ambiente do Serviço de Aplicativo está implantado.

Quando você integra um aplicativo de funções em um plano Premium ou 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. Integrando seu aplicativo de funções com uma VNet com a rota All habilitada, 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 saber como controlar o IP de saída usando uma rede virtual, consulte Tutorial: Controlar o IP de saída do Azure Functions com um gateway da NAT da rede virtual do Azure.

Automação

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

Solução de problemas

Embora o recurso seja fácil de configurar, isso não significa que sua experiência estará livre de problemas. Se tiver problemas para acessar o ponto de extremidade desejado, existem alguns utilitários que você pode usar para testar a conectividade do console do aplicativo. Há dois consoles que você pode usar. Um deles é o console do Kudu e o outro é o console no portal do Azure. Para acessar o console do Kudu do aplicativo, vá para Ferramentas > Kudu. Você também pode acessar o console do Kudo em [sitename].scm.azurewebsites.net. Depois que o site for carregado, vá para a guia Console de depuração. Para acessar o console do portal do Azure hospedado do seu aplicativo , vá para o > Console de ferramentas.

Ferramentas

Em aplicativos nativos do Windows, as ferramentas ping, nslookup e tracert não funcionam por meio do console devido a restrições de segurança (funcionam em contêineres personalizados do Windows). Para compensar essa ausência, duas ferramentas separadas foram adicionadas. Para testar a funcionalidade do DNS, adicionamos uma ferramenta chamada nameresolver.exe. A sintaxe do é:

nameresolver.exe hostname [optional: DNS Server]

Você pode usar a nameresolver para verificar os nomes de host de que seu aplicativo depende. Desta forma, você pode testar se há algo configurado incorretamente 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 de ambiente WEBSITE_DNS_SERVER e WEBSITE_DNS_ALT_SERVER.

Observação

A ferramenta nameresolver.exe atualmente não funciona em contêineres personalizados do Windows.

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

tcpping.exe hostname [optional: port]

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

Depurar o acesso a recursos hospedados na rede virtual

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

  • Há um firewall no caminho. Se você tiver um firewall no caminho, atingiu o tempo limite do TCP. O tempo limite de TCP é 21 segundos neste caso. Use 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 do DNS é de 3 segundos por servidor DNS. Se você tiver dois servidores DNS, o tempo limite será de seis segundos. Use nameresolver para ver se o DNS está funcionando. Você não pode usar o nslookup, porque ele não usa o DNS com o qual sua rede virtual está configurada. Se estiver inacessível, você pode ter um firewall ou NSG bloqueando o acesso ao DNS ou pode estar inoperante.

Se esses itens não resolverem seu problema, procure por coisas simples primeiro, como:

Integração de rede virtual regional

  • Seu destino é um endereço não RFC1918 e você não tem Rotear Todos habilitado?
  • Há um NSG bloqueando a saída de sua sub-rede de integração?
  • Se você estiver entrando no Azure ExpressRoute ou em uma VPN, seu gateway local será configurado para rotear o tráfego de volta para o Azure? Se você puder acessar pontos de extremidade em sua rede virtual, mas não no local, verifique suas rotas.
  • Você tem permissões suficientes para definir a delegação na sub-rede de integração? Durante a configuração de integração da rede virtual regional, sua sub-rede de integração é delegada para Microsoft.Web/serverFarms. A interface do usuário de integração da VNet delega a sub-rede para 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á para a interface do usuário da sub-rede da rede virtual do Azure e defina a delegação para Microsoft. Web/serverFarms.

Integração de rede virtual exigida por gateway

  • 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 em execução no portal? Se o gateway estiver inativo, ative-o.
  • Os certificados estão sincronizados ou você suspeita que a configuração da rede foi alterada? Se os certificados estiverem fora de sincronia ou se você suspeitar que uma alteração foi feita em sua configuração de rede virtual que não foi sincronizada com seus ASPs, selecione Sincronizar rede.
  • Se você estiver entrando no Azure ExpressRoute ou em uma VPN, seu gateway local será configurado para rotear o tráfego de volta para o Azure? Se você puder acessar pontos de extremidade em sua rede virtual, mas não no local, verifique suas rotas.
  • Você está tentando usar um gateway de coexistência que dá suporte a ponto a site e ExpressRoute? Não há suporte para gateways de coexistência com integração de rede virtual.

A depuração de problemas de rede é um desafio porque você não pode ver o que está bloqueando o acesso a uma combinação de hosts:porta específica. Esses motivos incluem:

  • você tem um firewall no seu host que impede o acesso à porta do aplicativo usando o intervalo de IP ponto a site. o cruzamento de sub-redes geralmente exige acesso Público.
  • o host de destino está inoperante.
  • seu aplicativo está inoperante.
  • você tinha o IP ou nome de host incorreto.
  • seu aplicativo está escutando em uma porta diferente da que você esperava. Você pode corresponder a sua ID de processo com a porta de escuta usando "netstat -aon" no host do ponto de extremidade.
  • Os grupos de segurança de rede estão configurados de modo a impedir o acesso ao host do aplicativo e à porta do 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 intervalo de endereços de ponto a site, portanto, você precisa permitir o acesso de todo o intervalo de endereços.

Mais etapas de depuração incluem:

  • Conecte-se a uma VM na sua VNet e tente acessar o host:porta do recurso de lá. Para testar o acesso TCP, use o comando do PowerShell test-netconnection. A sintaxe do é:

    test-netconnection hostname [optional: -Port]
    
  • Abra um aplicativo em uma VM e teste o acesso a esse host e porta a partir do console do seu aplicativo usando tcpping.

Recursos locais

Se o aplicativo não puder acessar um recurso local, verifique se é possível acessar o recurso da sua VNet. Use o comando do PowerShell test-netconnection para verificar se há acesso TCP. Se sua VM não conseguir acessar seu recurso local, sua conexão VPN ou ExpressRoute pode não estar configurada corretamente.

Se sua VM hospedada em rede virtual pode alcançar seu sistema local, mas seu aplicativo não, a causa é provavelmente um dos seguintes motivos:

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

Próximas etapas

Para saber mais sobre rede e o Azure Functions: