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 scala fissa e offre un isolamento rete simile a quello del 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 e accesso al sito privato ✅Sì ✅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ì

Restrizioni di accesso in ingresso

È possibile usare le restrizioni di accesso per definire un elenco con priorità di indirizzi IP consentiti o negati per l'accesso 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.

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

Nota

Con le restrizioni di rete, è possibile eseguire la distribuzione solo dall'interno della rete virtuale o quando è stato inserito l'indirizzo IP del computer usato per accedere al portale di Azure nell'elenco dei destinatari sicuri. Tuttavia, è comunque possibile gestire la funzione tramite il portale.

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

Usare endpoint di servizio

Usando gli endpoint di servizio, è possibile limitare l'accesso alle subnet della rete virtuale di Azure selezionate. 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 concedere 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 dei servizi Microsoft. Web mancanti . Lo scenario in cui potrebbe essere necessario abilitare gli endpoint di servizio nell'app, ma non la subnet, dipende principalmente dal fatto che siano disponibili le autorizzazioni per abilitarle nella subnet.

Se è necessario un altro utente per abilitare gli endpoint di servizio nella subnet, selezionare la casella di controllo Ignora endpoint dei servizi Microsoft. Web mancanti . L'app verrà configurata per gli endpoint di servizio in previsione di essere abilitata in un secondo momento nella subnet.

Screenshot del riquadro "Aggiungi restrizione IP" con il tipo di rete virtuale selezionato.

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 una ambiente del servizio app, è possibile controllarne l'accesso applicando regole di accesso IP.

Per informazioni su come configurare gli endpoint di servizio, vedere stabilire l'accesso al sito privato di funzioni di Azure.

Connessioni a 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 l'endpoint privato per le funzioni ospitate nei piani Premium e di servizio app .

Quando si crea una connessione all'endpoint privato in ingresso per le funzioni, sarà necessario anche un record DNS per risolvere l'indirizzo privato. Per impostazione predefinita, viene creato un record DNS privato quando si crea un endpoint privato usando il portale di Azure.

Per altre informazioni, vedere uso di endpoint privati per le app Web.

Per chiamare altri servizi che dispongono di una connessione a un endpoint privato, ad esempio archiviazione o bus di servizio, assicurarsi di configurare l'app per effettuare chiamate in uscita agli endpoint privati.

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 sistemi multi-tenant che supportano l'intera gamma di piani tariffari eccetto isolated.
  • Il ambiente del servizio app, che distribuisce nella VNet e supporta le app di piano tariffario isolate.

La funzionalità di integrazione VNet viene usata nelle app multi-tenant. Se l'app è nell'ambiente del servizio App, è già in una rete virtuale e non richiede l'uso della funzionalità Integrazione rete virtuale per raggiungere risorse nella stessa rete virtuale. Per altre informazioni su tutte le funzionalità di rete, vedere funzionalità di rete del servizio app.

L'integrazione di VNet consente all'app di accedere alle risorse nel VNet, ma non concede l'accesso privato in ingresso all'app dal VNet. L'accesso al sito privato fa riferimento a rendere un'app accessibile solo da una rete privata, ad esempio all'interno di una rete virtuale di Azure. L'integrazione di VNet viene usata solo per eseguire chiamate in uscita dall'app in VNet. La funzionalità di integrazione VNet si comporta in modo diverso quando viene usata con VNet nella stessa area e con VNet in altre aree. La funzionalità di integrazione VNet presenta due varianti:

  • Integrazione VNet a livello di area: quando ci si connette a Azure Resource Manager reti virtuali nella stessa area, è necessario disporre di una subnet dedicata nel VNet con cui si esegue l'integrazione.
  • Gateway: integrazione VNet necessaria: quando ci si connette a VNet in altre aree o a una rete virtuale classica nella stessa area, è necessario un gateway di rete virtuale di Azure di cui è stato effettuato il provisioning nel VNet di destinazione.

Funzionalità di integrazione di VNet:

  • Richiedi un piano tariffario standard, Premium, PremiumV2, PremiumV3 o Elastic Premium.
  • Supportare TCP e UDP.
  • Usare app Azure app di servizio e le app per le funzioni.

Ci sono alcuni aspetti che l'integrazione VNet non supporta, ad esempio:

  • Montaggio di un'unità.
  • Active Directory l'integrazione.
  • NetBIOS.

Gateway: l'integrazione VNet necessaria consente di accedere alle risorse solo nel VNet di destinazione o nelle reti connesse al VNet di destinazione con peering o VPN. Gateway: l'integrazione VNet necessaria non consente l'accesso alle risorse disponibili tra le connessioni ExpressRoute di Azure o l'uso degli endpoint di servizio.

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

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 Integrare un'app per le funzioni con una rete virtuale di Azure.

Integrazione della rete virtuale regionale

L'uso dell'integrazione VNet a livello di area consente all'app di accedere a:

  • Risorse in un VNet nella stessa area dell'app.
  • Risorse in reti virtuali con peering al VNet con cui è integrata l'app.
  • Servizi protetti dell'endpoint di servizio.
  • Risorse tra le connessioni Azure ExpressRoute.
  • Risorse nella VNet con cui si è integrato.
  • Risorse tra connessioni con peering, incluse le connessioni di Azure ExpressRoute.
  • Endpoint privati

Quando si usa l'integrazione di VNet con reti virtuali nella stessa area, è possibile usare le funzionalità di rete di Azure seguenti:

  • Gruppi di sicurezza di rete (gruppi): è possibile bloccare il traffico in uscita con una NSG posizionata nella subnet di integrazione. Le regole in ingresso non si applicano perché non è possibile usare l'integrazione VNet per fornire l'accesso in ingresso all'app.
  • Tabelle di route (UDR): è possibile inserire una tabella di route nella subnet di integrazione per inviare il traffico in uscita laddove si vuole.

Per impostazione predefinita, l'app instrada solo il traffico RFC1918 in VNet. Se si vuole instradare tutto il traffico in uscita nella VNet, seguire questa procedura per aggiungere l' WEBSITE_VNET_ROUTE_ALL impostazione nell'app:

  1. Passare all'interfaccia utente di configurazione nel portale dell'app. Selezionare Nuova impostazione applicazione.

  2. Immettere WEBSITE_VNET_ROUTE_ALL nella casella nome e immettere 1 nella casella valore .

    Specificare l'impostazione dell'applicazione

  3. Selezionare OK.

  4. Selezionare Salva.

Nota

Quando si esegue il routing di tutto il traffico in uscita nel VNet, è soggetto a gruppi e UdR applicati alla subnet di integrazione. Quando WEBSITE_VNET_ROUTE_ALL è impostato su 1 , il traffico in uscita viene ancora inviato dagli indirizzi elencati nelle proprietà dell'app, a meno che non si forniscano route che indirizzano il traffico altrove.

L'integrazione VNet a livello di area non è in grado di utilizzare la porta 25.

Esistono alcune limitazioni all'uso dell'integrazione di VNet con reti virtuali nella stessa area:

  • Non è possibile raggiungere risorse tra connessioni di peering globali.
  • La funzionalità è disponibile in tutte le unità di scala del servizio app in Premium v2 e Premium V3. È anche disponibile in standard ma solo da unità di scala del servizio app più recenti. Se si usa un'unità di scala precedente, è possibile usare la funzionalità solo da un piano di servizio App Premium v2. Per assicurarsi che sia possibile usare la funzionalità in un piano di servizio app standard, creare l'app in un piano di servizio App Premium V3. Tali piani sono supportati solo nelle unità di scala più recenti. Se lo si desidera, è possibile ridurre le prestazioni.
  • La subnet di integrazione può essere usata da un solo piano di servizio app.
  • La funzionalità non può essere usata da app del piano isolato che si trovano in un ambiente del servizio app.
  • Per la funzionalità è necessaria una subnet inutilizzata/28 o superiore in un Azure Resource Manager VNet.
  • L'app e il VNet devono trovarsi nella stessa area.
  • Non è possibile eliminare un VNet con un'app integrata. Rimuovere l'integrazione prima di eliminare il VNet.
  • È possibile avere una sola integrazione VNet a livello di area per ogni piano di servizio app. Più app nello stesso piano di servizio app possono usare lo stesso VNet.
  • Non è possibile modificare la sottoscrizione di un'app o di un piano mentre è presente un'app che usa l'integrazione VNet a livello di area.
  • L'app non può risolvere gli indirizzi in Zone private di DNS di Azure senza modifiche di configurazione.

L'integrazione di VNet dipende da una subnet dedicata. Quando si esegue 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 diminuiscono le dimensioni, lo spazio degli indirizzi richiesto viene raddoppiato per un breve periodo di tempo. Ciò influiscono sulle istanze effettive supportate disponibili per una determinata dimensione della subnet. La tabella seguente mostra sia il numero massimo di indirizzi disponibili per ogni blocco CIDR che l'effetto sulla scalabilità orizzontale:

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

*Si presuppone che sia necessario aumentare o ridurre le dimensioni in un determinato punto.

Poiché le dimensioni della subnet non possono essere modificate dopo l'assegnazione, usare una subnet sufficientemente grande da contenere la scala che l'app può raggiungere. Per evitare problemi con la capacità della subnet, è necessario usare un/26 con indirizzi 64.

Quando si vuole che le app in un altro piano raggiungano un VNet già connesso da app in un altro piano, selezionare una subnet diversa da quella usata dall'integrazione VNet preesistente.

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

Endpoint di servizio

L'integrazione VNet a livello di area consente di raggiungere i servizi di Azure protetti con gli endpoint di servizio. Per accedere a un servizio protetto con endpoint di servizio, è necessario eseguire le operazioni seguenti:

  1. Configurare l'integrazione di VNet a livello di area con l'app Web per connettersi a una subnet specifica per l'integrazione.
  2. Passare al servizio di destinazione e configurare gli endpoint di servizio nella subnet di integrazione.

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 VNet. Un'app che usa l'integrazione VNet a livello di area può usare un gruppo di sicurezza di rete per bloccare il traffico in uscita verso le risorse in VNet o Internet. Per bloccare il traffico verso gli indirizzi pubblici, è necessario che l'impostazione dell'applicazione sia WEBSITE_VNET_ROUTE_ALL impostata su 1 . Le regole in ingresso in un NSG non si applicano all'app perché l'integrazione con VNet influiscono solo sul traffico in uscita dall'app.

Per controllare il traffico in ingresso verso l'app, usare la funzionalità restrizioni di accesso. Un NSG applicato alla subnet di integrazione è attivo indipendentemente dalle route applicate alla subnet di integrazione. Se WEBSITE_VNET_ROUTE_ALL è impostato su 1 e non sono presenti route che influiscono sul traffico degli indirizzi pubblici sulla subnet di integrazione, tutto il traffico in uscita è ancora soggetto a gruppi assegnati alla subnet di integrazione. Quando WEBSITE_VNET_ROUTE_ALL non è impostato, gruppi viene applicato solo al traffico RFC1918.

Route

È possibile usare le tabelle di route per instradare il traffico in uscita dall'app a qualsiasi posizione. Per impostazione predefinita, le tabelle di route influiscono solo sul traffico di destinazione RFC1918. Quando si imposta WEBSITE_VNET_ROUTE_ALL su 1 , tutte le chiamate in uscita sono interessate. Le route impostate nella subnet di integrazione non influiranno 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 esegue il routing del traffico a un gateway, assicurarsi di impostare le route nella rete esterna per restituire le risposte.

Le route Border Gateway Protocol (BGP) influiscono anche sul traffico dell'app. Se si hanno Route BGP da qualcosa come un gateway ExpressRoute, il traffico in uscita dell'app è interessato. Per impostazione predefinita, le route BGP hanno effetto solo sul traffico di destinazione RFC1918. Quando WEBSITE_VNET_ROUTE_ALL è impostato su 1 , tutto il traffico in uscita può essere influenzato dalle route BGP.

Zone private di DNS di Azure

Quando l'app si integra con la VNet, USA lo stesso server DNS con cui è configurata la VNet. Per impostazione predefinita, l'app non funziona con le zone private di DNS di Azure. Per lavorare con le zone private di DNS di Azure, è necessario aggiungere le impostazioni dell'app seguenti:

  1. WEBSITE_DNS_SERVER con valore 168.63.129.16
  2. WEBSITE_VNET_ROUTE_ALL con valore 1

Queste impostazioni inviano tutte le chiamate in uscita dall'app in VNet e consentono all'app di accedere a una zona privata di DNS di Azure. Con queste impostazioni, l'app può usare il servizio DNS di Azure eseguendo una query sulla zona privata DNS a livello di ruolo di lavoro.

Endpoint privati

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:

  • Eseguire l'integrazione con le zone private di DNS di Azure. Quando il VNet non dispone di un server DNS personalizzato, questa operazione viene eseguita automaticamente.
  • Gestire l'endpoint privato nel server DNS usato dall'app. A tale scopo, è necessario conoscerlo, quindi puntare l'endpoint che si sta provando a raggiungere l'indirizzo usando un record A.
  • Configurare il server DNS in modo che si inoltri alle zone private di DNS di Azure.

Connettersi a risorse protette dell'endpoint di servizio

Per garantire un livello di sicurezza più elevato, è possibile limitare vari servizi di Azure a una rete virtuale usando gli endpoint di servizio. Sarà quindi necessario integrare l'app per le funzioni con la rete virtuale per accedere alla risorsa. Questa configurazione è supportata in tutti i piani che supportano l'integrazione della rete virtuale.

Per altre informazioni, vedere Endpoint servizio di rete virtuale.

Limitare l'account di archiviazione a una rete virtuale

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

Questa funzionalità funziona attualmente per tutti gli SKU supportati da rete virtuale Windows nel piano dedicato (servizio app) e per il piano 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.

Attualmente i riferimenti di Key Vault non funzionano se l'insieme di credenziali delle chiavi è protetto con gli endpoint di servizio. Per connettersi a un insieme di credenziali delle chiavi tramite l'integrazione della rete virtuale, è necessario chiamare Key Vault nel codice dell'applicazione.

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 di monitoraggio della scalabilità di runtime si trova nel portale di Azure in > impostazioni runtime funzione di 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 della rete virtuale può avere un effetto sulle prestazioni dell'applicazione, perché le istanze del piano di servizio app dovranno monitorare i trigger per determinare la scalabilità. Questo effetto è 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. Se si aggiunge l'impostazione dell'applicazione WEBSITE_VNET_ROUTE_ALL=1 si forza l'invio di tutto il traffico in uscita alla rete virtuale, in cui è possibile usare regole del gruppo di sicurezza di rete per limitare il traffico.

Per informazioni su come controllare l'IP in uscita tramite una rete virtuale, vedere esercitazione: controllare l'IP in uscita di funzioni di Azure con un gateway NAT di rete virtuale di Azure.

Automazione

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

  • Interfaccia della riga di comando di Azure: usare i az functionapp vnet-integration comandi per aggiungere, elencare o rimuovere un'integrazione della 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 il modello di avvio rapido di funzioni.

Risoluzione dei problemi

La funzionalità è facile da configurare, ma ciò non significa che la tua esperienza sarà priva di problemi. Se si verificano problemi durante l'accesso all'endpoint desiderato, sono disponibili alcune utilità che è possibile usare per testare la connettività dalla console app. Le console disponibili sono due: Uno è la console Kudu e l'altro è la console nella portale di Azure. Per accedere alla console Kudu dall'app, passare a strumenti > Kudu. È anche possibile accedere alla console Kudo in [SiteName]. SCM. azurewebsites. NET. Al termine del caricamento del sito Web, passare alla scheda debug console . Per accedere alla console ospitata da portale di Azure dall'app, passare a strumenti > console.

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 distinti. 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 una configurazione non configurata correttamente con il DNS o se 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

nameresolver.exe attualmente non funziona nei contenitori di Windows personalizzati.

È possibile utilizzare lo strumento successivo per verificare 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 un'applicazione è in ascolto sulla combinazione di host e porta e se l'app e l'host specificati hanno accesso alla rete.

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. Nella maggior parte dei casi, si tratta di una delle operazioni seguenti:

  • L'ostacolo è rappresentato da un firewall. Se si dispone di un firewall nel modo in cui 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 qui.
  • 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 si disponga di un firewall o di un NSG che blocca l'accesso al DNS o che potrebbe essere inattivo.

Se tali elementi non rispondono ai problemi, cercare prima di tutto, ad esempio:

Integrazione rete virtuale a livello di area

  • La destinazione è un indirizzo non RFC1918 e non si ha WEBSITE_VNET_ROUTE_ALL impostato su 1?
  • Esiste una NSG che blocca l'uscita dalla subnet di integrazione?
  • Se si usa Azure ExpressRoute o una VPN, il gateway locale è configurato per instradare il traffico al backup in Azure? Se è possibile raggiungere gli endpoint nella rete virtuale ma non in locale, verificare le route.
  • Si dispone di autorizzazioni sufficienti per impostare la delega sulla subnet di integrazione? Durante la configurazione dell'integrazione VNet a livello di area, la subnet di integrazione viene delegata a Microsoft. Web/serverFarms. L'interfaccia utente di integrazione di VNet delega la subnet a Microsoft. Web/serverFarms automaticamente. Se l'account non dispone di autorizzazioni di rete sufficienti per impostare la delega, sarà necessario un utente che può impostare gli attributi nella subnet di integrazione per delegare la subnet. Per delegare manualmente la subnet di integrazione, passare all'interfaccia utente della subnet della rete virtuale di Azure e impostare la delega per Microsoft. Web/serverFarms.

Gateway: integrazione VNet necessaria

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

Il debug dei problemi di rete è una sfida perché non è possibile vedere ciò che blocca l'accesso a una combinazione host: porta specifica. Di seguito sono riportate alcune cause:

  • Nell'host è presente un firewall 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.
  • Il nome host o l'indirizzo IP non è corretto.
  • 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 e alla porta dell'applicazione dall'intervallo IP da punto a sito.

Non si conosce l'indirizzo effettivamente usato dall'app. Potrebbe trattarsi di qualsiasi indirizzo nell'intervallo di indirizzi da punto a sito o subnet di integrazione, quindi è necessario consentire l'accesso dall'intero intervallo di indirizzi.

Di seguito è riportata la procedura di debug aggiuntiva:

  • Connettersi a una macchina virtuale nella rete virtuale e provare a raggiungere l'host di risorse: porta da qui. 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 all'host e alla 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 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, è possibile che la connessione VPN o ExpressRoute non sia configurata correttamente.

Se la macchina virtuale ospitata nella 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 di indirizzi IP da punto a sito.
  • Si sta tentando di raggiungere un indirizzo non RFC 1918 usando la funzionalità di integrazione VNet a livello di area.

Passaggi successivi

Per altre informazioni sulla rete e su Funzioni di Azure: