Integrare un'app con una rete virtuale di Azure

Questo articolo descrive la funzionalità di integrazione della rete virtuale Servizio app di Azure e come configurarla con le app in servizio app. Con le reti virtuali di Azure, è possibile posizionare molte delle risorse di Azure in una rete non internet-instradabile. La funzionalità di integrazione della rete virtuale servizio app consente alle app di accedere alle risorse in o tramite una rete virtuale. L'integrazione della rete virtuale non consente l'accesso privato alle app.

servizio app ha due varianti:

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

La funzionalità di integrazione della rete virtuale viene usata nei piani tariffari di calcolo dedicati Servizio app di Azure. Se l'app si trova in un ambiente del servizio app, è 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 reti virtuali nella stessa area e con 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 disporre di 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 le app e le app per le funzioni servizio app.

Esistono alcuni elementi 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 nelle connessioni di Azure ExpressRoute o funziona con gli endpoint del 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.

Informazioni su come abilitare l'integrazione della rete virtuale.

Integrazione della rete virtuale regionale

L'integrazione della rete virtuale a livello di area supporta la connessione a una rete virtuale nella stessa area e non richiede un gateway. L'uso dell'integrazione della rete virtuale a livello di area consente all'app di accedere:

  • Le risorse nella rete virtuale con cui si è integrati.
  • Le risorse nelle reti virtuali con peering alla rete virtuale dell'app sono integrate con connessioni di peering globali.
  • Risorse nelle connessioni Azure ExpressRoute.
  • Servizi protetti dall'endpoint di servizio.
  • Servizi abilitati per l'endpoint privato.

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 inserito 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 (UDR): è possibile inserire una tabella di route nella subnet di integrazione per inviare il traffico in uscita in cui si desidera.

Funzionamento dell'integrazione della rete virtuale a livello di area

Le app nel servizio app sono ospitate in ruoli di lavoro. L'integrazione della rete virtuale a livello di area funziona montando interfacce virtuali nei ruoli di lavoro con indirizzi nella subnet delegata. Poiché l'indirizzo si trova nella rete virtuale, può accedere alla maggior parte degli elementi nella rete virtuale o tramite la rete virtuale come una macchina virtuale nella rete virtuale. L'implementazione della rete è diversa dall'esecuzione di una macchina virtuale nella rete virtuale. alcune funzionalità di rete non sono ancora disponibili per questa funzionalità.

Diagramma che mostra il funzionamento dell'integrazione della rete virtuale a livello di area.

Quando l'integrazione della rete virtuale a livello di area è abilitata, l'app effettua chiamate in uscita tramite la rete virtuale. Gli indirizzi in uscita elencati nel portale delle proprietà dell'app sono gli indirizzi ancora usati dall'app. Tuttavia, se la chiamata in uscita è a una macchina virtuale o a un endpoint privato nella rete virtuale di integrazione o nella rete virtuale con peering, l'indirizzo in uscita sarà un indirizzo dalla subnet di integrazione. L'IP privato assegnato a un'istanza viene esposto tramite la variabile di ambiente WEBSITE_PRIVATE_IP.

Quando tutto il routing del traffico è abilitato, tutto il traffico in uscita viene inviato nella rete virtuale. Se tutto il routing del traffico non è abilitato, solo il traffico privato (RFC1918) e gli endpoint di servizio configurati nella subnet di integrazione verranno inviati alla rete virtuale e il traffico in uscita verso Internet passerà attraverso gli stessi canali del normale.

La funzionalità supporta una sola interfaccia virtuale per ogni ruolo di lavoro. Un'interfaccia virtuale per ogni ruolo di lavoro significa un'integrazione di rete virtuale a livello di area per ogni piano di servizio app. Tutte le app nello stesso piano di servizio app possono usare solo la stessa integrazione di rete virtuale in una subnet specifica. Se è necessaria un'app per connettersi a un'altra rete virtuale o a un'altra subnet nella stessa rete virtuale, è necessario creare un altro piano di servizio app. L'interfaccia virtuale usata non è una risorsa a cui i clienti hanno accesso diretto.

A causa della natura del funzionamento di questa tecnologia, il traffico usato con l'integrazione della rete virtuale non viene visualizzato nei log di flusso di Azure Network Watcher o NSG.

Requisiti della subnet

L'integrazione della rete virtuale dipende da una subnet dedicata. Quando si crea 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. Se si ridimensiona l'app su quattro istanze, vengono usati quattro indirizzi.

Quando si aumenta o si aumentano le dimensioni, lo spazio degli indirizzi richiesto viene raddoppiato per un breve periodo di tempo. Questa modifica influisce sulle istanze reali e supportate per una determinata dimensione della subnet. La tabella seguente mostra sia gli indirizzi disponibili massimi per blocco CIDR che l'effetto che ha sulla scala orizzontale.

Dimensioni del blocco CIDR Indirizzi massimi disponibili Scalabilità 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 in un certo momento.

Poiché le dimensioni della subnet non possono essere modificate dopo l'assegnazione, usare una subnet sufficientemente grande per supportare qualsiasi scalabilità che l'app possa raggiungere. Per evitare problemi relativi alla capacità della subnet, usare un /26 oggetto con 64 indirizzi. Quando si creano subnet in portale di Azure come parte dell'integrazione con la rete virtuale, è necessaria una dimensione minima di /27.

Quando si desidera che le app nel 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.

Autorizzazioni

È necessario disporre almeno delle autorizzazioni di controllo degli accessi in base al ruolo seguenti nella subnet o a un livello superiore per configurare l'integrazione della rete virtuale a livello di area tramite portale di Azure, interfaccia della riga di comando o quando si imposta direttamente la proprietà del virtualNetworkSubnetId sito:

Azione Descrizione
Microsoft.Network/virtualNetworks/read Leggere la definizione di rete virtuale
Microsoft.Network/virtualNetworks/subnets/read Leggere una definizione della subnet di rete virtuale
Microsoft.Network/virtualNetworks/subnets/join/action Aggiunge una rete virtuale

Se la rete virtuale si trova in una sottoscrizione diversa rispetto all'app, è necessario assicurarsi che la sottoscrizione con la rete virtuale sia registrata per il Microsoft.Web provider di risorse. È possibile registrare in modo esplicito il provider seguendo questa documentazione, ma verrà registrato automaticamente durante la creazione della prima app Web in una sottoscrizione.

Route

È possibile controllare il traffico che passa attraverso l'integrazione della rete virtuale. Esistono tre tipi di routing da considerare quando si configura l'integrazione della rete virtuale a livello di area. Il routing dell'applicazione definisce il traffico instradato dall'app e nella rete virtuale. Il routing della configurazione influisce sulle operazioni che si verificano prima o durante l'avvio dell'app. Esempi sono il pull e le impostazioni dell'app dell'immagine del contenitore con Key Vault riferimento. Il routing di rete è la possibilità di gestire sia il traffico dell'app che del traffico di configurazione dalla rete virtuale e dall'esterno.

Tramite le opzioni di routing dell'applicazione o routing di configurazione, è possibile configurare il traffico inviato tramite l'integrazione della rete virtuale. Il traffico è soggetto solo al routing di rete se viene inviato tramite l'integrazione della rete virtuale.

Routing delle applicazioni

Il routing delle applicazioni si applica al traffico inviato dall'app dopo l'avvio. Vedere routing della configurazione per il traffico durante l'avvio. Quando si configura il routing dell'applicazione, è possibile instradare tutto il traffico o solo il traffico privato (noto anche come traffico RFC1918 ) nella rete virtuale. È possibile configurare questo comportamento tramite l'impostazione Route All . Se Route All è disabilitato, l'app instrada solo il traffico privato alla rete virtuale. Se si vuole instradare tutto il traffico dell'app in uscita nella rete virtuale, assicurarsi che Route All sia abilitato.

  • Solo il traffico configurato nell'applicazione o nel routing della configurazione è soggetto ai gruppi di sicurezza di rete e alle richieste utente applicate alla subnet di integrazione.
  • Quando Route All è abilitato, il traffico in uscita dall'app viene comunque inviato dagli indirizzi elencati nelle proprietà dell'app, a meno che non si forniscano route che indirizzano il traffico altrove.

Informazioni su come configurare il routing delle applicazioni.

È consigliabile usare l'impostazione Di configurazione Route All per abilitare il routing di tutto il traffico. L'uso dell'impostazione di configurazione consente di controllare il comportamento con un criterio predefinito. L'impostazione dell'app esistente WEBSITE_VNET_ROUTE_ALL può comunque essere usata e è possibile abilitare tutto il routing del traffico con entrambe le impostazioni.

Nota

La connettività SMTP in uscita (porta 25) è supportata per servizio app quando il traffico SMTP viene instradato tramite l'integrazione della rete virtuale. La supportabilità è determinata da un'impostazione nella sottoscrizione in cui viene distribuita la rete virtuale. Per reti virtuali/subnet create prima di 1. Agosto 2022 è necessario avviare una modifica di configurazione temporanea alla rete virtuale/subnet per l'impostazione da sincronizzare dalla sottoscrizione. Un esempio può essere quello di aggiungere una subnet temporanea, associare/dissociare temporaneamente un gruppo di sicurezza di rete o configurare temporaneamente un endpoint di servizio. Per altre informazioni e risoluzione dei problemi di risoluzione dei problemi di connettività SMTP in uscita in Azure.

Routing della configurazione

Quando si usa l'integrazione della rete virtuale, è possibile configurare la modalità di gestione delle parti del traffico di configurazione. Per impostazione predefinita, il traffico di configurazione passerà direttamente sulla route pubblica, ma per i singoli componenti menzionati, è possibile configurarlo attivamente per essere instradato tramite l'integrazione della rete virtuale.

Archivio del contenuto

Portare la propria risorsa di archiviazione per il contenuto in spesso usato in Funzioni in cui l'archiviazione del contenuto è configurata come parte dell'app Funzioni.

Per instradare il traffico di archiviazione del contenuto tramite l'integrazione della rete virtuale, è necessario aggiungere un'impostazione dell'app denominata WEBSITE_CONTENTOVERVNET con il valore 1. Oltre all'aggiunta dell'impostazione dell'app, è necessario assicurarsi che qualsiasi firewall o gruppo di sicurezza di rete configurato nel traffico dalla subnet consenta il traffico alla porta 443 e 445.

Pull dell'immagine del contenitore

Quando si usano contenitori personalizzati per Linux, è possibile eseguire il pull del contenitore sull'integrazione della rete virtuale. Per instradare il traffico pull del contenitore attraverso l'integrazione della rete virtuale, è necessario aggiungere un'impostazione dell'app denominata WEBSITE_PULL_IMAGE_OVER_VNET con il valore true.

Impostazioni dell'app usando riferimenti Key Vault

Le impostazioni dell'app che usano Key Vault riferimenti tenteranno di ottenere segreti sulla route pubblica. Se il Key Vault blocca il traffico pubblico e l'app usa l'integrazione della rete virtuale, verrà eseguito un tentativo di ottenere i segreti tramite l'integrazione della rete virtuale.

Nota

  • I contenitori Windows non supportano il pull di immagini di contenitori personalizzate tramite l'integrazione della rete virtuale.
  • Il backup o il ripristino agli account di archiviazione privati non è attualmente supportato.
  • La configurazione dei certificati SSL/TLS da Key Vault privati non è attualmente supportata.
  • servizio app i log agli account di archiviazione privati non sono attualmente supportati. È consigliabile usare la registrazione diagnostica e consentire servizi attendibili per l'account di archiviazione.

Routing di rete

È possibile usare le tabelle di route per instradare il traffico in uscita dall'app senza restrizioni. Le destinazioni comuni possono includere dispositivi firewall o gateway. È anche possibile usare un gruppo di sicurezza di rete (NSG) per bloccare il traffico in uscita alle risorse nella rete virtuale o internet. Un gruppo di sicurezza di rete applicato alla subnet di integrazione è effettivo indipendentemente da qualsiasi tabella di route applicata alla subnet di integrazione.

Le tabelle di route e i gruppi di sicurezza di rete si applicano solo al traffico instradato tramite l'integrazione della rete virtuale. Per informazioni dettagliate, vedere routing dell'applicazione e routing della configurazione . Le route non influiscono sulle risposte alle richieste di app in ingresso e alle 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.

Quando si configurano gruppi di sicurezza di rete o tabelle di route che influiscono sul traffico in uscita, è necessario assicurarsi di considerare le dipendenze dell'applicazione. Le dipendenze dell'applicazione includono endpoint necessari per l'app durante il runtime. Oltre alle API e ai servizi che l'app sta chiamando, questo potrebbe anche essere endpoint derivati come l'elenco di revoche di certificati (CRL) controlla gli endpoint e l'endpoint di identità/autenticazione, ad esempio Azure Active Directory. Se si usa la distribuzione continua in servizio app, è anche necessario consentire gli endpoint a seconda del tipo e della lingua. In particolare per la distribuzione continua di Linux, è necessario consentire oryx-cdn.microsoft.io:443.

Quando si vuole instradare il traffico in uscita in locale, è possibile usare una tabella di route per inviare il traffico in uscita al gateway Di Azure ExpressRoute. Se si esegue il routing del traffico a un gateway, impostare 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 elementi come un gateway ExpressRoute, ciò influisce sul traffico in uscita dell'app. Analogamente alle route definite dall'utente, le route BGP influiscono sul traffico in base all'impostazione dell'ambito di routing.

Endpoint di servizio

L'integrazione della rete virtuale a livello di area consente di raggiungere i servizi di Azure protetti con gli endpoint di servizio. Per accedere a un servizio protetto dall'endpoint di servizio, seguire questa procedura:

  1. Configurare l'integrazione della rete virtuale 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.

Endpoint privati

Se si desidera effettuare chiamate a endpoint privati, 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, l'integrazione viene eseguita automaticamente quando le zone sono collegate alla rete virtuale.
  • Gestire l'endpoint privato nel server DNS usato dall'app. Per gestire la configurazione, è necessario conoscere l'indirizzo IP dell'endpoint privato. Puntare quindi l'endpoint a cui si sta tentando di raggiungere tale indirizzo usando un record A.
  • Configurare il server DNS per l'inoltro a zone private di DNS di Azure.

Zone private di DNS di Azure

Dopo aver integrato l'app con la rete virtuale, usa lo stesso server DNS con cui è configurata la rete virtuale. Se non viene specificato alcun DNS personalizzato, usa DNS predefinito di Azure e qualsiasi zona privata collegata alla rete virtuale.

Limitazioni

Esistono alcune limitazioni con l'uso dell'integrazione della rete virtuale a livello di area:

  • La funzionalità è disponibile da tutte le distribuzioni di servizio app in Premium v2 e Premium v3. È disponibile anche nel livello Basic e Standard, ma solo dalle distribuzioni di servizio app più recenti. Se si è in una distribuzione precedente, è possibile usare solo la funzionalità da un piano di servizio app Premium v2. Per assicurarsi di poter usare la funzionalità in un piano di servizio app Basic o Standard, creare l'app in un piano di servizio app Premium v3. Questi piani sono supportati solo nelle distribuzioni più recenti. È possibile ridurre il numero di istanze se si vuole dopo la creazione del piano.
  • La funzionalità non può essere usata dalle app del piano isolato che si trovano in un ambiente del servizio app.
  • Non è possibile raggiungere le risorse tra connessioni di peering con reti virtuali classiche.
  • La funzionalità richiede una subnet inutilizzata che è un blocco IPv4 /28 o maggiore in una rete virtuale di Azure Resource Manager.
  • L'app e la rete virtuale devono trovarsi nella stessa area.
  • La rete virtuale di integrazione non può avere spazi di indirizzi IPv6 definiti.
  • La subnet di integrazione non può avere criteri dell'endpoint di servizio abilitati.
  • La subnet di integrazione può essere usata da un solo piano di servizio app.
  • Non è possibile eliminare una rete virtuale con un'app integrata. Rimuovere l'integrazione prima di eliminare la rete virtuale.
  • È possibile disporre di un'unica 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 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.

Integrazione della rete virtuale richiesta dal gateway

L'integrazione della rete virtuale richiesta dal gateway supporta la connessione a una rete virtuale in un'altra area o a una rete virtuale classica. Integrazione della rete virtuale richiesta dal gateway:

  • Consente a un'app di connettersi a una sola rete virtuale alla volta.
  • Consente di integrare fino a cinque reti virtuali all'interno di un piano di servizio app.
  • Consente di usare la stessa rete virtuale da più app in un piano di servizio app senza influire sul numero totale che può essere usato da un piano di servizio app. Se si hanno sei app che usano la stessa rete virtuale nello stesso piano di servizio app che conta come una rete virtuale usata.
  • Il contratto di servizio nel gateway può influire sul contratto di servizio complessivo.
  • Consente alle app di usare il DNS con cui è configurata la rete virtuale.
  • Richiede un gateway basato su route di rete virtuale configurato con una VPN da punto a sito SSTP prima che possa essere connessa a un'app.

Non è possibile usare l'integrazione della rete virtuale richiesta dal gateway:

  • Con una rete virtuale connessa con ExpressRoute.
  • Da un'app Linux.
  • Da un contenitore Windows.
  • Per accedere alle risorse protette dall'endpoint di servizio.
  • Per risolvere le impostazioni dell'app che fanno riferimento a una rete protetta Key Vault.
  • Con un gateway di coesistenza che supporta le VPN sia ExpressRoute che da punto a sito o da sito a sito.

Configurare un gateway nella rete virtuale di Azure

Per creare un gateway:

  1. Creare il gateway VPN e la subnet. Selezionare un tipo di VPN basato su route.

  2. Impostare gli indirizzi da punto a sito. Se il gateway non si trova nello SKU di base, IKEV2 deve essere disabilitato nella configurazione da punto a sito e SSTP deve essere selezionato. Lo spazio indirizzi da punto a sito deve essere compreso nei blocchi di indirizzi RFC 1918 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16.

Se si crea il gateway da usare con l'integrazione della rete virtuale richiesta dal gateway, non è necessario caricare un certificato. La creazione del gateway può richiedere 30 minuti. Non sarà possibile integrare l'app con la rete virtuale fino alla creazione del gateway.

Funzionamento dell'integrazione della rete virtuale richiesta dal gateway

L'integrazione della rete virtuale richiesta dal gateway è basata sulla tecnologia VPN da punto a sito. Le VPN da punto a sito limitano alla macchina virtuale che ospita l'app l'accesso alla rete. Le app sono limitate all'invio del traffico a Internet solo tramite connessioni ibride o tramite l'integrazione della rete virtuale. Quando l'app è configurata con il portale per usare l'integrazione della rete virtuale richiesta dal gateway, una negoziazione complessa viene gestita per conto dell'utente per creare e assegnare certificati sul gateway e sul lato applicazione. Il risultato è che i lavoratori usati per ospitare le app possono connettersi direttamente al gateway di rete virtuale nella rete virtuale selezionata.

Diagramma che mostra il funzionamento dell'integrazione della rete virtuale richiesta dal gateway.

Accedere alle risorse locali

Le app possono accedere alle risorse locali integrando con reti virtuali con connessioni da sito a sito. Se si usa l'integrazione della rete virtuale richiesta dal gateway gateway, aggiornare le route del gateway VPN locale con i blocchi di indirizzi da punto a sito. Quando la connessione VPN da sito a sito viene configurata per la prima volta, gli script usati per la configurazione devono configurare le route in modo appropriato. Se gli indirizzi da punto a sito vengono aggiunti dopo aver creato la VPN da sito a sito, è necessario aggiornare le route manualmente. Le informazioni dettagliate su come eseguire questa operazione variano in base al gateway e non sono descritte in questo documento.

Le route BGP dall'ambiente locale non verranno propagate automaticamente in servizio app. È necessario propagarli manualmente nella configurazione da punto a sito usando la procedura descritta in questo documento Pubblicizzare le route personalizzate per i client VPN P2S.

Non è necessaria alcuna configurazione aggiuntiva per la funzionalità di integrazione della rete virtuale a livello di area per raggiungere la rete virtuale alle risorse locali. È sufficiente connettere la rete virtuale alle risorse locali usando ExpressRoute o una VPN da sito a sito.

Nota

La funzionalità di integrazione della rete virtuale richiesta dal gateway non integra un'app con una rete virtuale con un gateway ExpressRoute. Anche se il gateway ExpressRoute è configurato in modalità coesistenza, l'integrazione della rete virtuale non funziona. Se è necessario accedere alle risorse tramite una connessione ExpressRoute, usare la funzionalità di integrazione della rete virtuale a livello di area o un ambiente del servizio app, che viene eseguito nella rete virtuale.

Peering

Se si usa il peering con l'integrazione della rete virtuale a livello di area, non è necessario eseguire altre operazioni di configurazione.

Se si usa l'integrazione della rete virtuale richiesta dal gateway con il peering, è necessario configurare alcuni altri elementi. Per configurare il peering per interagire con l'app:

  1. Aggiungere una connessione di peering nella rete virtuale a cui si connette l'app. Quando si aggiunge la connessione di peering, abilitare Consenti accesso alla rete virtuale e selezionare Consenti traffico inoltrato e Consenti transito gateway.
  2. Aggiungere una connessione peering nella rete virtuale a cui viene eseguito il peering alla rete virtuale a cui si è connessi. Quando si aggiunge la connessione di peering nella rete virtuale di destinazione, abilitare Consenti accesso alla rete virtuale e selezionare Consenti traffico inoltrato e Consenti gateway remoti.
  3. Passare a servizio app pianificare>l'integrazionedella> rete virtuale nel portale. Selezionare la rete virtuale a cui si connette l'app. Nella sezione routing aggiungere l'intervallo di indirizzi della rete virtuale a cui viene eseguito il peering con la rete virtuale a cui è connessa l'app.

Gestire l'integrazione della rete virtuale

La connessione e la disconnessione con una rete virtuale è a livello di app. Le operazioni che possono influire sull'integrazione della rete virtuale in più app sono a livello di piano di servizio app. Dal portale diintegrazione della rete virtuale di rete> app > è possibile ottenere informazioni dettagliate sulla rete virtuale. È possibile visualizzare informazioni simili a livello di piano servizio app nel portale di integrazione della retevirtuale di rete servizio app>>.

L'unica operazione che è possibile eseguire nella visualizzazione app dell'istanza di integrazione della rete virtuale consiste nel disconnettere l'app dalla rete virtuale a cui è attualmente connesso. Per disconnettere l'app da una rete virtuale, selezionare Disconnetti. L'app viene riavviata quando si disconnette da una rete virtuale. La disconnessione non modifica la rete virtuale. La subnet o il gateway non viene rimosso. Se si vuole eliminare la rete virtuale, disconnettere prima l'app dalla rete virtuale ed eliminare le risorse, ad esempio i gateway.

L'interfaccia utente di integrazione della rete virtuale servizio app mostra tutte le integrazioni di rete virtuale usate dalle app nel piano di servizio app. Per visualizzare i dettagli su ogni rete virtuale, selezionare la rete virtuale a cui si è interessati. Sono disponibili due azioni che è possibile eseguire qui per l'integrazione della rete virtuale richiesta dal gateway:

  • Rete di sincronizzazione: l'operazione di rete di sincronizzazione viene usata solo per la funzionalità di integrazione della rete virtuale richiesta dal gateway. L'esecuzione di un'operazione di rete di sincronizzazione garantisce che i certificati e le informazioni di rete siano sincronizzati. Se si aggiunge o si modifica il DNS della rete virtuale, eseguire un'operazione di rete di sincronizzazione. Questa operazione riavvia tutte le app che usano questa rete virtuale. Questa operazione non funzionerà se si usa un'app e una rete virtuale appartenente a sottoscrizioni diverse.
  • Aggiungere route: l'aggiunta di route esegue il traffico in uscita nella rete virtuale.

L'INDIRIZZO IP privato assegnato all'istanza viene esposto tramite la variabile di ambiente WEBSITE_PRIVATE_IP. L'interfaccia utente della console Kudu mostra anche l'elenco delle variabili di ambiente disponibili per l'app Web. Questo INDIRIZZO IP viene assegnato dall'intervallo di indirizzi della subnet integrata. Per l'integrazione della rete virtuale a livello di area, il valore di WEBSITE_PRIVATE_IP è un indirizzo IP dall'intervallo di indirizzi della subnet delegata. Per l'integrazione della rete virtuale richiesta dal gateway, il valore è un IP dall'intervallo di indirizzi del pool di indirizzi da punto a sito configurato nel gateway di rete virtuale. Questo indirizzo IP verrà usato dall'app Web per connettersi alle risorse tramite la rete virtuale di Azure.

Nota

Il valore di WEBSITE_PRIVATE_IP è associato alla modifica. Tuttavia, sarà un INDIRIZZO IP all'interno dell'intervallo di indirizzi della subnet di integrazione o dell'intervallo di indirizzi da punto a sito, quindi sarà necessario consentire l'accesso dall'intero intervallo di indirizzi.

Routing di integrazione della rete virtuale richiesta dal gateway

Le route definite nella rete virtuale vengono usate per indirizzare il traffico nella rete virtuale dall'app. Per inviare più traffico in uscita alla rete virtuale, aggiungere i blocchi di indirizzi qui. Questa funzionalità funziona solo con l'integrazione della rete virtuale richiesta dal gateway. Le tabelle di route non influiscono sul traffico dell'app quando si usa l'integrazione della rete virtuale richiesta dal gateway con l'integrazione della rete virtuale a livello di area.

Certificati di integrazione della rete virtuale necessari per il gateway

Quando l'integrazione della rete virtuale richiesta dal gateway è abilitata, è disponibile uno scambio obbligatorio di certificati per garantire la sicurezza della connessione. Con i certificati si ottengono la configurazione DNS, le route e altre informazioni simili che descrivono la rete.

Se vengono modificati i certificati o le informazioni di rete, selezionare Sincronizza rete. Quando si seleziona Sincronizza rete, si causa una breve interruzione della connettività tra l'app e la rete virtuale. L'app non viene riavviata, ma la perdita di connettività potrebbe causare la mancata corretta funzione del sito.

Dettagli prezzi

La funzionalità di integrazione della rete virtuale a livello di area non prevede costi aggiuntivi per l'uso oltre i costi del piano tariffario del piano di servizio app.

Tre addebiti sono correlati all'uso della funzionalità di integrazione della rete virtuale richiesta dal gateway:

  • servizio app piano tariffario: le app devono trovarsi in un piano di servizio app Basic, Standard, Premium, Premium v2 o Premium v3. Per altre informazioni sui costi, vedere Prezzi di Servizio app.
  • Costi di trasferimento dei dati: è previsto un addebito per l'uscita dei dati, anche se la rete virtuale si trova nello stesso data center. Tali addebiti sono descritti nei dettagli dei prezzi del trasferimento dati.
  • Costi del gateway VPN: è previsto un costo per il gateway di rete virtuale necessario per la connessione VPN da punto a sito. Per altre informazioni, vedere Prezzi di Gateway VPN.

Risoluzione dei problemi

Nota

L'integrazione della rete virtuale non è supportata per gli scenari Docker Compose in servizio app. Le restrizioni di accesso vengono ignorate se è presente un endpoint privato.

La funzionalità è facile da configurare, ma ciò non significa che l'esperienza sarà gratuita. Se si verificano problemi di accesso all'endpoint desiderato, sono disponibili alcune utilità che è possibile usare per testare la connettività dalla console dell'app. Le console disponibili sono due: Una è la console Kudu e l'altra è la console nella portale di Azure. Per raggiungere la console Kudu dall'app, passare a Strumenti>Kudu. È anche possibile raggiungere la console Kudo in [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 dei vincoli di sicurezza (funzionano nei contenitori di Windows personalizzati). Per riempire il vuoto, 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 testare se si dispone di elementi non configurati 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 ambientali WEBSITE_DNS_SERVER e WEBSITE_DNS_ALT_SERVER.

Nota

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

È possibile usare lo strumento successivo per testare la connettività TCP a una combinazione 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 host e porta e l'accesso di rete dall'app all'host e alla porta specificati.

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

Un certo numero di cose può impedire all'app di raggiungere un host e una porta specifici. La maggior parte del tempo è 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 molte cose oltre i firewall, ma iniziano lì.
  • Il DNS non è accessibile. Il timeout DNS è di 3 secondi per 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 avere un firewall o un gruppo di sicurezza di rete che blocca l'accesso a DNS o potrebbe essere inattivo.

Se questi elementi non rispondono ai problemi, cercare prima di tutto cose 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 ad 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 della 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 che un utente che possa impostare attributi nella subnet di integrazione per delegare la subnet. Per delegare manualmente la subnet di integrazione, passare all'interfaccia utente della subnet di Azure Rete virtuale 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.255 / 172.16.16.0 0.0-172.31.255.255/192.168.0.0-192.168.255.255)?
  • Il gateway viene visualizzato come aggiornato 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 di configurazione, selezionare Sincronizza rete.
  • Se si sta passando una VPN, il gateway locale è configurato per instradare il backup del 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 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:

  • È disponibile un firewall sull'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 rispetto a 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 dell'applicazione e alla porta dall'intervallo IP da punto a sito.

Non si conosce l'indirizzo che l'app usa effettivamente. Potrebbe essere 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:port da questa posizione. Per testare l'accesso TCP, usare il comando Test-NetConnection di PowerShell. 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 rete virtuale. Usare il comando Test-NetConnection PowerShell 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 o il piano di servizio app è stato eliminato 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 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 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 eseguito i passaggi precedenti, contattare supporto tecnico Microsoft.