Opzioni di rete di Funzioni di Azure

Questo articolo descrive le funzionalità di rete disponibili nelle opzioni di hosting per Funzioni di Azure. Tutte le opzioni di rete seguenti consentono di accedere in vari modi alle risorse senza usare indirizzi instradabili tramite Internet o di limitare l'accesso a Internet a un'app per le funzioni.

Nei modelli di hosting sono disponibili diversi livelli di isolamento della rete. La scelta dell'opzione corretta consente di soddisfare i requisiti di isolamento della rete.

È possibile ospitare le app per le funzioni in due modi:

  • È possibile scegliere tra le opzioni di piano eseguite in un'infrastruttura multi-tenant, con diversi livelli di opzioni di connettività e scalabilità della rete virtuale:
    • Il Piano a consumo si ridimensiona dinamicamente in risposta al carico e offre opzioni minime di isolamento rete.
    • Anche il piano Premium si ridimensiona dinamicamente e offre un isolamento rete più completo.
    • Il piano di servizio app di Azure opera su una scala fissa e offre isolamento di rete simile al piano Premium.
  • È possibile eseguire funzioni in un ambiente del servizio app. Questo metodo distribuisce la funzione nella rete virtuale e offre controllo di rete e isolamento completi.

Matrice delle funzionalità di rete

Funzionalità Piano a consumo Piano Premium Piano dedicato ASE Kubernetes
Restrizioni IP in ingresso ✅Sì ✅Sì ✅Sì ✅Sì ✅Sì
Endpoint privati in ingresso ❌No ✅Sì ✅Sì ✅Sì ✅Sì
Integrazione della rete virtuale ❌No ✅Sì (Regionale) ✅Sì (Regional e Gateway) ✅Sì ✅Sì
Trigger della rete virtuale (non HTTP) ❌No ✅Sì ✅Sì ✅Sì ✅Sì
Connessioni ibride (solo Windows) ❌No ✅Sì ✅Sì ✅Sì ✅Sì
Restrizioni IP in uscita ❌No ✅Sì ✅Sì ✅Sì ✅Sì

Risorse di avvio rapido

Usare le risorse seguenti per iniziare rapidamente a usare scenari di rete Funzioni di Azure. Queste risorse vengono a cui si fa riferimento in tutto l'articolo.

Funzionalità di rete in ingresso

Le funzionalità seguenti consentono di filtrare le richieste in ingresso all'app per le funzioni.

Restrizioni di accesso in ingresso

È possibile usare le restrizioni di accesso per definire un elenco ordinato di priorità di indirizzi IP consentiti o negati all'app. L'elenco può includere indirizzi IPv4 e IPv6 o subnet di rete virtuale specifiche usando endpoint di servizio. In presenza di una o più voci, alla fine dell'elenco è presente un'istruzione di tipo "rifiuta tutto" implicita. Le restrizioni IP funzionano con tutte le opzioni di hosting di funzioni.

Le restrizioni di accesso sono disponibili in Premium, Consumo e servizio app.

Nota

Con restrizioni di rete, è possibile distribuire solo dall'interno della rete virtuale o quando si è inserito l'indirizzo IP del computer in uso per accedere all'portale di Azure nell'elenco Destinatari sicuri. Tuttavia, è comunque possibile gestire la funzione usando il portale.

Per altre informazioni, vedere Restrizioni di accesso al servizio app di Azure.

Endpoint privati

L'endpoint privato di Azure è un'interfaccia di rete che si connette in modo privato e sicuro a un servizio basato sul collegamento privato di Azure. L'endpoint privato usa un indirizzo IP privato della rete virtuale, portando il servizio nella rete virtuale in modo efficace.

È possibile usare Endpoint privato per le funzioni ospitate nei piani Premium e servizio app.

Se si desidera effettuare chiamate agli endpoint privati, è necessario assicurarsi che le ricerche DNS vengano risolte nell'endpoint privato. È possibile applicare questo comportamento in uno dei modi seguenti:

  • Eseguire l'integrazione con zone private di DNS di Azure. Quando la rete virtuale non ha un server DNS personalizzato, questa operazione viene eseguita automaticamente.
  • Gestire l'endpoint privato nel server DNS usato dall'app. A tale scopo, è necessario conoscere l'indirizzo dell'endpoint privato e quindi puntare l'endpoint che si sta tentando di raggiungere a tale indirizzo usando un record A.
  • Configurare il proprio server DNS da inoltrare alle zone private DNS di Azure.

Per altre informazioni, vedere Uso di endpoint privati per App Web.

Per chiamare altri servizi che dispongono di una connessione endpoint privata, ad esempio l'archiviazione o il bus di servizio, assicurarsi di configurare l'app per effettuare chiamate in uscita agli endpoint privati. Per altre informazioni sull'uso di endpoint privati con l'account di archiviazione per l'app per le funzioni, visitare limitare l'account di archiviazione a una rete virtuale.

Endpoint di servizio

L'uso degli endpoint di servizio consente di limitare un numero di servizi di Azure a subnet di rete virtuale selezionate per offrire un livello di sicurezza superiore. L'integrazione della rete virtuale a livello di area consente all'app per le funzioni di raggiungere i servizi di Azure protetti con gli endpoint di servizio. Questa configurazione è supportata in tutti i piani che supportano l'integrazione della rete virtuale. Per accedere a un servizio protetto dall'endpoint di servizio, è necessario eseguire le operazioni seguenti:

  1. Configurare l'integrazione della rete virtuale a livello di area con l'app per le funzioni per connettersi a una subnet specifica.
  2. Passare al servizio di destinazione e configurare gli endpoint di servizio nella subnet di integrazione.

Per altre informazioni, vedere Endpoint servizio di rete virtuale.

Usare gli endpoint di servizio

Per limitare l'accesso a una subnet specifica, creare una regola di restrizione con un tipo di Rete virtuale. È quindi possibile selezionare la sottoscrizione, la rete virtuale e la subnet a cui si vuole consentire o negare l'accesso.

Se gli endpoint di servizio non sono già abilitati con Microsoft.Web per la subnet selezionata, verranno abilitati automaticamente, a meno che non si selezioni la casella di controllo Ignora endpoint servizio Microsoft.Web mancanti . Lo scenario in cui è possibile abilitare gli endpoint di servizio nell'app, ma non la subnet dipende principalmente dal fatto che si disponga delle autorizzazioni per abilitarle nella subnet.

Se è necessario che un altro utente abiliti gli endpoint di servizio nella subnet, selezionare la casella di controllo Ignora endpoint servizio Microsoft.Web mancanti . L'app verrà configurata per gli endpoint di servizio in previsione della loro abilitazione in un secondo momento nella subnet.

Screenshot del riquadro

Non è possibile usare gli endpoint di servizio per limitare l'accesso alle app eseguite in un ambiente del servizio app. Quando l'app si trova in un ambiente del servizio app, è possibile controllare l'accesso applicando le regole di accesso IP.

Per informazioni su come configurare gli endpoint di servizio, vedere Stabilire Funzioni di Azure accesso al sito privato.

Integrazione della rete virtuale

L'integrazione della rete virtuale consente all'app per le funzioni di accedere alle risorse all'interno di una rete virtuale. Funzioni di Azure supporta due tipi di integrazione della rete virtuale:

  • I piani tariffari di calcolo dedicati, che includono Basic, Standard, Premium, Premium v2 e Premium v3.
  • Il ambiente del servizio app, che viene distribuito direttamente nella rete virtuale con un'infrastruttura di supporto dedicata e usa i piani tariffari Isolated e Isolated v2.

La funzionalità di integrazione della rete virtuale viene usata in Servizio app di Azure piani tariffari di calcolo dedicati. Se l'app si trova in un ambiente del servizio app, si trova già in una rete virtuale e non richiede l'uso della funzionalità di integrazione della rete virtuale per raggiungere le risorse nella stessa rete virtuale. Per altre informazioni su tutte le funzionalità di rete, vedere servizio app funzionalità di rete.

L'integrazione della rete virtuale consente all'app di accedere alle risorse nella rete virtuale, ma non concede l'accesso privato in ingresso all'app dalla rete virtuale. Per accesso privato si intende rendere l'app accessibile solo da una rete privata, ad esempio da una rete virtuale di Azure. L'integrazione della rete virtuale viene usata solo per effettuare chiamate in uscita dall'app nella rete virtuale. La funzionalità di integrazione della rete virtuale si comporta in modo diverso quando viene usata con le reti virtuali nella stessa area e con le reti virtuali in altre aree. La funzionalità di integrazione della rete virtuale presenta due varianti:

  • Integrazione della rete virtuale a livello di area: quando ci si connette alle reti virtuali nella stessa area, è necessario avere una subnet dedicata nella rete virtuale con cui si esegue l'integrazione.
  • Integrazione della rete virtuale richiesta dal gateway: quando ci si connette direttamente alle reti virtuali in altre aree o a una rete virtuale classica nella stessa area, è necessario un gateway di Azure Rete virtuale creato nella rete virtuale di destinazione.

Funzionalità di integrazione della rete virtuale:

  • Richiede un piano tariffario Basic o Standard, Premium, Premium v2, Premium v3 o Elastic Premium servizio app.
  • Supporta TCP e UDP.
  • Funziona con servizio app app e app per le funzioni.

Esistono alcuni aspetti che l'integrazione della rete virtuale non supporta, ad esempio:

  • Montaggio di un'unità.
  • Windows Server Active Directory aggiunta al dominio.
  • NetBIOS.

L'integrazione della rete virtuale richiesta dal gateway consente l'accesso alle risorse solo nella rete virtuale di destinazione o nelle reti connesse alla rete virtuale di destinazione con peering o VPN. L'integrazione della rete virtuale richiesta dal gateway non consente l'accesso alle risorse disponibili tra le connessioni Di Azure ExpressRoute o l'uso con gli endpoint di servizio.

Indipendentemente dalla versione usata, l'integrazione della rete virtuale consente all'app di accedere alle risorse nella rete virtuale, ma non concede l'accesso privato in ingresso all'app dalla rete virtuale. L'accesso al sito privato fa riferimento a rendere l'app accessibile solo da una rete privata, ad esempio dall'interno di una rete virtuale di Azure. L'integrazione della rete virtuale è solo per effettuare chiamate in uscita dall'app nella rete virtuale.

L'integrazione della rete virtuale in Funzioni di Azure usa l'infrastruttura condivisa con le app Web del servizio app. Per altre informazioni sui due tipi di integrazione della rete virtuale, vedere:

Per informazioni su come configurare l'integrazione della rete virtuale, vedere Abilitare l'integrazione della rete virtuale.

Abilitare l'integrazione della rete virtuale

  1. Passare al pannello Rete nel portale dell'app per le funzioni. In Integrazione rete virtuale selezionare Fare clic per configurare.

  2. Selezionare Add VNet (Aggiungi rete virtuale).

    Selezionare Integrazione rete virtuale

  3. L'elenco a discesa contiene tutte le reti virtuali di Azure Resource Manager della sottoscrizione nella stessa area. Selezionare la rete virtuale con cui si vuole eseguire l'integrazione.

    Selezionare la rete virtuale

    • Il piano Premium di Funzioni supporta solo l'integrazione della rete virtuale a livello di area. Se la rete virtuale si trova nella stessa area, creare una nuova subnet o selezionare una subnet vuota e preesistente.
    • Per selezionare una rete virtuale in un'altra area, è necessario disporre di un gateway di rete virtuale di cui è stato effettuato il provisioning con il punto a sito abilitato. L'integrazione della rete virtuale tra aree è supportata solo per i piani dedicati, ma i peering globali funzioneranno con l'integrazione della rete virtuale a livello di area.

Durante l'integrazione, l'app viene riavviata. Al termine dell'integrazione, verranno visualizzati i dettagli sulla rete virtuale con cui si è integrati. Per impostazione predefinita, Route All verrà abilitato e tutto il traffico verrà instradato nella rete virtuale.

Se si vuole instradare solo il traffico privato (traffico RFC1918 ), seguire la procedura descritta nella documentazione del servizio app.

Integrazione della rete virtuale regionale

L'uso dell'integrazione della rete virtuale a livello di area consente all'app di accedere a:

  • Risorse nella stessa rete virtuale dell'app.
  • Le risorse nelle reti virtuali con peering alla rete virtuale con cui l'app è integrata.
  • Servizi protetti con endpoint di servizio.
  • Risorse nelle connessioni Azure ExpressRoute.
  • Risorse nelle connessioni con peering, tra cui le connessioni Azure ExpressRoute.
  • Endpoint privati

Quando si usa l'integrazione della rete virtuale a livello di area, è possibile usare le funzionalità di rete di Azure seguenti:

  • Gruppi di sicurezza di rete : è possibile bloccare il traffico in uscita con un gruppo di sicurezza di rete posizionato nella subnet di integrazione. Le regole in ingresso non si applicano perché non è possibile usare l'integrazione della rete virtuale per fornire l'accesso in ingresso all'app.
  • Tabelle di route (route definite dall'utente): è possibile inserire una tabella di route nella subnet di integrazione per inviare il traffico in uscita in cui si vuole.

Nota

Quando si instrada tutto il traffico in uscita alla rete virtuale, è soggetto ai gruppi di sicurezza di rete e alle route definite dall'utente applicate alla subnet di integrazione. Quando la rete virtuale è integrata, il traffico in uscita dell'app per le funzioni verso gli indirizzi IP pubblici viene comunque inviato dagli indirizzi elencati nelle proprietà dell'app, a meno che non si forniscano route che indirizzano il traffico altrove.

L'integrazione della rete virtuale a livello di area non è in grado di usare la porta 25.

Esistono alcune limitazioni relative all'uso della rete virtuale:

  • La funzionalità è disponibile da tutte le distribuzioni di servizio app in Premium V2 e Premium V3. È disponibile anche in Standard, ma solo dalle distribuzioni di servizio app più recenti. Se si usa una distribuzione precedente, è possibile usare la funzionalità solo da un piano di servizio app Premium V2. Per assicurarsi di poter usare la funzionalità in un piano di servizio app Standard, creare l'app in un piano di servizio app Premium V3. Questi piani sono supportati solo nelle distribuzioni più recenti. È possibile ridurre le prestazioni se si desidera dopo.
  • La subnet di integrazione può essere usata da un solo piano servizio app.
  • La funzionalità non può essere usata dalle app del piano isolato presenti in un ambiente del servizio app.
  • La funzionalità richiede una subnet inutilizzata che sia /28 o superiore in una rete virtuale di Azure Resource Manager.
  • L'app e la rete virtuale devono trovarsi nella stessa area.
  • Non è possibile eliminare una rete virtuale con un'app integrata. Rimuovere l'integrazione prima di eliminare la rete virtuale.
  • È possibile avere una sola integrazione di rete virtuale a livello di area per ogni piano di servizio app. Più app nello stesso piano di servizio app possono usare la stessa subnet di integrazione.
  • Non è possibile modificare la sottoscrizione di un'app o un piano mentre è presente un'app che usa l'integrazione della rete virtuale a livello di area.

Subnet

L'integrazione della rete virtuale dipende da una subnet dedicata. Quando si effettua il provisioning di una subnet, la subnet di Azure perde cinque indirizzi IP dall'inizio. Un indirizzo viene usato dalla subnet di integrazione per ogni istanza del piano. Quando si ridimensiona l'app a quattro istanze, vengono usati quattro indirizzi.

Quando si aumentano o si abbassano le dimensioni, lo spazio degli indirizzi richiesto viene raddoppiato per un breve periodo di tempo. Ciò influisce sulle istanze supportate reali e disponibili per una determinata dimensione della subnet. La tabella seguente illustra sia gli indirizzi disponibili massimi per blocco CIDR che l'impatto su scala orizzontale:

Dimensioni del blocco CIDR Numero massimo di indirizzi disponibili Scala orizzontale massima (istanze)*
/28 11 5
/27 27 13
/26 59 29

*Si supponga che sia necessario aumentare o ridurre le dimensioni o lo SKU a un certo punto.

Poiché le dimensioni della subnet non possono essere modificate dopo l'assegnazione, usare una subnet sufficientemente grande per soddisfare qualsiasi scala che l'app possa raggiungere. Per evitare problemi con la capacità della subnet per i piani Premium di Funzioni, è consigliabile usare /24 con 256 indirizzi per Windows e /26 con 64 indirizzi per Linux. Quando si creano subnet in portale di Azure come parte dell'integrazione con la rete virtuale, per Windows e Linux è necessaria rispettivamente una dimensione minima di /24 e /26.

Quando si vuole che le app in un altro piano raggiungano una rete virtuale già connessa alle app in un altro piano, selezionare una subnet diversa da quella usata dall'integrazione della rete virtuale preesistente.

La funzionalità è completamente supportata per le app Windows e Linux, inclusi i contenitori personalizzati. Tutti i comportamenti funzionano allo stesso modo tra le app di Windows e le app Linux.

Gruppi di sicurezza di rete

È possibile usare i gruppi di sicurezza di rete per bloccare il traffico in ingresso e in uscita verso le risorse in una rete virtuale. Un'app che usa l'integrazione della rete virtuale a livello di area può usare un gruppo di sicurezza di rete per bloccare il traffico in uscita verso le risorse nella rete virtuale o in Internet. Per bloccare il traffico verso gli indirizzi pubblici, è necessario avere l'integrazione della rete virtuale con Route All abilitato. Le regole in ingresso in un gruppo di sicurezza di rete non si applicano all'app perché l'integrazione della rete virtuale influisce solo sul traffico in uscita dall'app.

Per controllare il traffico in ingresso verso l'app, usare la funzionalità Restrizioni di accesso. Un gruppo di sicurezza di rete applicato alla subnet di integrazione è attivo indipendentemente dalle route applicate alla subnet di integrazione. Se l'app per le funzioni è integrata con Route All abilitata e non sono presenti route che influiscono sul traffico degli indirizzi pubblici nella subnet di integrazione, tutto il traffico in uscita è comunque soggetto ai gruppi di sicurezza di rete assegnati alla subnet di integrazione. Quando Route All non è abilitato, i gruppi di sicurezza di rete vengono applicati solo al traffico RFC1918.

Route

È possibile usare le tabelle di route per instradare il traffico in uscita dall'app alla destinazione desiderata. Per impostazione predefinita, le tabelle di route influiscono solo sul traffico di destinazione RFC1918. Quando Route All è abilitato, tutte le chiamate in uscita sono interessate. Quando Route All è disabilitato, solo il traffico privato (RFC1918) è interessato dalle tabelle di route. Le route impostate nella subnet di integrazione non influiscono sulle risposte alle richieste di app in ingresso. Le destinazioni comuni possono includere dispositivi firewall o gateway.

Se si vuole instradare tutto il traffico in uscita in locale, è possibile usare una tabella di route per inviare tutto il traffico in uscita al gateway ExpressRoute. Se si instrada il traffico a un gateway, assicurarsi di impostare le route nella rete esterna per inviare le risposte.

Le route BGP (Border Gateway Protocol) influiscono anche sul traffico dell'app. Se sono presenti route BGP da elementi come un gateway ExpressRoute, ciò influisce sul traffico in uscita dell'app. Per impostazione predefinita, le route BGP influiscono solo sul traffico di destinazione RFC1918. Quando l'app per le funzioni è integrata con Route All abilitata, tutto il traffico in uscita può essere interessato dalle route BGP.

Zone private di DNS di Azure

Dopo l'integrazione dell'app con la rete virtuale, usa lo stesso server DNS con cui è configurata la rete virtuale e funzionerà con le zone private DNS di Azure collegate alla rete virtuale.

Limitare l'account di archiviazione a una rete virtuale

Nota

Per distribuire rapidamente un'app per le funzioni con endpoint privati abilitati nell'account di archiviazione, fare riferimento al modello seguente: App per le funzioni con endpoint privati di Archiviazione di Azure.

Quando si crea un'app per le funzioni, è necessario creare o collegare un account di archiviazione di Azure di uso generico che supporta l'archiviazione BLOB, Coda e Tabella. È possibile sostituire questo account di archiviazione con uno protetto con endpoint di servizio o endpoint privati.

Questa funzionalità è supportata per tutti gli SKU supportati dalla rete virtuale Windows e Linux nel piano Dedicato (servizio app) e per i piani Premium. Il piano a consumo non è supportato. Per informazioni su come configurare una funzione con un account di archiviazione limitato a una rete privata, vedere Limitare l'account di archiviazione a una rete virtuale.

Usare i riferimenti di Key Vault

È possibile usare i riferimenti di Azure Key Vault per usare segreti di Azure Key Vault nell'applicazione Funzioni di Azure senza modificare il codice. Azure Key Vault è un servizio che supporta la gestione centralizzata dei segreti, con controllo completo sui criteri di accesso e sulla cronologia di controllo.

Se l'integrazione della rete virtuale è configurata per l'app, è possibile usare Key Vault riferimenti per recuperare i segreti da un insieme di credenziali con restrizioni di rete.

Trigger della rete virtuale (non HTTP)

Attualmente è possibile usare funzioni trigger non HTTP da una rete virtuale in uno dei due modi seguenti:

  • Eseguire l'app per le funzioni in un piano Premium e abilitare il supporto dei trigger della rete virtuale.
  • Eseguire l'app per le funzioni in un piano di servizio app o in un ambiente del servizio app.

Piano Premium con trigger di rete virtuale

Quando si esegue un piano Premium, è possibile connettere funzioni trigger non HTTP a servizi in esecuzione all'interno di una rete virtuale. A tale scopo è necessario abilitare il supporto dei trigger della rete virtuale per l'app per le funzioni. L'impostazione Monitoraggio della scalabilità di runtime è disponibile nella portale di Azure inImpostazioni di runtime della funzionedi configurazione>.

VNETToggle

È anche possibile abilitare i trigger della rete virtuale usando il seguente comando dell'interfaccia della riga di comando di Azure:

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

Suggerimento

L'abilitazione dei trigger di rete virtuale può avere un impatto sulle prestazioni dell'applicazione perché le istanze del piano di servizio app dovranno monitorare i trigger per determinare quando ridimensionare. Questo impatto è probabilmente molto ridotto.

I trigger della rete virtuale sono supportati nella versione 2.x e versioni successive del runtime di Funzioni. Sono supportati i tipi di trigger non HTTP seguenti.

Estensione Versione minima
Microsoft.Azure.WebJobs.Extensions.Storage 3.0.10 o versioni successive
Microsoft.Azure.WebJobs.Extensions.EventHubs 4.1.0 o versioni successive
Microsoft.Azure.WebJobs.Extensions.ServiceBus 3.2.0 o versioni successive
Microsoft.Azure.WebJobs.Extensions.CosmosDB 3.0.5 o versioni successive
Microsoft.Azure.WebJobs.Extensions.DurableTask 2.0.0 o versioni successive

Importante

Quando si abilita il supporto dei trigger della rete virtuale, solo i tipi di trigger indicati nella tabella precedente vengono ridimensionati dinamicamente con l'applicazione. È comunque possibile usare trigger non presenti nella tabella, ma questi non vengono ridimensionati oltre il numero di istanze preriscaldate. Per l'elenco completo dei trigger, vedere Trigger e associazioni.

Piano di servizio app e ambiente del servizio app con trigger della rete virtuale

Quando l'app per le funzioni viene eseguita in un piano di servizio app o in un ambiente del servizio app, è possibile usare funzioni trigger non HTTP. Per garantire che le funzioni vengano attivate correttamente, è necessario essere connessi a una rete virtuale con accesso alla risorsa definita nella connessione trigger.

Si supponga ad esempio di voler configurare Azure Cosmos DB in modo che accetti traffico solo da una rete virtuale. In questo caso è necessario distribuire l'app per le funzioni in un piano di servizio app che offre l'integrazione della rete virtuale con quella rete virtuale specifica. L'integrazione consente a una funzione di essere attivata da quella risorsa Azure Cosmos DB.

connessioni ibride

Le connessioni ibride sono una funzionalità di Inoltro di Azure che consente di accedere alle risorse dell'applicazione in altre reti. Fornisce l'accesso dalla propria app a un endpoint applicazione. Non è possibile usarla per accedere all'applicazione. Le connessioni ibride sono disponibili per le funzioni che vengono eseguite in Windows in tutte le versioni meno il Piano a consumo.

Come in Funzioni di Azure, ogni connessione ibrida è correlata a una singola combinazione di host e porta TCP. Questo significa che l'endpoint della connessione ibrida può trovarsi in qualsiasi sistema operativo e in qualsiasi applicazione, a condizione che si acceda a una porta TCP in ascolto. La funzionalità Connessioni ibride non conosce né deve conoscere qual è il protocollo dell'applicazione o a quale risorsa sta accedendo l'utente. Offre solo l'accesso alla rete.

Per altre informazioni, vedere la Documentazione del servizio app per le connessioni ibride. La stessa procedura di configurazione supporta Funzioni di Azure.

Importante

Le connessioni ibride sono supportate solo nei piani di Windows. Linux non è supportato.

Restrizioni IP in uscita

Le restrizioni IP in uscita sono disponibili in un piano Premium, un piano di servizio app o un ambiente del servizio app. È possibile configurare le restrizioni in uscita per la rete virtuale in cui è distribuito l'ambiente del servizio app.

Quando si integra un'app per le funzioni in un piano Premium o in un piano di servizio app con una rete virtuale, per impostazione predefinita l'app può comunque effettuare chiamate in uscita a Internet. Integrando l'app per le funzioni con una rete virtuale con Route All abilitata, si forza l'invio di tutto il traffico in uscita nella rete virtuale, in cui è possibile usare le regole del gruppo di sicurezza di rete per limitare il traffico.

Per informazioni su come controllare l'IP in uscita usando una rete virtuale, vedere Esercitazione: Controllare Funzioni di Azure IP in uscita con un gateway NAT di rete virtuale di Azure.

Automazione

Le API seguenti consentono di gestire a livello di codice le integrazioni di reti virtuali a livello di codice:

  • Interfaccia della riga di comando di Azure: usare i az functionapp vnet-integration comandi per aggiungere, elencare o rimuovere un'integrazione di rete virtuale a livello di area.
  • Modelli arm: l'integrazione della rete virtuale a livello di area può essere abilitata usando un modello di azure Resource Manager. Per un esempio completo, vedere questo modello di avvio rapido di Funzioni.

Risoluzione dei problemi

La funzionalità è facile da configurare, ma ciò non significa che l'esperienza sarà gratuita. Se si verificano problemi di accesso all'endpoint desiderato, è possibile usare alcune utilità per testare la connettività dalla console dell'app. Le console disponibili sono due: Una è la console Kudu e l'altra è la console nel portale di Azure. Per raggiungere la console Kudu dall'app, passare a Strumenti>Kudu. È anche possibile raggiungere la console Kudo all'indirizzo [sitename].scm.azurewebsites.net. Dopo il caricamento del sito Web, passare alla scheda Console di debug. Per accedere alla console portale di Azure ospitata dall'app, passare a Console strumenti>.

Strumenti

Nelle app di Windows native, gli strumenti ping, nslookup e tracert non funzioneranno tramite la console a causa di vincoli di sicurezza (funzionano in contenitori Windows personalizzati). Per riempire il void, vengono aggiunti due strumenti separati. Per testare la funzionalità DNS, è stato aggiunto uno strumento denominato nameresolver.exe. La sintassi è:

nameresolver.exe hostname [optional: DNS Server]

Si può usare nameresolver per controllare i nomi host da cui dipende l'app. In questo modo è possibile verificare se si dispone di qualcosa di non configurato correttamente con il DNS o forse non si ha accesso al server DNS. È possibile visualizzare il server DNS usato dall'app nella console esaminando le variabili di ambiente WEBSITE_DNS_SERVER e WEBSITE_DNS_ALT_SERVER.

Nota

Lo strumento nameresolver.exe attualmente non funziona in contenitori Windows personalizzati.

È possibile usare lo strumento successivo per testare la connettività TCP a una combinazione di host e porta. Questo strumento viene chiamato tcpping la cui sintassi è:

tcpping.exe hostname [optional: port]

L'utilità tcpping indica se è possibile raggiungere un host e una porta specifici. Può mostrare l'esito positivo solo se è presente un'applicazione in ascolto nella combinazione di host e porta e l'accesso alla rete dall'app all'host e alla porta specificati.

Eseguire il debug dell'accesso alle risorse ospitate dalla rete virtuale

Un certo numero di elementi può impedire all'app di raggiungere un host e una porta specifici. Nella maggior parte dei casi si tratta di una di queste cose:

  • L'ostacolo è rappresentato da un firewall. Se si dispone di un firewall nel modo, si raggiunge il timeout TCP. che in questo caso è di 21 secondi. Usare lo strumento tcpping per testare la connettività. I timeout TCP possono essere causati da molti elementi oltre i firewall, ma iniziare da lì.
  • Il DNS non è accessibile. Il timeout DNS è di 3 secondi per ogni server DNS. Se si dispone di due server DNS, il timeout è di 6 secondi. Usare nameresolver per verificare il funzionamento del DNS. Non è possibile usare nslookup, perché non usa il DNS con cui è configurata la rete virtuale. Se non è accessibile, è possibile che un firewall o un gruppo di sicurezza di rete blocchi l'accesso a DNS o che sia inattivo.

Se questi elementi non rispondono ai problemi, cercare prima di tutto elementi come:

Integrazione della rete virtuale regionale

  • La destinazione è un indirizzo non RFC1918 e non è abilitato Route All ?
  • Esiste un gruppo di sicurezza di rete che blocca l'uscita dalla subnet di integrazione?
  • Se si passa attraverso Azure ExpressRoute o una VPN, il gateway locale è configurato per instradare il traffico di backup ad Azure? Se è possibile raggiungere gli endpoint nella rete virtuale ma non in locale, controllare le route.
  • Sono disponibili autorizzazioni sufficienti per impostare la delega nella subnet di integrazione? Durante la configurazione dell'integrazione della rete virtuale a livello di area, la subnet di integrazione viene delegata a Microsoft.Web/serverFarms. L'interfaccia utente di integrazione rete virtuale delega automaticamente la subnet a Microsoft.Web/serverFarms. Se l'account non dispone di autorizzazioni di rete sufficienti per impostare la delega, è necessario un utente che possa impostare gli attributi nella subnet di integrazione per delegare la subnet. Per delegare manualmente la subnet di integrazione, passare all'interfaccia utente della subnet Rete virtuale di Azure e impostare la delega per Microsoft.Web/serverFarms.

Integrazione della rete virtuale richiesta dal gateway

  • Intervallo di indirizzi da punto a sito negli intervalli RFC 1918 (10.0.0.0-10.255.255.255 / 172.16.16.0 0.0-172.31.255.255 / 192.168.0.0-192.168.255.255)?
  • Il gateway viene visualizzato come disponibile nel portale? Se il gateway è inattivo, è necessario riattivarlo.
  • I certificati vengono visualizzati come sincronizzati o si sospetta che la configurazione di rete sia stata modificata? Se i certificati non sono sincronizzati o si sospetta che sia stata apportata una modifica alla configurazione della rete virtuale che non è stata sincronizzata con gli ASP, selezionare Sincronizza rete.
  • Se si passa attraverso una VPN, il gateway locale è configurato per instradare il traffico di backup ad Azure? Se è possibile raggiungere gli endpoint nella rete virtuale ma non in locale, controllare le route.
  • Si sta provando a usare un gateway di coesistenza che supporta sia il punto a sito che ExpressRoute? I gateway di coesistenza non sono supportati con l'integrazione della rete virtuale.

Il debug dei problemi di rete è un problema perché non è possibile vedere cosa blocca l'accesso a una combinazione host:porta specifica. Alcune cause includono:

  • È presente un firewall nell'host che impedisce l'accesso alla porta dell'applicazione dall'intervallo IP da punto a sito. L'attraversamento delle subnet richiede spesso l'accesso pubblico.
  • L'host di destinazione è inattivo.
  • L'applicazione è inattiva.
  • Si è verificato un indirizzo IP o un nome host errato.
  • L'applicazione è in ascolto su una porta diversa da quella prevista. È possibile associare l'ID di processo alla porta di ascolto mediante "netstat -aon" nell'host dell'endpoint.
  • I gruppi di sicurezza di rete vengono configurati in modo da impedire l'accesso all'host dell'applicazione e alla porta dall'intervallo IP da punto a sito.

Non sai quale indirizzo viene effettivamente usato dall'app. Può trattarsi di qualsiasi indirizzo nella subnet di integrazione o nell'intervallo di indirizzi da punto a sito, quindi è necessario consentire l'accesso dall'intero intervallo di indirizzi.

Altri passaggi di debug includono:

  • Connettersi a una macchina virtuale nella rete virtuale e tentare di raggiungere l'host della risorsa:porta da questa posizione. Per testare l'accesso TCP, usare il comando Di PowerShell Test-NetConnection. La sintassi è:
Test-NetConnection hostname [optional: -Port]
  • Visualizzare un'applicazione in una macchina virtuale e testare l'accesso a tale host e porta dalla console dall'app usando tcpping.

Risorse locali

Se l'app non riesce a raggiungere una risorsa in locale, verificare se è possibile raggiungere la risorsa dalla rete virtuale. Usare il comando Di PowerShell Test-NetConnection per verificare l'accesso TCP. Se la macchina virtuale non riesce a raggiungere la risorsa locale, la connessione VPN o ExpressRoute potrebbe non essere configurata correttamente.

Se la macchina virtuale ospitata dalla rete virtuale può raggiungere il sistema locale, ma l'app non può, la causa è probabilmente uno dei motivi seguenti:

  • Le route non sono configurate con la subnet o gli intervalli di indirizzi da punto a sito nel gateway locale.
  • I gruppi di sicurezza di rete bloccano l'accesso per l'intervallo IP da punto a sito.
  • I firewall locali bloccano il traffico dall'intervallo IP da punto a sito.
  • Si sta tentando di raggiungere un indirizzo non RFC 1918 usando la funzionalità di integrazione della rete virtuale a livello di area.

Eliminazione del piano di servizio app o dell'app Web prima di disconnettere l'integrazione della rete virtuale

Se l'app Web è stata eliminata o il piano di servizio app senza disconnettere prima l'integrazione della rete virtuale, non sarà possibile eseguire alcuna operazione di aggiornamento/eliminazione nella rete virtuale o nella subnet usata per l'integrazione con la risorsa eliminata. Una delega di subnet 'Microsoft.Web/serverFarms' rimarrà assegnata alla subnet e impedirà le operazioni di aggiornamento/eliminazione.

Per eseguire nuovamente l'aggiornamento o l'eliminazione della subnet o della rete virtuale, è necessario ricreare l'integrazione della rete virtuale e quindi disconnetterla:

  1. Ricreare il piano di servizio app e l'app Web (è obbligatorio usare lo stesso nome dell'app Web come prima).
  2. Passare al pannello "Rete" nell'app Web e configurare l'integrazione della rete virtuale.
  3. Dopo aver configurato l'integrazione della rete virtuale, selezionare il pulsante "Disconnetti".
  4. Eliminare il piano servizio app o l'app Web.
  5. Aggiornare/eliminare la subnet o la rete virtuale.

Se si verificano ancora problemi con l'integrazione della rete virtuale dopo aver seguito i passaggi precedenti, contattare supporto tecnico Microsoft.

Passaggi successivi

Per altre informazioni sulla rete e su Funzioni di Azure: