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

Este artigo descreve as funcionalidades de networking disponíveis nas opções de hospedagem para Funções Azure. Todas as seguintes opções de networking dão-lhe alguma capacidade de aceder a recursos sem usar endereços de internet-routable ou para restringir o acesso à Internet a uma aplicação de função.

Os modelos de hospedagem têm diferentes níveis de isolamento de rede disponíveis. Escolher o correto ajuda-o a cumprir os requisitos de isolamento da rede.

Pode hospedar aplicações de função de várias maneiras:

  • Pode escolher entre opções de plano que funcionam numa infraestrutura multitenante, com vários níveis de conectividade de rede virtual e opções de escala:
    • O plano de consumo escala dinamicamente em resposta à carga e oferece opções mínimas de isolamento de rede.
    • O plano Premium também escala dinamicamente e oferece um isolamento de rede mais abrangente.
    • O plano Azure App Service funciona a uma escala fixa e oferece isolamento de rede semelhante ao plano Premium.
  • Pode executar funções num Ambiente de Serviço de Aplicações. Este método implementa a sua função na sua rede virtual e oferece controlo e isolamento completos da rede.

Matriz de funcionalidades de networking

Funcionalidade Plano de consumo Plano Premium Plano dedicado ASE Kubernetes
Restrições ip de entrada e acesso ao site privado ✅Yes ✅Yes ✅Yes ✅Yes ✅Yes
Integração de rede virtual ❌No ✅Sim (Regional) ✅Sim (Regional e Gateway) ✅Yes ✅Yes
Gatilhos de rede virtuais (não HTTP) ❌No ✅Yes ✅Yes ✅Yes ✅Yes
Ligações híbridas (apenas para Windows) ❌No ✅Yes ✅Yes ✅Yes ✅Yes
Restrições ip de saída ❌No ✅Yes ✅Yes ✅Yes ✅Yes

Restrições de acesso à entrada

Pode utilizar as restrições de acesso para definir uma lista de endereços IP encomendados por prioridade que sejam permitidos ou impedidos de aceder à sua aplicação. A lista pode incluir endereços IPv4 e IPv6, ou sub-redes de rede virtuais específicas utilizando pontos finais de serviço. Quando há uma ou mais entradas, existe um "negar tudo" implícito no final da lista. As restrições ip funcionam com todas as opções de hospedagem de funções.

As restrições de acesso estão disponíveis no Serviço premium, consumoe aplicação.

Nota

Com as restrições de rede em vigor, só pode ser implantado a partir da sua rede virtual, ou quando tiver colocado o endereço IP da máquina que está a utilizar para aceder ao portal Azure na lista de Destinatários Seguros. No entanto, ainda é possível gerir a função utilizando o portal.

Para saber mais, consulte as restrições de acesso estático do Azure App Service.

Utilizar pontos finais de serviço

Ao utilizar pontos finais de serviço, pode restringir o acesso a sub-redes de rede virtuais Azure selecionadas. Para restringir o acesso a uma sub-rede específica, crie uma regra de restrição com um tipo de Rede Virtual. Pode então selecionar a subscrição, a rede virtual e a sub-rede a que pretende permitir ou negar o acesso.

Se os pontos finais de serviço ainda não estiverem ativados com o Microsoft.Web para a sub-rede que selecionou, serão automaticamente ativados, a menos que selecione a caixa de verificação de pontos finais do serviço Microsoft.Web em falta. O cenário em que poderá querer ativar os pontos finais do serviço na app, mas não a sub-rede, depende principalmente de ter as permissões para os ativar na sub-rede.

Se precisar de outra pessoa para ativar os pontos finais do serviço na sub-rede, selecione a caixa de verificação de pontos finais do serviço Microsoft.Web em falta. A sua aplicação será configurada para os pontos finais de serviço, antecipando-se a sua ativação posterior na sub-rede.

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

Não é possível utilizar pontos finais de serviço para restringir o acesso a aplicações que funcionam num Ambiente de Serviço de Aplicações. Quando a sua aplicação está num Ambiente de Serviço de Aplicações, pode controlar o acesso à ela aplicando regras de acesso IP.

Para aprender a configurar pontos finais de serviço, consulte o Site privado Do Azure Functions.

Conexões de ponto final privado

O Ponto Final Privado do Azure é uma interface de rede que o liga em privado e com segurança a um serviço com a tecnologia do 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.

Pode utilizar o Private Endpoint para as suas funções hospedadas nos planos Premium e App Service.

Ao criar uma ligação de ponto final privado de entrada para funções, também necessitará de um registo DNS para resolver o endereço privado. Por predefinição, será criado um registo de DNS privado para si ao criar um ponto final privado utilizando o portal Azure.

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

Para ligar para outros serviços que tenham uma ligação privada de ponto final, como armazenamento ou autocarro de serviço, certifique-se de configurar a sua app para fazer chamadas de saída para pontos finais privados.

Integração da rede virtual

A integração de rede virtual permite que a sua aplicação de função aceda a recursos dentro de uma rede virtual. A Azure Functions suporta dois tipos de integração de rede virtual:

  • Os sistemas multitenantes que suportam toda a gama de planos de preços, exceto isolados.
  • O Ambiente de Serviço de Aplicações, que se implanta no seu VNet e suporta aplicações de planos de preços isolados.

A funcionalidade de Integração VNet é utilizada em aplicações multitenantes. Se a sua aplicação está no Ambiente de Serviço de Aplicações,então já está num VNet e não necessita de utilização da funcionalidade de Integração VNet para alcançar recursos no mesmo VNet. Para obter mais informações sobre todas as funcionalidades de networking, consulte as funcionalidades de networking do Serviço de Aplicações.

A VNet Integration dá à sua aplicação acesso a recursos no seu VNet, mas não concede acesso privado à sua aplicação a partir do VNet. O acesso ao site privado refere-se a tornar uma aplicação acessível apenas a partir de uma rede privada, como por exemplo dentro de uma rede virtual Azure. A VNet Integration é usada apenas para fazer chamadas de saída da sua app para o seu VNet. A funcionalidade de Integração VNet comporta-se de forma diferente quando é usada com VNet na mesma região e com vNet noutras regiões. A funcionalidade de Integração VNet tem duas variações:

  • Integração Regional VNet: Quando ligar às redes virtuais do Azure Resource Manager na mesma região, deve ter uma sub-rede dedicada no VNet com a qual se está a integrar.
  • Integração VNet exigida pelo Gateway: Quando se conecta ao VNet noutras regiões ou a uma rede virtual clássica na mesma região, precisa de um gateway de rede virtual Azure a provisionado no VNet alvo.

As funcionalidades de Integração VNet:

  • Requer um plano de preços Standard, Premium, PremiumV2, PremiumV3 ou Elastic Premium.
  • Apoiar TCP e UDP.
  • Trabalhe com aplicações e aplicações de função do Azure App Service.

Há algumas coisas que a Integração VNet não suporta, como:

  • Montar uma unidade.
  • Integração do Diretório Ativo.
  • O NetBIOS.

A Integração VNet exigida pelo Gateway fornece acesso a recursos apenas no VNet alvo ou em redes ligadas ao VNet alvo com peering ou VPNs. A Integração VNet exigida pelo Gateway não permite o acesso aos recursos disponíveis em todas as ligações Azure ExpressRoute ou trabalha com pontos finais de serviço.

Independentemente da versão utilizada, a VNet Integration dá à sua aplicação acesso a recursos no seu VNet, mas não concede acesso privado à sua aplicação a partir do VNet. O acesso ao site privado refere-se a tornar a sua aplicação acessível apenas a partir de uma rede privada, como por exemplo dentro de um Azure VNet. A Integração VNet destina-se apenas a fazer chamadas de saída da sua app para o seu VNet.

A integração virtual da rede em Azure Functions utiliza infraestruturas partilhadas com aplicações web do App Service. Para saber mais sobre os dois tipos de integração de rede virtual, consulte:

Para aprender a configurar a integração de rede virtual, consulte integrar uma aplicação de função com uma rede virtual Azure.

Integração de rede virtual regional

A utilização da Integração VNet regional permite que a sua aplicação aceda:

  • Recursos num VNet na mesma região que a sua aplicação.
  • Os recursos em VNets espreguiçadados para o VNet a sua aplicação está integrada.
  • Serviços seguros de serviço.
  • Recursos através das ligações Azure ExpressRoute.
  • Recursos no VNet com os qual está integrado.
  • Recursos através de ligações espreitadas, que incluem ligações Azure ExpressRoute.
  • Pontos finais privados

Quando utilizar a Integração VNet com VNets na mesma região, pode utilizar as seguintes funcionalidades de networking Azure:

  • Grupos de segurança de rede (NSGs): Pode bloquear o tráfego de saída com um NSG colocado na sua sub-rede de integração. As regras de entrada não se aplicam porque não pode usar a Integração VNet para fornecer acesso à sua aplicação.
  • Tabelas de rotas (UDRs): Pode colocar uma tabela de rota na sub-rede de integração para enviar o tráfego de saída onde quiser.

Por padrão, a sua aplicação apenas encaminha o tráfego RFC1918 para o seu VNet. Se pretender encaminhar todo o tráfego de saída para o seu VNet, utilize os seguintes passos para adicionar a WEBSITE_VNET_ROUTE_ALL definição na sua aplicação:

  1. Aceda ao UI de configuração no portal da aplicação. Selecione Nova definição da aplicação.

  2. WEBSITE_VNET_ROUTE_ALLInsira na caixa Nome e introduza na 1 caixa Valor.

    Fornecer definição de aplicação

  3. Selecione OK.

  4. Selecione Guardar.

Nota

Quando encaminha todo o tráfego de saída para o seu VNet, está sujeito aos NSGs e UDRs que são aplicados na sua sub-rede de integração. Quando WEBSITE_VNET_ROUTE_ALL estiver programado para , o tráfego de saída ainda é enviado a partir dos 1 endereços que estão listados nas propriedades da sua aplicação, a menos que forneça rotas que direcionem o tráfego para outro lugar.

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

Existem algumas limitações com a utilização da Integração VNet com VNets na mesma região:

  • Não se pode alcançar recursos através de ligações globais de observação.
  • A funcionalidade está disponível em todas as unidades de escala de Serviço de Aplicações em Premium V2 e Premium V3. Também está disponível no Standard, mas apenas a partir de novas unidades de escala de Serviço de Aplicações. Se estiver numa unidade de escala mais antiga, só pode utilizar a funcionalidade a partir de um plano de Serviço de Aplicações Premium V2. Se quiser ter a certeza de que pode utilizar a funcionalidade num plano standard de Serviço de Aplicações, crie a sua aplicação num plano premium de Serviço de Aplicações V3. Esses planos só são apoiados nas nossas unidades de escala mais recentes. Pode reduzir a escala se quiser depois disso.
  • A sub-rede de integração pode ser utilizada apenas por um plano de Serviço de Aplicações.
  • A funcionalidade não pode ser utilizada por aplicações de plano isolado que se encontrem num Ambiente de Serviço de Aplicações.
  • A funcionalidade requer uma sub-rede não utilizada que seja um /28 ou maior num VNet do Gestor de Recursos Azure.
  • A aplicação e o VNet devem estar na mesma região.
  • Não é possível eliminar um VNet com uma aplicação integrada. Remova a integração antes de eliminar o VNet.
  • Você pode ter apenas uma integração regional VNet por plano de Serviço de Aplicação. Várias aplicações no mesmo plano de Serviço de Aplicações podem usar o mesmo VNet.
  • Não é possível alterar a subscrição de uma app ou de um plano enquanto há uma aplicação que está a usar a Integração VNet regional.
  • A sua aplicação não consegue resolver endereços em Zonas Privadas Azure DNS sem alterações de configuração.

A Integração VNet depende de uma sub-rede dedicada. Quando se disponibiliza uma sub-rede, a sub-rede Azure perde cinco IPs desde o início. Um endereço é utilizado a partir da sub-rede de integração para cada instância de plano. Quando escala a sua aplicação para quatro instâncias, então são utilizados quatro endereços.

Quando se escala ou desce em tamanho, o espaço de endereço necessário é duplicado por um curto período de tempo. Isto afeta os casos reais e disponíveis suportados para um determinado tamanho da sub-rede. O quadro a seguir mostra tanto os endereços máximos disponíveis por bloco CIDR como o impacto que isso tem na escala horizontal:

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

*Assume que terá de escalar para cima ou para baixo em tamanho ou SKU em algum momento.

Uma vez que o tamanho da sub-rede não pode ser alterado após a atribuição, use uma sub-rede suficientemente grande para acomodar qualquer escala que a sua aplicação possa alcançar. Para evitar problemas com capacidade de sub-rede, deve utilizar um /26 com 64 endereços.

Quando quiser que as suas apps num outro plano cheguem a um VNet que já esteja ligado a apps noutro plano, selecione uma sub-rede diferente da que está a ser usada pela integração VNet pré-existente.

A funcionalidade é totalmente suportada tanto para aplicações Windows como Linux, incluindo recipientes personalizados. Todos os comportamentos agem da mesma forma entre aplicações Windows e aplicações Linux.

Pontos finais de serviço

A Integração Regional de VNet permite-lhe chegar aos serviços Azure que são protegidos com pontos finais de serviço. Para aceder a um serviço de serviço seguro de ponto final, tem de fazer o seguinte:

  1. Configure a Integração Regional de VNet com a sua aplicação web para se conectar a uma sub-rede específica para integração.
  2. Vá ao serviço de destino e configuure os pontos finais do serviço contra a sub-rede de integração.

Grupos de segurança de rede

Pode utilizar grupos de segurança de rede para bloquear o tráfego de entrada e saída de recursos num VNet. Uma aplicação que utiliza a Integração VNet regional pode usar um grupo de segurança de rede para bloquear o tráfego de saída para recursos no seu VNet ou na internet. Para bloquear o tráfego para endereços públicos, tem de ter a definição de aplicação WEBSITE_VNET_ROUTE_ALL definida para 1 . As regras de entrada num NSG não se aplicam à sua aplicação porque a Integração VNet afeta apenas o tráfego de saída da sua aplicação.

Para controlar o tráfego de entrada na sua aplicação, utilize a funcionalidade Restrições de Acesso. Um NSG aplicado à sua sub-rede de integração está em vigor, independentemente de quaisquer rotas aplicadas à sua sub-rede de integração. Se WEBSITE_VNET_ROUTE_ALL estiver definido e não tiver rotas que 1 afetem o tráfego de endereço público na sua sub-rede de integração, todo o tráfego de saída ainda está sujeito a NSGs atribuídos à sua sub-rede de integração. Quando WEBSITE_VNET_ROUTE_ALL não está definido, os NSGs são aplicados apenas ao tráfego RFC1918.

Rotas

Pode utilizar as tabelas de rotas para encaminhar o tráfego de saída da sua app para onde quiser. Por predefinição, as tabelas de rotas apenas afetam o tráfego de destino RFC1918. Quando se prepara WEBSITE_VNET_ROUTE_ALL 1 para, todas as suas chamadas de saída são afetadas. As rotas que estão definidas na sua sub-rede de integração não afetarão respostas a pedidos de aplicações de entrada. Os destinos comuns podem incluir dispositivos de firewall ou gateways.

Se quiser encaminhar todo o tráfego de saída no local, pode utilizar uma mesa de rota para enviar todo o tráfego de saída para o seu gateway ExpressRoute. Se fizer a rota do tráfego para um gateway, certifique-se de definir rotas na rede externa para enviar quaisquer respostas de volta.

As rotas do Border Gateway Protocol (BGP) também afetam o tráfego da sua aplicação. Se tiver rotas BGP a partir de algo como um gateway ExpressRoute, o tráfego de saída da sua aplicação é afetado. Por padrão, as rotas BGP afetam apenas o tráfego de destino RFC1918. Quando WEBSITE_VNET_ROUTE_ALL estiver programado para , todo o tráfego de saída pode ser afetado pelas suas rotas 1 BGP.

Zonas privadas Azure DNS

Depois de a sua aplicação se integrar com o seu VNet, utiliza o mesmo servidor DNS com o qual o seu VNet está configurado. Por padrão, a sua aplicação não funcionará com zonas privadas Azure DNS. Para trabalhar com as zonas privadas Azure DNS, é necessário adicionar as seguintes definições de aplicações:

  1. WEBSITE_DNS_SERVER com valor 168.63.129.16
  2. WEBSITE_VNET_ROUTE_ALL com valor 1

Estas definições enviam todas as suas chamadas de saída da sua app para o seu VNet e permitem que a sua aplicação aceda a uma zona privada do Azure DNS. Com estas definições, a sua aplicação pode utilizar o Azure DNS consultando a zona privada dns ao nível do trabalhador.

Pontos Finais Privados

Se quiser fazer chamadas para Private Endpoints,então deve certificar-se de que as suas pesquisas de DNS resolvem-se para o ponto final privado. Pode impor este comportamento de uma das seguintes formas:

  • Integre com zonas privadas Azure DNS. Quando o seu VNet não tem um servidor DNS personalizado, isto é feito automaticamente.
  • Gerencie o ponto final privado no servidor DNS utilizado pela sua aplicação. Para isso, deve conhecer o endereço de ponto final privado e, em seguida, indicar o ponto final que está a tentar alcançar para esse endereço usando um registo A.
  • Configure o seu próprio servidor DNS para encaminhar para as zonas privadas do Azure DNS.

Ligar ao ponto final de serviço recursos seguros

Para fornecer um nível de segurança mais elevado, pode restringir uma série de serviços Azure a uma rede virtual utilizando pontos finais de serviço. Em seguida, deve integrar a sua aplicação de função com aquela rede virtual para aceder ao recurso. Esta configuração é suportada em todos os planos que suportam a integração de redes virtuais.

Para saber mais, consulte os pontos finais do serviço de rede Virtual.

Restringir a sua conta de armazenamento a uma rede virtual

Quando criar uma aplicação de função, deve criar ou ligar para uma conta de Armazenamento Azure de uso geral que suporte o armazenamento de Blob, Queue e Table. Pode substituir esta conta de armazenamento por uma que esteja segura com pontos finais de serviço ou ponto final privado.

Atualmente, esta funcionalidade funciona para todos os SKUs virtuais suportados pela rede do Windows no plano Dedicado (Serviço de Aplicações) e para o plano Premium. O plano de consumo não é apoiado. Para aprender a configurar uma função com uma conta de armazenamento restrita a uma rede privada, consulte Restringir a sua conta de armazenamento a uma rede virtual.

Utilizar as referências do Key Vault

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

Atualmente, as referências do Key Vault não funcionarão se o cofre da chave estiver seguro com pontos finais de serviço. Para se ligar a um cofre de chaves utilizando a integração virtual da rede, tem de ligar para o Key Vault no seu código de aplicação.

Gatilhos de rede virtuais (não HTTP)

Atualmente, pode utilizar funções de gatilho não-HTTP a partir de uma rede virtual de uma de duas maneiras:

  • Execute a sua aplicação de função num plano Premium e ative o suporte ao gatilho da rede virtual.
  • Execute a sua aplicação de função num plano de Serviço de Aplicações ou ambiente de serviço de aplicações.

Plano premium com gatilhos de rede virtual

Quando executar um plano Premium, pode ligar funções de gatilho não-HTTP a serviços que funcionam dentro de uma rede virtual. Para isso, tem de ativar o suporte de gatilho de rede virtual para a sua aplicação de função. A definição de monitorização da escala de tempo de execução encontra-se no portal Azure nas definições de tempo de funcionamento da função de configuração > .

VNETToggle

Também pode ativar os gatilhos de rede virtuais utilizando o seguinte comando Azure CLI:

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

Dica

Ativar os gatilhos de rede virtuais pode ter um impacto no desempenho da sua aplicação, uma vez que as instâncias do seu plano de Serviço de Aplicações terão de monitorizar os seus gatilhos para determinar quando escalar. É provável que este impacto seja muito pequeno.

Os gatilhos de rede virtuais são suportados na versão 2.x e acima do tempo de execução de Funções. Os seguintes tipos de gatilho não-HTTP são suportados.

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 ativa o suporte ao gatilho de rede virtual, apenas os tipos de gatilho mostrados na escala de tabela anterior dinamicamente com a sua aplicação. Ainda podes usar gatilhos que não estão na mesa, mas não estão além da contagem de exemplos pré-aquecidas. Para obter a lista completa de gatilhos, consulte Triggers e encadernações.

Plano de Serviço de Aplicações e Ambiente de Serviço de Aplicações com gatilhos de rede virtual

Quando a sua aplicação de função é executado num plano de Serviço de Aplicações ou num Ambiente de Serviço de Aplicações, pode utilizar funções de gatilho não-HTTP. Para que as suas funções sejam ativadas corretamente, tem de estar ligado a uma rede virtual com acesso ao recurso definido na ligação do gatilho.

Por exemplo, assuma que quer configurar a Azure Cosmos DB para aceitar o tráfego apenas a partir de uma rede virtual. Neste caso, deve implementar a sua aplicação de função num plano de Serviço de Aplicações que proporciona integração de rede virtual com essa rede virtual. A integração permite que uma função seja desencadeada por esse recurso DB da Azure Cosmos.

Ligações Híbridas

Hybrid Connections é uma característica do Azure Relay que pode usar para aceder a recursos de aplicações noutras redes. Fornece acesso da sua aplicação a um ponto final de aplicação. Não pode usá-lo para aceder à sua aplicação. As Ligações Híbridas estão disponíveis para funções que funcionam no Windows em todos, menos no plano de Consumo.

Como usado em Funções Azure, cada ligação híbrida está relacionada com um único hospedeiro TCP e combinação de porta. Isto significa que o ponto final da ligação híbrida pode estar em qualquer sistema operativo e qualquer aplicação, desde que aceda a uma porta de escuta TCP. A funcionalidade Ligações Híbridas não sabe nem se importa com o protocolo de aplicação ou o que está a aceder. Só dá acesso à rede.

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

Importante

As Ligações Híbridas só são suportadas nos planos do Windows. Linux não é apoiado.

Restrições ip de saída

As restrições IP de saída estão disponíveis num plano Premium, plano de Serviço de Aplicações ou Ambiente de Serviço de Aplicações. Pode configurar restrições de saída para a rede virtual onde o seu Ambiente de Serviço de Aplicações está implantado.

Quando integra uma aplicação de função num plano Premium ou num plano de Serviço de Aplicações com uma rede virtual, a aplicação ainda pode fazer chamadas de saída para a internet por padrão. Ao adicionar a definição de aplicação, força todo o WEBSITE_VNET_ROUTE_ALL=1 tráfego de saída a ser enviado para a sua rede virtual, onde as regras do grupo de segurança de rede podem ser usadas para restringir o tráfego.

Para aprender a controlar o IP de saída utilizando uma rede virtual, consulte Tutorial: Control Azure Functions outbound IP com um gateway NAT de rede virtual Azure.

Automatização

As seguintes APIs permitem gerir programáticamente integrações de redes virtuais regionais:

Resolução de problemas

A funcionalidade é fácil de configurar, mas isso não significa que a sua experiência seja livre de problemas. Se encontrar problemas no acesso ao seu ponto final pretendido, existem alguns utilitários que pode utilizar para testar a conectividade a partir da consola da aplicação. Há duas consolas que podes usar. Uma é a consola Kudu, e a outra é a consola no portal Azure. Para chegar à consola Kudu a partir da sua aplicação, vá ao Tools > Kudu. Também pode alcançar a consola Kudo em [sitename].scm.azurewebsites.net. Depois de carregar o site, vá ao separador de consola Debug. Para chegar à consola azure a partir da sua aplicação, vá ao Consola de Ferramentas. >

Ferramentas

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

nameresolver.exe hostname [optional: DNS Server]

Pode utilizar o nomeresolver para verificar os nomes de anfitrião de que a sua aplicação depende. Desta forma pode testar se tem alguma coisa mal configurada com o seu DNS ou talvez não tenha acesso ao seu servidor DNS. Pode ver o servidor DNS que a sua aplicação utiliza na consola, olhando para as variáveis ambientais WEBSITE_DNS_SERVER e WEBSITE_DNS_ALT_SERVER.

Nota

nameresolver.exe atualmente não funciona em recipientes windows personalizados.

Pode utilizar a próxima ferramenta para testar a conectividade TCP a uma combinação de hospedeiro e porta. Esta ferramenta chama-se tcpping e a sintaxe é:

tcpping.exe hostname [optional: port]

O utilitário de tcpping diz-lhe se pode chegar a um hospedeiro e porta específicos. Só pode mostrar sucesso se houver uma aplicação a ouvir na combinação de anfitriões e portas, e há acesso à rede da sua app para o anfitrião especificado e porta.

Depurg acesso a recursos hospedados em rede virtual

Uma série de coisas pode impedir que a sua app chegue a um anfitrião e porto específicos. A maior parte do tempo é uma destas coisas:

  • Uma firewall está no caminho. Se tiver uma firewall no caminho, atinja o tempo limite da TCP. O tempo limite de TCP é de 21 segundos neste caso. Utilize a ferramenta de tcpping para testar a conectividade. Os intervalos de tempo TCP podem ser causados por muitas coisas além das firewalls, mas começam por aí.
  • O DNS não está acessível. O tempo limite de DNS é de 3 segundos por servidor DNS. Se tiver dois servidores DNS, o tempo limite é de 6 segundos. Use o nome de consolação para ver se o DNS está a funcionar. Não podes usar o nslookup, porque isso não usa o DNS com o qual a tua rede virtual está configurada. Se for inacessível, pode ter uma firewall ou NSG bloqueando o acesso ao DNS ou pode estar em baixo.

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

Integração Regional de VNet

  • O seu destino é um endereço não-RFC1918 e não tem WEBSITE_VNET_ROUTE_ALL definido para 1?
  • Existe uma saída de bloqueio da NSG da sua sub-rede de integração?
  • Se vai atravessar a Azure ExpressRoute ou uma VPN, o seu portal no local está configurado para encaminhar o tráfego de volta para Azure? Se conseguir chegar aos pontos finais da sua rede virtual, mas não no local, verifique as suas rotas.
  • Tem permissões suficientes para definir a delegação na sub-rede de integração? Durante a configuração regional de Integração VNet, a sua sub-rede de integração é delegada no Microsoft.Web/serverFarms. O UI de Integração VNet delega automaticamente a sub-rede para Microsoft.Web/serverFarms. Se a sua conta não tiver permissões de networking suficientes para definir a delegação, precisará de alguém que possa definir atributos na sua sub-rede de integração para delegar a sub-rede. Para delegar manualmente a sub-rede de integração, vá à sub-rede Azure Virtual Network UI e deslote a delegação para Microsoft.Web/serverFarms.

Integração VNet exigida pelo Gateway

  • É o intervalo de endereços ponto-a-local nas gamas RFC 1918 (10.0.0-10.255.255.255 /172.16.00.0-172.31.255.255 / 192.168.0.0-192.168.255.255)?
  • O portal mostra-se como estando no portal? Se o seu portal está em baixo, então traga-o de volta.
  • Os certificados mostram estar sincronizados ou suspeita que a configuração da rede foi alterada? Se os seus certificados estiverem dessincronizados ou suspeitar que foi feita uma alteração na sua configuração de rede virtual que não foi sincronizada com os seus ASPs, selecione Sync Network.
  • Se vai atravessar uma VPN, o portal no local está configurado para encaminhar o tráfego de volta para Azure? Se conseguir chegar aos pontos finais da sua rede virtual, mas não no local, verifique as suas rotas.
  • Está a tentar usar uma porta de entrada de coexistência que suporta tanto o ponto para o site como o ExpressRoute? As portas de coexistência não são suportadas com a Integração VNet.

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

  • Tem uma firewall no seu anfitrião que impede o acesso à porta de aplicação a partir da sua gama IP ponto-a-local. Atravessar sub-redes requer frequentemente acesso público.
  • O teu anfitrião-alvo está em baixo.
  • A sua candidatura está em baixo.
  • Enganou-se no IP ou no nome de anfitrião.
  • A sua aplicação está a ouvir numa porta diferente do que esperava. Pode combinar o seu ID de processo com a porta de audição utilizando "netstat -aon" no anfitrião do ponto final.
  • Os seus grupos de segurança de rede estão configurados de forma a impedir o acesso ao seu anfitrião de aplicações e à porta a partir da sua gama IP ponto-a-local.

Não sabe que endereço a sua aplicação realmente usa. Pode ser qualquer endereço na sub-rede de integração ou no intervalo de endereços ponto a local, pelo que precisa de permitir o acesso a partir de toda a gama de endereços.

Os passos adicionais de depurg incluem:

  • Ligue-se a um VM na sua rede virtual e tente contactar o seu anfitrião de recursos:porta a partir daí. Para testar o acesso à TCP, utilize a rede de teste de comando PowerShell . A sintaxe é:
test-netconnection hostname [optional: -Port]
  • Apresentar uma aplicação num VM e testar o acesso a esse anfitrião e porta a partir da consola a partir da sua aplicação, utilizando tcpping.

Recursos no local

Se a sua aplicação não conseguir chegar a um recurso no local, verifique se consegue contactar o recurso a partir da sua rede virtual. Utilize o comando PowerShell de rede de teste para verificar se há acesso à TCP. Se o seu VM não conseguir chegar ao seu recurso no local, a sua ligação VPN ou ExpressRoute pode não estar configurada corretamente.

Se o seu VM virtual hospedado em rede pode chegar ao seu sistema no local, mas a sua aplicação não pode, a causa é provavelmente uma das seguintes razões:

  • As suas rotas não estão configuradas com os intervalos de endereços da sua sub-rede ou ponto a local no seu gateway no local.
  • Os seus grupos de segurança de rede estão a bloquear o acesso para o seu intervalo ip ponto-a-local.
  • As suas firewalls no local estão a bloquear o tráfego da sua gama IP ponto-a-local.
  • Está a tentar chegar a um endereço não RFC 1918 utilizando a funcionalidade regional de Integração VNet.

Passos seguintes

Para saber mais sobre networking e Funções Azure: