Condividi tramite

Funzioni di Azure: le opzioni di rete

Questo articolo descrive le funzionalità di rete disponibili nelle opzioni di hosting per Funzioni di Azure. Le opzioni di rete seguenti possono essere classificate come funzionalità di rete in ingresso e in uscita. Le funzionalità in ingresso consentono di limitare l'accesso all'app, mentre quelle in uscita consentono di connettere l'app a risorse protette da una rete virtuale e di controllare il modo in cui viene instradato il traffico in uscita.

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.

Funzionalità Piano A consumo Flex Piano a consumo Piano Premium Piano dedicato/Ambiente del servizio app App contenitore1
Restrizioni di accesso in ingresso ✅ ✅ ✅ ✅ ✅ 2
Endpoint privati (in ingresso) ✅ ❌ ✅ ✅ ❌
Endpoint di servizio (in ingresso) ✅ ❌ ✅ ✅ ✅
Integrazione della rete virtuale (in uscita) ✅ ❌ ✅ ✅ 3 ✅
Connessioni ibride ❌ ❌ ✅ (solo Windows) ✅ (solo Windows) ✅ (solo Windows)
  1. Per altre informazioni, vedere Networking in App contenitore di Azure environment.
  2. Gestito tramite la configurazione di accesso dell'ambiente delle App container.
  3. Il piano Dedicated/ASE supporta anche l'integrazione richiesta dal gateway nella rete virtuale.

Risorse di avvio rapido

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

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 gli 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.

Note

Con restrizioni di rete, è possibile eseguire la distribuzione solo dall'interno della rete virtuale o quando si inserisce l'indirizzo IP del computer in uso per accedere al portale di Azure nell'elenco Safe Recipients. Tuttavia, è comunque possibile gestire la funzione usando il portale.

Per altre informazioni, vedere Servizio app di Azure restrizioni di accesso statico.

Durante l'esecuzione in App contenitore, l'accesso in ingresso viene gestito tramite la configurazione in ingresso dell'ambiente di App contenitore e non tramite le restrizioni di accesso al servizio app. Per ulteriori informazioni, vedere restrizioni IP in App contenitore di Azure.

Endpoint privati (in ingresso)

Azure Private Endpoint è un'interfaccia di rete che consente di connettersi privatamente e in modo sicuro a un servizio basato su collegamento privato di Azure. L'endpoint privato usa un indirizzo IP privato della rete virtuale, integrando il servizio nella rete virtuale in modo efficace.

È possibile usare l'endpoint privato per le funzioni ospitate nei piani Flex Consumption, Elastic Premium e Dedicated (App Service).

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

  • Integrare con le 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. Per gestire un endpoint privato, è necessario conoscere l'indirizzo dell'endpoint e usare un record A per fare riferimento all'endpoint che si sta tentando di raggiungere.
  • Configura il proprio server DNS per inoltrare alle zone DNS private di Azure.

Per ulteriori informazioni, vedere l'utilizzo degli endpoint privati per App Web.

Per chiamare altri servizi che dispongono di una connessione endpoint privato, ad esempio archiviazione o 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, vedere Limitare l'account di archiviazione a una rete virtuale.

Endpoint di servizio (in ingresso)

Usando gli endpoint di servizio, è possibile limitare molti servizi Azure alle subnet di rete virtuale selezionate per offrire un livello di sicurezza superiore. L'integrazione della rete virtuale regionale consente all'applicazione funzionale 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 endpoint di servizio protetto, seguire la procedura seguente:

  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 sulla subnet di integrazione.

Per altre informazioni, vedere Endpoint servizio di rete virtuale.

Usare endpoint di servizio

Per limitare l'accesso a una subnet specifica, creare una regola di restrizione con un tipo 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, vengono abilitati automaticamente, a meno che non si selezioni la casella di controllo Ignora gli endpoint del 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 del servizio nella subnet, selezionare la casella di controllo Ignora endpoint del servizio Microsoft.Web mancanti. L'app è configurata per gli endpoint di servizio, che è possibile abilitare 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 Establish Funzioni di Azure accesso al sito privato.

Integrazione della rete virtuale (in uscita)

Questa sezione descrive in dettaglio le funzionalità supportate da Funzioni per controllare i dati in uscita dall'app.

L'integrazione della rete virtuale consente all'app per le funzioni di accedere alle risorse nella rete virtuale. Dopo l'integrazione, l'app instrada il traffico in uscita attraverso la rete virtuale. Ciò consente all'app di accedere a endpoint privati o risorse con regole che consentono il traffico solo da subnet selezionate. Quando la destinazione è un indirizzo IP all'esterno della rete virtuale, l'INDIRIZZO IP di origine verrà comunque inviato da uno degli indirizzi elencati nelle proprietà dell'app, a meno che non sia stato configurato un gateway NAT.

Funzioni di Azure supporta l'integrazione della rete virtuale a livello di area, ovvero l'approccio consigliato. Per informazioni su come configurare l'integrazione della rete virtuale, vedere Abilitare l'integrazione della rete virtuale.

Funzioni di Azure supporta due tipi di integrazione della rete virtuale:

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

Integrazione di rete virtuale regionale (in uscita)

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

  • 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 tra connessioni Azure ExpressRoute.
  • Risorse nelle connessioni con peering, tra cui le connessioni Azure ExpressRoute.
  • Punti finali privati.

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

  • Gruppi di sicurezza di rete (NSG): è possibile bloccare il traffico in uscita inserendo un gruppo di sicurezza di rete 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 dove si desidera.

Note

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.

Considerazioni per il piano Flex Consumption:

  • L'app e la rete virtuale devono trovarsi nella stessa area.
  • Assicurarsi che il provider di risorse Microsoft.App Azure sia abilitato per la sottoscrizione, seguendo queste istruzioni. Questa operazione è necessaria per la delega della subnet. Il portale Azure e interfaccia della riga di comando di Azure applicano questa regola quando si crea un'app Flex Consumption, poiché l'integrazione con la rete virtuale può essere abilitata in qualsiasi momento dopo che l'app sia stata creata.
  • La delega della subnet richiesta durante l'esecuzione in un piano a consumo flessibile è Microsoft.App/environments. Ciò differisce dai piani Elastico Premium e Dedicato (servizio app), che richiedono requisiti di delega diversi.
  • È possibile pianificare l'uso massimo di 40 indirizzi IP per un'app per le funzioni, anche se l'app può utilizzarne più di 40. Ad esempio, se si dispone di 15 app con funzione Consumo flessibile integrate nella stessa subnet, è necessario pianificare un massimo di 15x40 = 600 indirizzi IP da utilizzare. Questo limite è soggetto a modifiche e non viene applicato.
  • La subnet non può essere già usata per altri scopi, ad esempio con endpoint privati o endpoint di servizio, oppure essere delegata a qualsiasi altro piano di hosting o servizio. Sebbene sia possibile condividere la stessa subnet con più app in modalità Consumo flessibile, le risorse di rete vengono condivise tra queste app per le funzioni, il che può comportare che un'app influisca sulle prestazioni delle altre app presenti nella stessa subnet.
  • Non è possibile condividere la stessa subnet tra un ambiente delle app container e un'applicazione Flex Consumption.
  • Attualmente il piano A consumo flessibile non supporta le subnet con nomi che contengono caratteri di sottolineatura (_).

Considerazioni sui piani Elastico Premium, Dedicato (servizio app)e App contenitore:

  • La funzionalità è disponibile per Elastico Premium e Servizio app Premium V2 e Premium V3. È disponibile anche in Standard, ma solo dalle distribuzioni più recenti del servizio app. Se si usa una distribuzione precedente, è possibile usare la funzionalità solo da un piano di servizio app Premium V2. Se si vuole 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. Se lo si desidera, è possibile ridurre le prestazioni.
  • Le app del piano isolato che si trovano in un ambiente del servizio app non possono usare la funzionalità .
  • L'app e la rete virtuale devono trovarsi nella stessa area.
  • La funzionalità richiede una subnet /28 o superiore in una rete virtuale Azure Resource Manager.
  • Più piani di servizio app possono usare la subnet di integrazione.
  • Per un piano Servizio app è possibile avere fino a due integrazioni di rete virtuale a livello di area. Più app nello stesso piano di servizio app possono usare la stessa subnet di integrazione.
  • La subnet scelta non può essere già usata per altri scopi, ad esempio con endpoint privati o endpoint di servizio o essere delegata a qualsiasi altro piano di hosting o servizio.
  • È possibile condividere la stessa subnet con più app in un piano di servizio app. Poiché le risorse di rete vengono condivise in tutte le app, un'app per le funzioni potrebbe influire sulle prestazioni di altri utenti nella stessa subnet.
  • Non è possibile eliminare una rete virtuale con un'app integrata. Rimuovere l'integrazione prima di eliminare la rete virtuale.
  • 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.

Abilitare l'integrazione della rete virtuale

  1. Nell'app per le funzioni nel portale Azure, in Settings selezionare Networking. Poi, in Rete virtuale Integration, selezionare Not configured per aggiungere.

  2. Selezionare Aggiungi integrazione della rete virtuale.

    Screenshot della pagina di integrazione della rete virtuale in cui è possibile abilitare l'integrazione della rete virtuale nell'app.

  3. L'elenco a discesa contiene tutte le reti virtuali di Azure Resource Manager della tua sottoscrizione nella stessa regione. Selezionare la rete virtuale che si desidera integrare.

    Selezionare la rete virtuale

    • I piani di hosting Consumo Flessibile e Elastico Premium supportano solo l'integrazione della rete virtuale locale. 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 al sito abilitato. L'integrazione della rete virtuale tra aree è supportata solo per i piani dedicati, ma i peering globali funzionano con l'integrazione della rete virtuale a livello di area.

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

Se si preferisce instradare solo il traffico privato (trafficoRFC1918), seguire la procedura descritta in questo articolo di Servizio app.

Subnet

L'integrazione della rete virtuale dipende da una subnet dedicata. Quando si effettua il provisioning di una subnet, Azure riserva i primi cinque indirizzi IP per l'uso interno. Il modo in cui vengono utilizzati gli indirizzi IP rimanenti dipende dal piano di hosting. Poiché le dimensioni della subnet non possono essere modificate dopo l'assegnazione, usare una subnet sufficientemente grande per supportare qualsiasi ridimensionare l'app.

La tabella seguente riepiloga i requisiti della subnet per ogni piano di hosting:

Piano di hosting Integrazione rete virtuale Dimensioni minime della subnet Dimensioni della subnet consigliate Delegazione subnet
Piano a Consumo Flessibile Supportato /27 /27 (singola app), /26 (più app) Microsoft.App/environments
Elastic Premium (Windows) Supportato /28 /24 Microsoft.Web/serverFarms
Elastic Premium (Linux) Supportato /28 /26 Microsoft.Web/serverFarms
Dedicato (servizio app) Supportato /28 /26 o maggiore Microsoft.Web/serverFarms
Container App Gestito dall'ambiente Consultare Networking delle Container Apps Consultare Networking delle Container Apps Microsoft.App/environments
Consumo Non supportato N/A N/A N/A

Assicurarsi di selezionare il piano di hosting nella parte superiore dell'articolo per i dettagli specifici del piano.

Quando viene eseguito in App contenitore di Azure, l'integrazione della rete virtuale viene gestita tramite l'ambiente App contenitore. Le dimensioni e la configurazione delle subnet sono determinate dall'ambiente delle applicazioni container, non direttamente dall'applicazione per funzioni. Per altre informazioni, vedere Networking in App contenitore di Azure environment.

Nei piani Elastico Premium e Dedicato (Servizio app), ogni istanza in esecuzione dell'app per le funzioni usa un indirizzo IP dalla subnet. Quando si aumenta o si diminuisce, lo spazio degli indirizzi richiesto può temporaneamente raddoppiare per ospitare la transizione. Se più app condividono la stessa subnet, l'utilizzo totale degli indirizzi IP è la somma di tutte le istanze in tali app, oltre al raddoppio temporaneo durante gli eventi di ridimensionamento.

Scenari di consumo IP

Scenario Consumo di indirizzi IP
Un'app, un'istanza Un indirizzo IP
Un'app, cinque istanze Cinque indirizzi IP
Un'app, con scalabilità da cinque a dieci istanze Fino a 20 indirizzi IP (temporanei, durante l'operazione di scalabilità)
Tre app, cinque istanze ciascuna 15 indirizzi IP

Raccomandazioni relative all'intervallo CIDR

Dimensioni del blocco CIDR Numero massimo di indirizzi disponibili Scala orizzontale massima (istanze)1
/28 11 5
/27 27 13
/26 59 29
/25 123 612
/24 251 1253
  1. Si presuppone che sia necessario aumentare o ridurre le dimensioni o lo SKU a un certo punto.
  2. Anche se il numero di indirizzi IP supporta 61 istanze, le singole app nel piano dedicato hanno un massimo di 30 istanze.
  3. Anche se il numero di indirizzi IP supporta 125 istanze, le singole app nel piano Elastic Premium hanno un massimo di 100 istanze.

Considerazioni aggiuntive

  • Per evitare problemi con la capacità della subnet per i piani Elastic Premium di Funzioni, è consigliabile usare /24 con 256 indirizzi per Windows e /26 con 64 indirizzi per Linux. Quando si creano subnet nel portale di Azure come parte dell'integrazione con la rete virtuale, è necessaria una dimensione minima di /24 e /26 rispettivamente per Windows e Linux.
  • Ogni piano di servizio app può supportare fino a due subnet che possono essere usate per l'integrazione della rete virtuale. È possibile aggiungere più app di un singolo piano di servizio app alla stessa subnet, ma le app di un piano diverso non possono usare la stessa subnet.

Nel piano Flex Consumption, il traffico di rete in uscita dalle istanze delle app per le funzioni viene instradato attraverso gateway condivisi dedicati alla subnet. Al massimo 27 gateway condivisi (27 indirizzi IP) vengono usati per subnet, indipendentemente dal numero di app integrate. Quando una subnet viene usata per troppe istanze o per le app che eseguono carichi di lavoro a elevato utilizzo di I/O, possono verificarsi problemi di capacità di rete, ad esempio una maggiore latenza e timeout. L'espansione orizzontale delle app non sarà influenzata.

Importante

L'integrazione delle app per le funzioni di Consumo Flessibile con una subnet di dimensioni inferiori a /27 o l'integrazione di più app con una subnet di dimensioni /27 riduce la capacità di rete in uscita disponibile per le app. Se si intende farlo, effettuare test di carico sulle app con carichi di lavoro su scala produttiva per evitare di riscontrare vincoli di capacità di rete.

Raccomandazioni relative all'intervallo CIDR

Dimensioni del blocco CIDR Indirizzi utilizzabili Numero massimo di istanze Raccomandazione
/27 27 1,000 Consigliato per un'app a funzione singola
/26 59 1,000+ Consigliato per più app o quando si ridimensionano oltre 1.000 istanze*

* Contattare il gruppo di prodotti per richiedere un aumento del numero massimo di istanze.

Gruppi di sicurezza di rete

È possibile usare i gruppi di sicurezza di rete per controllare il traffico tra le risorse nella rete virtuale. Ad esempio, è possibile creare una regola di sicurezza che impedisca al traffico in uscita dall'app di raggiungere una risorsa nella rete virtuale o di uscire dalla rete. Queste regole di sicurezza si applicano alle app che hanno configurato l'integrazione della rete virtuale. Per bloccare il traffico verso indirizzi pubblici, è necessario disporre dell'integrazione della rete virtuale e dell'opzione Instrada tutto abilitata. 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 all'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 in una rete virtuale con l'opzione Instrada tutto abilitata e non sono presenti percorsi che influiscono sul traffico di 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 verso qualsiasi posizione desiderata. Per impostazione predefinita, le tabelle di route influiscono solo sul traffico di destinazione RFC1918. Quando Instrada tutto è abilitata, tutte le chiamate in uscita sono interessate. Quando si disabilita Route All, le tabelle di route influiscono solo sul traffico privato (RFC1918). 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 di protezione.

Se si vuole instradare tutto il traffico in uscita 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 eventuali risposte.

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

Restrizioni IP in uscita

È possibile configurare restrizioni in uscita per la rete virtuale in cui viene distribuito il ambiente del servizio app.

Quando si integra un'app per le funzioni in un piano Elastico Premium o in un piano 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 Flex Consumption, tutto il traffico è già instradato attraverso la rete virtuale e Route All non è necessario.

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

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 DNS di Azure zone private collegate alla rete virtuale.

Automazione

Le API seguenti consentono di gestire a livello di codice le integrazioni di rete virtuale a livello di codice:

  • interfaccia della riga di comando di Azure: usare i comandi az functionapp vnet-integration 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.

connessioni ibride

Connessionihybrid è una funzionalità di Inoltro di Azure che è possibile usare per 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.

Come usato in Funzioni di Azure, ogni connessione ibrida è correlata a una singola combinazione di host TCP e porta. 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. Questi stessi passaggi di configurazione supportano Funzioni di Azure.

Importante

Le connessioni ibride sono supportate solo quando l'app per le funzioni viene eseguita in Windows. Le app Linux non sono supportate.

Connessione a servizi Azure tramite una rete virtuale

L'integrazione della rete virtuale consente all'app per le funzioni di accedere alle risorse in una rete virtuale. Questa sezione illustra gli aspetti da considerare quando si tenta di connettere l'app a determinati servizi.

Limitare l'account di archiviazione a una rete virtuale

Note

Per distribuire rapidamente un'app per le funzioni con endpoint privati abilitati sull'account di archiviazione, vedere il 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.

Per informazioni su come configurare l'app per le funzioni con un account di archiviazione protetto con una rete virtuale, vedere Limitare l'account di archiviazione a una rete virtuale.

È necessario assicurarsi che il routing della condivisione dei contenuti privati sia configurato. Per informazioni su come configurare l'app per le funzioni con un account di archiviazione protetto con una rete virtuale, vedere Limitare l'account di archiviazione a una rete virtuale.

Per informazioni su come configurare l'app per le funzioni con un account di archiviazione protetto con una rete virtuale, vedere Limitare l'account di archiviazione a una rete virtuale.

Usare i riferimenti di Key Vault

È possibile usare riferimenti Azure Key Vault per usare segreti di Azure Key Vault nell'applicazione Funzioni di Azure senza richiedere modifiche al codice. Azure Key Vault è un servizio che fornisce una 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 riferimenti a Key Vault per recuperare i segreti da un insieme di credenziali con restrizioni di rete.

Trigger della rete virtuale (non HTTP)

Il carico di lavoro potrebbe richiedere che l'app venga attivata da un'origine evento protetta da una rete virtuale.

Note

Quando vengono eseguiti in App contenitore di Azure, i trigger di rete virtuale vengono gestiti tramite la configurazione di rete dell'ambiente app contenitore. Per altre informazioni, vedere Networking in App contenitore di Azure environment.

Il piano Flex Consumption supporta in modo nativo gli attivatori di rete virtuale. L'app per le funzioni può essere attivata da origini eventi protette da una rete virtuale senza richiedere una configurazione aggiuntiva per il monitoraggio della scalabilità di runtime.

Il piano Elastic Premium consente di creare funzioni che attivano i servizi protetti da una rete virtuale. Questi trigger non HTTP sono noti come trigger di rete virtuale.

Il piano Elastic Premium consente di creare funzioni che attivano i servizi protetti da una rete virtuale.

Per impostazione predefinita, i trigger di rete virtuale non causano il ridimensionamento dell’app per le funzioni oltre il numero di istanze preavviso. Tuttavia, alcune estensioni supportano trigger di rete virtuale che causano la scalabilità dinamica dell'app per le funzioni. È possibile abilitare questo monitoraggio della scalabilità dinamica nell'app per le funzioni per le estensioni supportate in uno dei modi seguenti:

  1. Nel portale Azure passare all'app per le funzioni.

  2. In Impostazioni selezionare Configurazione, quindi nella scheda Impostazioni runtime funzione impostare Monitoraggio della scalabilità di runtime su Sì.

  3. Selezionare Salva per aggiornare la configurazione dell'app per le funzioni e riavviare l'app.

VNETToggle

Suggerimento

L'abilitazione del monitoraggio dei trigger di rete virtuale può influire sulle prestazioni dell'applicazione, anche se è probabile che l'impatto sia ridotto.

Il supporto per il monitoraggio a scalabilità dinamica dei trigger di rete virtuale non è disponibile nella versione 1.x del runtime di Funzioni.

Le estensioni in questa tabella supportano il monitoraggio della scalabilità dinamica dei trigger di rete virtuale. Per ottenere prestazioni di ridimensionamento ottimali, è consigliabile eseguire l'aggiornamento alle versioni che supportano anche il ridimensionamento basato sulla destinazione.

Estensione (versione minima) Solo monitoraggio della scalabilità di runtime Con Scalabilità basata su destinazione
Microsoft.Azure. WebJobs.Extensions.CosmosDB > 3.0.5 > 4.1.0
Microsoft.Azure. WebJobs.Extensions.DurableTask > 2.0.0 n/d
Microsoft.Azure. WebJobs.Extensions.EventHubs > 4.1.0 > 5.2.0
Microsoft.Azure. WebJobs.Extensions.ServiceBus > 3.2.0 > 5.9.0
Microsoft.Azure. WebJobs.Extensions.Storage > 3.0.10 > 5.1.0*

* Solo archiviazione code.

Importante

Quando si abilita il monitoraggio dei trigger di rete virtuale, solo i trigger per queste estensioni possono causare la scalabilità dinamica dell'app. È comunque possibile usare i trigger delle estensioni che non si trovano in questa tabella, ma non causeranno il ridimensionamento oltre il numero di istanze pre-riscaldamento. Per un elenco completo di tutte le estensioni di trigger e binding, vedere Trigger e associazioni.

Quando l'app per le funzioni viene eseguita in un piano di servizio app o in un ambiente del servizio app, è possibile scrivere funzioni attivate da risorse protette da una rete virtuale. Affinché le funzioni vengano attivate correttamente, l'app deve essere connessa a una rete virtuale con accesso alla risorsa definita nella connessione del trigger.

Si supponga, ad esempio, di voler configurare Azure Cosmos DB per accettare il 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 tale risorsa di Azure Cosmos DB di attivare una funzione.

Testare gli endpoint privati

Quando si testano le funzioni in un'app per le funzioni con endpoint privati, è necessario eseguire i test dall'interno della stessa rete virtuale, ad esempio in una macchina virtuale (VM) in tale rete. Per usare l'opzione Code + Test nel portale da tale macchina virtuale, è necessario aggiungere le origini CORS seguenti all'app per le funzioni:

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

Quando si limita l'accesso all'app per le funzioni con endpoint privati o qualsiasi altra restrizione di accesso, è necessario aggiungere anche il tag AzureCloud del servizio all'elenco consentito. Per aggiornare l'elenco elementi consentiti:

  1. Passare all'app per le funzioni e selezionare Impostazioni>rete. In Configurazione >Accesso alla rete pubblica selezionare Abilitato senza restrizioni di accesso.

  2. Assicurarsi che Accesso alla rete pubblica sia impostato su Abilitato da seleziona reti virtuali e indirizzi IP.

  3. Aggiungere una regola in Accesso al sito e regole:

    1. Selezionare Service Tag come Tipo di impostazioni di origine e AzureCloud come Tag del servizio.

    2. Assicurarsi che l'azione sia Consenti e impostare il nome e la priorità desiderati.

Risoluzione dei problemi

La funzionalità è facile da configurare, ma ciò non significa che l'esperienza sarà gratuita. In caso di problemi di accesso all'endpoint desiderato, sono disponibili varie utilità che permettono di 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 Debug. Per accedere alla console ospitata dal portale Azure dall'app, passare a Tools>Console.

Strumenti

Nelle app Windows native gli strumenti pingnslookup e tracert non funzioneranno tramite la console a causa di vincoli di sicurezza (funzionano in contenitori custom Windows). Per questo motivo sono stati aggiunti due strumenti separati. Per testare la funzionalità del DNS è stato aggiunto lo strumento 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 la configurazione del server DNS è corretta e se 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.

Note

Lo strumento nameresolver.exe attualmente non funziona nei contenitori di 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 una porta e un host specifici. Essa visualizza il completamento solo se è presente un'applicazione in ascolto presso la combinazione di host e porta ed è presente un accesso di rete dall'app all'host e alla porta specificati.

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

Una serie di elementi può impedire all'app di raggiungere un host e una porta specifici. La maggior parte dei casi è una di queste cose:

  • L'ostacolo è rappresentato da un firewall. Se è presente un firewall, si verifica il timeout TCP. Il timeout TCP in questo caso è di 21 secondi. Usare lo strumento tcpping per testare la connettività. Il timeout TCP può essere dovuto anche ad altri motivi, ma è consigliabile iniziare dal firewall.
  • Il DNS non è accessibile. Il timeout DNS è di tre 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 stai utilizzando Azure ExpressRoute o una VPN, il gateway locale è configurato per instradare il traffico di ritorno su 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 della rete virtuale delega la subnet a Microsoft. Web/serverFarms automaticamente. 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 attivo 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 non sincronizzata con i provider di servizi app, selezionare Sincronizza rete.
  • Se si passa attraverso una VPN, il gateway locale è configurato per instradare nuovamente il traffico ad Azure? Se è possibile raggiungere gli endpoint nella rete virtuale ma non in locale, controllare le route.
  • Si sta tentando di 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 sull'host che impedisce l'accesso alla porta dell'applicazione dall'intervallo IP da punto a sito. Il passaggio tra subnet spesso richiede l'accesso pubblico.
  • L'host di destinazione è inattivo.
  • L'applicazione è inattiva.
  • L'IP o il 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 sono configurati in modo da impedire l'accesso all'host e alla porta dell'applicazione dall'intervallo IP da punto a sito.

Non si sa 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 un'altra macchina virtuale nella rete virtuale e provare a raggiungere l'host:porta della risorsa da quel punto. Per verificare l'accesso al protocollo 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 locale, verificare se è possibile raggiungere la risorsa dalla propria rete virtuale. Usare il comando di PowerShell test-netconnection per eseguire controllare l'accesso al protocollo 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 nella rete virtuale può raggiungere il sistema locale ma l'app non ci riesce, la causa è probabilmente una delle 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 della rete bloccano l'accesso all'intervallo IP da punto a sito.
  • I firewall locali bloccano il traffico proveniente 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 è stata eliminata l'app Web 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. La delega della subnet 'Microsoft.Web/serverFarms' resterà assegnata alla subnet e impedirà le operazioni di aggiornamento/eliminazione.

Per eseguire di nuovo 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 esattamente lo stesso nome dell'app Web di 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 di 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.

Strumento di risoluzione dei problemi di rete

È anche possibile usare lo strumento di risoluzione dei problemi di rete per risolvere i problemi di connessione. Per aprire lo strumento di risoluzione dei problemi di rete, passare all'app nel portale di Azure. Selezionare Diagnostica e risolvere il problema e quindi cercare Risoluzione dei problemi di rete.

Problemi di connessione: controlla lo stato dell'integrazione della rete virtuale, incluso il controllo se l'indirizzo IP privato è stato assegnato a tutte le istanze del piano e delle impostazioni DNS. Se non è configurato un DNS personalizzato, viene applicato DNS di Azure predefinito. Lo strumento di risoluzione dei problemi verifica anche la presenza di dipendenze comuni dell'app per le funzioni, tra cui la connettività per Archiviazione di Azure e altre dipendenze di associazione.

Screenshot che mostra la risoluzione dei problemi di connessione in esecuzione.

Problemi di configurazione : questo strumento di risoluzione dei problemi verifica se la subnet è valida per l'integrazione della rete virtuale.

Screenshot che mostra l'esecuzione dello strumento di risoluzione dei problemi di configurazione.

Problema di eliminazione di subnet/rete virtuale: questo strumento di risoluzione dei problemi controlla se la subnet ha blocchi e se contiene collegamenti di associazione del servizio inutilizzati che potrebbero bloccare l'eliminazione della rete virtuale o della subnet.

Per altre informazioni sulla rete e sulle Funzioni di Azure:

  • Last updated on