Domande frequenti sulla rete virtuale di Azure

Nozioni di base sulla rete virtuale

Che cos'è una rete virtuale di Azure?

Una rete virtuale (VNet) di Azure è una rappresentazione della rete personalizzata nel cloud. È un isolamento logico del cloud di Azure dedicato alla sottoscrizione. È possibile usare le reti virtuali per eseguire il provisioning e gestire reti virtuali private (VPN) in Azure e facoltativamente collegare le reti virtuali con altre reti virtuali in Azure o con l'infrastruttura IT locale per creare soluzioni ibride o cross-premise. Ogni rete virtuale creata ha il proprio blocco CIDR e può essere collegata ad altre reti virtuali e reti locali purché i blocchi CIDR non si sovrappongano. È anche possibile controllare le impostazioni del server DNS per le reti virtuali e la segmentazione della rete virtuale in subnet.

Usare le reti virtuali per:

  • Creare una rete virtuale solo cloud privata e dedicata. Per una soluzione personalizzata, non è sempre necessaria una configurazione cross-premise. Quando si crea una rete virtuale, i servizi e le macchine virtuali all'interno della rete virtuale possono comunicare direttamente e in modo sicuro tra loro nel cloud. È ancora possibile configurare connessioni di endpoint per le VM e i servizi che richiedono la comunicazione Internet come parte della soluzione.

  • Estendere in modo sicuro il data center. Con le reti virtuali è possibile creare reti virtuali private da sito a sito (S2S) tradizionali per la scalabilità sicura della capacità del data center. Le reti virtuali private S2S usano IPSEC per fornire una connessione sicura tra il gateway VPN della rete virtuale privata aziendale e Azure.

  • Abilitare scenari cloud ibridi. Le reti virtuali offrono la flessibilità per supportare una gamma di scenari cloud ibridi. È possibile connettere applicazioni basate sul cloud in modo sicuro a qualsiasi tipo di sistema locale, come mainframe e sistemi Unix.

Come iniziare?

Per iniziare, vedere la documentazione relativa alla rete virtuale . che contiene una panoramica e informazioni sulla distribuzione per tutte le funzionalità di rete virtuale.

È possibile usare reti virtuali senza connettività cross-premise?

Sì. È possibile usare una rete virtuale senza connetterla all'ambiente locale. Ad esempio, è possibile eseguire controller di dominio Active Directory di Windows Server e farm di SharePoint esclusivamente in una rete virtuale di Azure.

È possibile eseguire l'ottimizzazione WAN tra reti virtuali o tra una rete virtuale e il data center locale?

Sì. È possibile distribuire appliance virtuali di rete per l'ottimizzazione WAN di diversi fornitori tramite Azure Marketplace.

Configurazione

Quali strumenti si usano per creare una rete virtuale?

Per creare o configurare una rete virtuale, è possibile usare gli strumenti seguenti:

Quali intervalli di indirizzi è possibile usare nelle reti virtuali?

È consigliabile usare gli intervalli di indirizzi enumerati in RFC 1918, che sono stati messi da parte da IETF per gli spazi indirizzi privati e non instradabili:

  • 10.0.0.0 - 10.255.255.255 (prefisso 10/8)
  • 172.16.0.0 - 172.31.255.255 (prefisso 172.16/12)
  • 192.168.0.0 - 192.168.255.255 (prefisso 192.168/16)

È anche possibile distribuire lo spazio indirizzi condiviso riservato in RFC 6598, che viene considerato come spazio indirizzi IP privati in Azure:

  • 100.64.0.0 - 100.127.255.255 (prefisso 100.64/10)

Altri spazi indirizzi, inclusi tutti gli altri spazi indirizzi privati, non instradabili, riconosciuti da IETF, possono funzionare ma potrebbero avere effetti collaterali indesiderati.

Inoltre, non è possibile aggiungere gli intervalli di indirizzi seguenti:

  • 224.0.0.0/4 (multicast)
  • 255.255.255.255/32 (broadcast)
  • 127.0.0.0/8 (loopback)
  • 169.254.0.0/16 (locale rispetto al collegamento)
  • 168.63.129.16/32 (DNS interno)

È possibile avere indirizzi IP pubblici nelle reti virtuali?

Sì. Per altre informazioni sugli intervalli di indirizzi IP pubblici, vedere Create a virtual network (Creare una rete virtuale). Gli indirizzi IP pubblici non sono accessibili direttamente da Internet.

Esiste un limite al numero di subnet nella rete virtuale?

Sì. Vedere Limiti di Azure per informazioni dettagliate. Gli spazi degli indirizzi della subnet non possono sovrapporsi.

Esistono restrizioni sull'uso di indirizzi IP all'interno di tali subnet?

Sì. Azure riserva i primi quattro e l'ultimo indirizzo IP, per un totale di 5 indirizzi IP, all'interno di ogni subnet.

L'intervallo di indirizzi IP 192.168.1.0/24, ad esempio, contiene gli indirizzi riservati seguenti:

  • 192.168.1.0: indirizzo di rete
  • 192.168.1.1: riservato da Azure per il gateway predefinito
  • 192.168.1.2, 192.168.1.3: riservato da Azure per il mapping degli IP DNS di Azure allo spazio della rete virtuale
  • 192.168.1.255: indirizzo di broadcast di rete.

Quanto piccole o grandi possono essere le reti virtuali e le subnet?

La subnet IPv4 più piccola supportata è /29 e la più grande è /2 (in base alle definizioni di subnet CIDR). Le subnet IPv6 devono avere esattamente una dimensione di /64.

È possibile trasferire le reti VLAN in Azure usando reti virtuali?

No. Le reti virtuali sono sovrapposizioni di livello 3. Azure non supporta alcuna semantica di livello 2.

È possibile specificare criteri di routing personalizzati nelle reti virtuali e nelle subnet?

Sì. È possibile creare una tabella di route e associarla a una subnet. Per altre informazioni sul routing in Azure, vedere Panoramica sul routing.

Qual è il comportamento quando si applicano gruppi di sicurezza di rete e route definita dall'utente nella subnet?

Per il traffico in ingresso, vengono elaborate le regole in ingresso del gruppo di sicurezza di rete. Per le regole in uscita, le regole in uscita del gruppo di sicurezza di rete vengono elaborate in base alle regole della route definita dall'utente.

Qual è il comportamento quando si applica un gruppo di sicurezza di rete alla scheda di interfaccia di rete e alla subnet per una macchina virtuale?

Quando i gruppi di sicurezza di rete vengono applicati sia alle & subnet della scheda di interfaccia di rete per una macchina virtuale, il gruppo di sicurezza di rete a livello di subnet seguito dal gruppo di sicurezza di rete a livello di scheda di interfaccia di rete viene elaborato per il gruppo di sicurezza di rete a livello di rete in ingresso e NIC seguito dal gruppo di sicurezza di rete a livello di subnet per il traffico in uscita.

Le reti virtuali supportano la distribuzione multicast o broadcast?

No. La distribuzione multicast o broadcast non è supportata.

Quali protocolli è possibile usare all'interno delle reti virtuali?

All'interno delle reti virtuali è possibile usare i protocolli TCP, UDP e ICMP TCP/IP. Unicast è supportato nelle reti virtuali. I pacchetti incapsulati IP in IP, multicast e broadcast e i pacchetti Generic Routing Encapsulation (GRE) sono bloccati all'interno delle reti virtuali. Non è possibile usare DYNAMIC Host Configuration Protocol (DHCP) tramite Unicast (porta di origine UDP/68/porta di destinazione UDP/67). Porta di origine UDP 65330 riservata all'host. Vedere "È possibile distribuire un server DHCP in una rete virtuale" per altri dettagli su ciò che è e non è supportato per DHCP.

È possibile distribuire un server DHCP in una rete virtuale?

Le reti virtuali di Azure forniscono servizio DHCP e DNS alle macchine virtuali e dhcp client/server (porta di origine UDP/68, porta di destinazione UDP/67) non supportate in una rete virtuale. Non è possibile distribuire il proprio servizio DHCP per ricevere e fornire traffico DHCP unicast/broadcast client/server. È possibile distribuire un server DHCP in una macchina virtuale con la finalità di ricevere il traffico DHCP unicast (porta di origine UDP/67, porta di destinazione UDP/67). Un possibile scenario consiste nel configurare l'inoltro DHCP dai dispositivi locali a una macchina virtuale di Azure che esegue un server DHCP. Il cliente è responsabile della configurazione dei dispositivi locali (ad esempio, configurazione del router) per creare questo traffico di inoltro DHCP all'INDIRIZZO IP della macchina virtuale in Azure.

È possibile eseguire il ping del gateway predefinito all'interno di una rete virtuale?

No. Il gateway predefinito fornito da Azure non risponde al ping. È tuttavia possibile usare ping nelle reti virtuali per controllare la connettività e la risoluzione dei problemi tra macchine virtuali.

È possibile usare tracert per diagnosticare la connettività?

Sì.

È possibile aggiungere subnet dopo la creazione della rete virtuale?

Sì. Le subnet possono essere aggiunte alle reti virtuali in qualsiasi momento purché l'intervallo di indirizzi della subnet non faccia parte di un'altra subnet e vi sia sufficiente spazio disponibile nell'intervallo di indirizzi della rete virtuale.

È possibile modificare le dimensioni della subnet dopo averla creata?

Sì. È possibile aggiungere, rimuovere, espandere o compattare una subnet se non sono presenti macchine virtuali o servizi distribuiti al suo interno.

È possibile modificare la rete virtuale dopo averli creati?

Sì. È possibile aggiungere, rimuovere e modificare i blocchi CIDR utilizzati da una rete virtuale.

Se si eseguono i servizi in una rete virtuale, è possibile connettersi a Internet?

Sì. Tutti i servizi distribuiti all'interno di una rete virtuale possono effettuare la connessione in uscita a Internet. Per altre informazioni sulle connessioni Internet in uscita in Azure, vedere Connessioni in uscita. Se si vuole effettuare la connessione in ingresso a una risorsa distribuita tramite Resource Manager, la risorsa deve avere un indirizzo IP pubblico assegnato. Per altre informazioni sugli indirizzi IP pubblici, vedere Indirizzi IP pubblici. A ciascun servizio cloud di Azure distribuito in Azure viene assegnato un indirizzo VIP indirizzabile pubblicamente. Per abilitare tali servizi in modo che accettino le connessioni da Internet, è necessario definire gli endpoint di input per i ruoli PaaS e gli endpoint per le macchine virtuali.

Le reti virtuali supportano IPv6?

Sì, le reti virtuali possono essere solo IPv4 o dual stack (IPv4+IPv6). Per informazioni dettagliate, vedere Panoramica di IPv6 per reti virtuali di Azure.

Una rete virtuale può estendersi a più aree?

No. Una rete virtuale è limitata a una singola area. Tuttavia, una rete virtuale si estende su zone di disponibilità. Per altre informazioni sulle zone di disponibilità, vedere Panoramica delle zone di disponibilità. È possibile connettere reti virtuali in diverse aree con il peering di rete virtuale. Per informazioni dettagliate, vedere Panoramica del peering di rete virtuale.

È possibile connettere una rete virtuale a un'altra rete virtuale in Azure?

Sì. È possibile connettere una rete virtuale a un'altra usando:

Risoluzione del nome (DNS)

Quali sono le opzioni DNS per le reti virtuali?

Usare la tabella delle decisioni nella pagina Risoluzione dei nomi per le VM e le istanze del ruolo come guida per tutte le opzioni DNS disponibili.

È possibile specificare i server DNS per una rete virtuale?

Sì. È possibile specificare gli indirizzi IP del server DNS nelle impostazioni della rete virtuale. L'impostazione viene applicata come server DNS predefiniti per tutte le macchine virtuali nella rete virtuale.

Quanti server DNS è possibile specificare?

Fare riferimento a Limiti di Azure.

È possibile modificare i server DNS dopo aver creato la rete?

Sì. È possibile modificare l'elenco dei server DNS per la rete virtuale in qualsiasi momento. Se si modifica l'elenco di server DNS, è necessario eseguire un rinnovo del lease DHCP in tutte le macchine virtuali interessate nella rete virtuale, affinché le nuove impostazioni DNS siano effettive. Per le macchine virtuali che eseguono il sistema operativo Windows, è possibile eseguire questa operazione digitando ipconfig /renew direttamente nella macchina virtuale. Per altri tipi di sistema operativo, fare riferimento alla documentazione di rinnovo del lease DHCP per il tipo di sistema operativo specifico.

Qual è il DNS fornito da Azure e funziona con le reti virtuali?

Il DNS fornito da Azure è un servizio DNS multi-tenant offerto da Microsoft. Azure registra tutte le macchine virtuali e le istanze del ruolo del servizio cloud in questo servizio. Questo servizio fornisce la risoluzione dei nomi dal nome host per le macchine virtuali e le istanze del ruolo contenute all'interno dello stesso servizio cloud e da FQDN per le macchine virtuali e le istanze del ruolo nella stessa rete virtuale. Per altre informazioni sul servizio DNS, vedere Risoluzione dei nomi per le macchine virtuali e le istanze del ruolo di Servizi cloud.

Esiste una limitazione ai primi 100 servizi cloud nella rete virtuale per la risoluzione dei nomi cross-tenant tramite il DNS fornito da Azure. Se si utilizza il proprio server DNS, questa limitazione non viene applicata.

È possibile ignorare le impostazioni DNS in base alla macchina virtuale o al servizio cloud?

Sì. È possibile impostare i server DNS in base alla macchina virtuale o al servizio cloud per ignorare le impostazioni di rete predefinite. Tuttavia, è consigliabile usare quanto più possibile DNS a livello di rete.

È possibile trasferire il suffisso DNS personalizzato?

No. Non è possibile specificare un suffisso DNS personalizzato per le reti virtuali.

Connessione di macchine virtuali

È possibile distribuire le macchine virtuali su una rete virtuale?

Sì. Tutte le scheda di interfaccia di rete collegate a una macchina virtuale distribuita con il modello di distribuzione Resource Manager devono essere connesse a una rete virtuale. Facoltativamente, è possibile connettere le macchine virtuali distribuite con il modello di distribuzione classica a una rete virtuale.

Quali tipi di indirizzi IP è possibile assegnare alle macchine virtuali?

  • Privato: assegnato a ogni scheda di interfaccia di rete all'interno di ogni macchina virtuale. L'indirizzo viene assegnato con il metodo statico o dinamico. Gli indirizzi IP privati vengono assegnati dall'intervallo specificato nelle impostazioni della subnet della rete virtuale. Alle risorse distribuite con il modello di distribuzione classica vengono assegnati indirizzi IP privati, anche se non sono connesse a una rete virtuale. Il comportamento del metodo di allocazione è diverso a seconda del fatto che una risorsa sia stata distribuita con il modello di distribuzione Resource Manager o classica:

    • Resource Manager: un indirizzo IP privato assegnato con il metodo dinamico o statico rimane assegnato a una macchina virtuale (Resource Manager) finché la risorsa non viene eliminata. La differenza consiste nel fatto che quando si usa il metodo statico si seleziona l'indirizzo da assegnare, mentre quando si usa quello dinamico sceglie Azure.
    • Classica: un indirizzo IP privato assegnato con il metodo dinamico può cambiare quando una macchina virtuale (classica) viene riavviata dopo essere stata arrestata (deallocata). Se è necessario assicurarsi che l'indirizzo IP privato per una risorsa distribuita tramite il modello di distribuzione classica non cambi mai, assegnare un indirizzo IP privato con il metodo statico.
  • Pubblico: assegnato facoltativamente alle schede di interfaccia di rete collegate a macchine virtuali distribuite con il modello di distribuzione Azure Resource Manager. L'indirizzo può essere assegnato con il metodo di allocazione statica o dinamica. Tutte le macchine virtuali e le istanze del ruolo dei servizi cloud distribuite con il modello di distribuzione classica esistono all'interno di un servizio cloud, a cui viene assegnato un indirizzo IP virtuale (VIP) pubblico dinamico. Facoltativamente, è possibile assegnare un indirizzo IP pubblico statico, detto indirizzo IP riservato, come indirizzo VIP. Gli indirizzi IP pubblici possono essere assegnati a singole macchine virtuali o istanze del ruolo dei servizi cloud distribuite con il modello di distribuzione classica. Questi indirizzi sono denominati indirizzi IP pubblici a livello di istanza (ILPIP) e possono essere assegnati in modo dinamico.

È possibile riservare un indirizzo IP privato per una macchina virtuale che verrà creata in un secondo momento?

No. Non è possibile riservare un indirizzo IP privato. Se un indirizzo IP privato è disponibile, viene assegnato a una macchina virtuale o a un'istanza del ruolo dal server DHCP, indipendentemente dal fatto che la macchina virtuale sia o meno quella a cui si vuole assegnare l'indirizzo IP privato. È possibile tuttavia cambiare l'indirizzo IP privato di una macchina virtuale già creata con qualsiasi indirizzo IP privato disponibile.

Gli indirizzi IP privati vengono modificati per le macchine virtuali in una rete virtuale?

Dipende. Se la macchina virtuale è stata distribuita tramite Resource Manager, non vengono modificati, indipendentemente dal fatto che l'indirizzo IP sia stato assegnato con il metodo di allocazione statica o dinamica. Se la macchina virtuale è stata distribuita tramite il modello di distribuzione classica, gli indirizzi IP possono essere modificati quando una macchina virtuale viene avviata dopo essere stata arrestata (deallocata). L'indirizzo viene rilasciato da una macchina virtuale distribuita tramite uno dei modelli di distribuzione quando la macchina virtuale viene eliminata.

È possibile assegnare manualmente indirizzi IP alle schede di interfaccia di rete all'interno del sistema operativo di una macchina virtuale?

Sì, ma non è consigliabile a meno che non sia necessario, ad esempio quando si assegnano più indirizzi IP a una macchina virtuale. Per informazioni dettagliate, vedere Aggiunta di più indirizzi IP a una macchina virtuale. Se l'indirizzo IP assegnato a una scheda di interfaccia di rete di Azure collegata a una macchina virtuale viene modificato e l'indirizzo IP all'interno del sistema operativo della macchina virtuale è differente, si perde la connessione alla macchina virtuale.

Se si arresta il funzionamento di uno slot di distribuzione del servizio cloud o di una macchina virtuale dall'interno del sistema operativo, cosa accade agli indirizzi IP?

Nessun pacchetto. Gli indirizzi IP, pubblici, privati o indirizzi VIP pubblici, rimangano assegnati alla relativa macchina virtuale o allo slot di distribuzione del servizio cloud.

È possibile spostare le macchine virtuali da una subnet a un'altra in una rete virtuale senza ripetere la distribuzione?

Sì. Per altre informazioni, vedere l'articolo Come spostare una macchina virtuale o un'istanza del ruolo in un'altra subnet.

È possibile configurare un indirizzo MAC statico per la macchina virtuale?

No. Un indirizzo MAC non può essere configurato in modo statico.

L'indirizzo MAC rimarrà invariato per la macchina virtuale dopo averla creata?

Sì, l'indirizzo MAC rimane invariato sia che la macchina virtuale venga distribuita con il modello di distribuzione classica o Resource Manager, finché non viene eliminata. In precedenza se la macchina virtuale veniva arrestata, ovvero deallocata, l'indirizzo MAC veniva rilasciato. Ora viene mantenuto anche quando la macchina virtuale è in stato deallocato. L'indirizzo MAC rimarrà assegnato all'interfaccia di rete finché l'interfaccia non viene eliminata oppure non viene modificato l'indirizzo IP privato assegnato alla configurazione IP primaria dell'interfaccia di rete primaria.

È possibile eseguire la connessione a Internet da una macchina virtuale in una rete virtuale?

Sì. Tutte le macchine virtuali e le istanze del ruolo dei servizi cloud distribuite all'interno di una rete virtuale possono connettersi a Internet.

Servizi di Azure che si connettono a reti virtuali

È possibile usare le app Web del servizio app di Azure con una rete virtuale?

Sì. È possibile distribuire App Web all'interno di una rete virtuale usando un ambiente del servizio app (ambiente del servizio app), connettere il back-end delle app alle reti virtuali con integrazione della rete virtuale e bloccare il traffico in ingresso all'app con endpoint del servizio. Per altre informazioni, vedere gli articoli seguenti:

È possibile distribuire i servizi cloud con ruolo di lavoro e Web (PaaS) in una rete virtuale?

Sì. Facoltativamente, è possibile distribuire istanze del ruolo dei servizi cloud all'interno di reti virtuali. A tale scopo, specificare il nome della rete virtuale e i mapping dei ruoli e delle subnet nella sezione di configurazione della rete della configurazione del servizio. Non è necessario aggiornare i file binari.

È possibile connettere un set di scalabilità di macchine virtuali a una rete virtuale?

Sì. È necessario connettere un set di scalabilità di macchine virtuali a una rete virtuale.

È disponibile un elenco completo dei servizi di Azure da cui è possibile distribuire le risorse in una rete virtuale?

Sì. Per informazioni dettagliate, vedere Integrazione della rete virtuale per i servizi di Azure.

Come è possibile limitare l'accesso alle risorse PaaS di Azure da una rete virtuale?

Per le risorse distribuite tramite alcuni servizi PaaS di Azure, come Archiviazione di Azure e il database SQL di Azure, è possibile limitare l'accesso alla rete solo alla rete virtuale tramite l'uso di endpoint servizio di rete virtuale o di Collegamento privato di Azure. Per informazioni dettagliate, vedere Panoramica degli endpoint del servizio di rete virtuale, collegamento privato di Azure panoramica

È possibile spostare i servizi all’interno e all’esterno delle reti virtuali?

No. Non è possibile spostare i servizi all'interno e all'esterno delle reti virtuali. Per spostare una risorsa in un'altra rete virtuale, è necessario eliminarla e ridistribuirla.

Sicurezza

Che cos'è il modello di sicurezza per le reti virtuali?

Le reti virtuali sono isolate l'una dall'altra e gli altri servizi sono ospitati nell'infrastruttura di Azure. Una rete virtuale è un limite di attendibilità.

È possibile limitare il flusso del traffico in ingresso o in uscita alle risorse connesse alla rete virtuale?

Sì. È possibile applicare gruppi di sicurezza di rete a singole subnet all'interno di una rete virtuale e/o a schede di interfaccia di rete collegate a una rete virtuale.

È possibile implementare un firewall tra le risorse connesse alla rete virtuale?

Sì. È possibile distribuire appliance virtuali di rete di diversi fornitori tramite Azure Marketplace.

Sono disponibili informazioni sulla protezione di reti virtuali?

Sì. Per informazioni dettagliate, vedere Panoramica della sicurezza di rete di Azure.

Le reti virtuali archiviano i dati dei clienti?

No. Le reti virtuali non archivia i dati dei clienti.

È possibile impostare la proprietà FlowTimeoutInMinutes per un'intera sottoscrizione?

No. Questa operazione deve essere impostata nella rete virtuale. Di seguito è possibile automatizzare l'impostazione di questa proprietà per le sottoscrizioni più grandi:

$Allvnet = Get-AzVirtualNetwork
$time = 4 #The value should be between 4 and 30 minutes (inclusive) to enable tracking, or null to disable tracking. $null to disable. 
ForEach ($vnet in $Allvnet)
{
    $vnet.FlowTimeoutInMinutes = $time
    $vnet | Set-AzVirtualNetwork
}

API, schemi e strumenti

È possibile gestire le reti virtuali dal codice?

Sì. È possibile usare le API REST per le reti virtuali nei modelli di distribuzione di Azure Resource Manager e classica.

È disponibile il supporto degli strumenti per le reti virtuali?

Sì. Altre informazioni:

Peering reti virtuali

Che cos'è il peering di reti virtuali?

Il peering di reti virtuali consente di connettere le reti virtuali. Usando una connessione di peering di reti virtuali è possibile instradare il traffico tra le reti in modo privato tramite indirizzi IPv4. Le macchine virtuali nelle reti virtuali con peering possono comunicare tra loro come se si trovassero nella stessa rete. Queste reti virtuali possono trovarsi in aree geografiche uguali o diverse. In questo secondo caso, si parla di peering di reti virtuali globale. Le connessioni di peering di reti virtuali possono essere create anche tra sottoscrizioni di Azure.

È possibile creare una connessione di peering per una rete virtuale in un'area diversa?

Sì. Il peering di reti virtuali globale consente di eseguire il peering di reti virtuali in aree diverse. Il peering globale della rete virtuale è disponibile in tutte le aree pubbliche di Azure, le aree cloud cina e le aree cloud per enti pubblici. Non è possibile eseguire il peering globale da aree pubbliche di Azure alle aree cloud nazionali.

Se le due reti virtuali in due aree diverse vengono sottoposte a peering tra reti virtuali globali, non è possibile connettersi alle risorse che si trovano dietro un Load Balancer di base tramite l'IP front-end dell'Load Balancer. Questa restrizione non esiste per un Load Balancer Standard. Le risorse seguenti possono usare i servizi di bilanciamento del carico di base che significa che non è possibile raggiungerli tramite l'ip front-end del Load Balancer tramite il peering reti virtuali globali. È tuttavia possibile usare il peering reti virtuali globali per raggiungere le risorse direttamente tramite gli indirizzi IP di rete virtuale privata, se consentito.

  • Macchine virtuali dietro i servizi di bilanciamento del carico di base
  • Set di scalabilità di macchine virtuali con load Balancer di base
  • Cache Redis
  • SKU del gateway applicazione (v1)
  • Service Fabric
  • Gestione API (stv1)
  • Active Directory Domain Services (ADDS)
  • App per la logica
  • HDInsight
  • Azure Batch
  • Ambiente del servizio app

È possibile connettersi a queste risorse tramite ExpressRoute o da rete virtuale a rete virtuale tramite gateway di rete virtuale.

È possibile abilitare il peering reti virtuali se le reti virtuali appartengono a sottoscrizioni all'interno di diversi tenant di Azure Active Directory?

Sì. È possibile stabilire il peering reti virtuali (sia locale che globale) se le sottoscrizioni appartengono a tenant di Azure Active Directory diversi. A tale scopo, è possibile usare il portale, PowerShell o l'interfaccia della riga di comando.

La connessione al peering rete virtuale è nello stato Avviato, per quale motivo non è possibile connettersi?

Se la connessione di peering è in stato Avviato , significa che è stato creato un solo collegamento. È necessario creare un collegamento bidirezionale per stabilire una connessione. Ad esempio, per eseguire il peering di rete virtuale A a rete virtuale B, un collegamento deve essere creato da rete virtuale A a rete virtuale B e da rete virtuale B a rete virtuale A. La creazione di entrambi i collegamenti cambierà lo stato in Connesso.

La connessione di peering di reti virtuali è in stato Disconnesso. Per quale motivo non è possibile connettersi?

Se la connessione peering della rete virtuale è in stato Disconnesso , significa che uno dei collegamenti creati è stato eliminato. Per ristabilire una connessione di peering, è necessario eliminare il collegamento e ricrearlo.

È possibile eseguire il peering di rete virtuale con una rete virtuale in una sottoscrizione diversa?

Sì. È possibile eseguire il peering di reti virtuali tra sottoscrizioni e aree.

È possibile eseguire il peering di due reti virtuali con gli intervalli di indirizzi sovrapposti o corrispondenti?

No. Gli spazi indirizzi non devono sovrapporsi per consentire il peering reti virtuali.

È possibile eseguire il peering di una rete virtuale a due reti virtuali diverse con l'opzione "Usa gateway remoto" abilitata in entrambi i peering?

No. È possibile abilitare l'opzione "Usa gateway remoto" solo in un peering in una delle reti virtuali.

Non sono previsti addebiti per la creazione di una connessione peering di reti virtuali. Viene addebitato il trasferimento dei dati tra connessioni peering. Vedere qui.

Il traffico peering di rete virtuale è crittografato?

Quando il traffico di Azure si sposta tra data center (al di fuori dei limiti fisici non controllati da Microsoft o per conto di Microsoft), la crittografia del livello di collegamento dati MACsec viene usata nell'hardware di rete sottostante. Ciò è applicabile al traffico di peering reti virtuali.

Perché la connessione di peering è in stato Disconnesso ?

Le connessioni peering di rete virtuale passano allo stato Disconnesso quando viene eliminato un collegamento di peering della rete virtuale. È necessario eliminare entrambi i collegamenti per ristabilire una connessione peering.

Se si esegue il peering di rete virtuale A a rete virtuale B e il peering di rete virtuale B a rete virtuale C, significa che è stato eseguito il peering delle reti virtuali A e C?

No. Il peering transitivo non è supportato. Si dovrà eseguire il peering delle reti virtuali A e C affinché questo si verifichi.

Sono presenti limitazioni relative alla larghezza di banda per le connessioni peering?

No. La rete virtuale di peering, sia locale che globale, non impone restrizioni relative alla larghezza di banda. La larghezza di banda è limitata solo dalla macchina virtuale o dalla risorsa di calcolo.

Come è possibile risolvere i problemi di peering reti virtuali?

Ecco una guida alla risoluzione dei problemi che è possibile provare.

TAP di rete virtuale

Quali aree di Azure sono disponibili per la TAP di rete virtuale?

L'anteprima tap della rete virtuale è disponibile in tutte le aree di Azure. Le interfacce di rete monitorate, la risorsa punto di accesso terminale di rete virtuale e l'agente di raccolta o la soluzione di analisi devono essere distribuiti nella stessa area.

La TAP di rete virtuale supporta qualsiasi funzionalità di filtraggio dei pacchetti con mirroring?

Le funzionalità di filtro non sono supportate con l'anteprima TAP di rete virtuale. Quando si aggiunge una configurazione TAP a un'interfaccia di rete, una deep copy di tutto il traffico in ingresso e in uscita sull'interfaccia di rete viene inviata in streaming alla destinazione TAP.

È possibile aggiungere più configurazioni TAP a un'interfaccia di rete monitorata?

Un'interfaccia di rete monitorata può avere solo una configurazione TAP. Verificare con la soluzione partner individuale la possibilità di trasmettere più copie del traffico TAP agli strumenti di analisi di propria scelta.

Può la stessa risorsa TAP di rete virtuale aggregare il traffico dalle interfacce di rete monitorate in più di una rete virtuale?

Sì. La stessa risorsa TAP di rete virtuale può essere utilizzata per aggregare il traffico con mirroring da interfacce di rete monitorate in reti virtuali con peering nella stessa sottoscrizione o in una sottoscrizione diversa. La risorsa TAP di rete virtuale e il bilanciamento del carico di destinazione o l'interfaccia di rete di destinazione devono essere nella stessa sottoscrizione. Tutte le sottoscrizioni devono trovarsi nello stesso tenant di Azure Active Directory.

Ci sono considerazioni sulle prestazioni del traffico di produzione se abilito una configurazione TAP di rete virtuale su un'interfaccia di rete?

Tap di rete virtuale è disponibile in anteprima. Durante l'anteprima, non esiste alcun contratto di servizio. La funzionalità non deve essere utilizzata per i carichi di lavoro di produzione. Quando un'interfaccia di rete della macchina virtuale è abilitata con una configurazione TAP, vengono usate le stesse risorse nell'host di Azure allocato alla macchina virtuale per inviare il traffico di produzione per eseguire la funzione di mirroring e inviare i pacchetti con mirroring. Selezionare la dimensione corretta della macchina virtuale Linux o Windows per assicurarsi che siano disponibili risorse sufficienti affinché la macchina virtuale possa inviare il traffico di produzione e il traffico con mirroring.

Il networking accelerato per Linux o Windows è supportato con la TAP di rete virtuale?

Sarà possibile aggiungere una configurazione TAP a un'interfaccia di rete collegata a una macchina virtuale con networking accelerato abilitato. Ma le prestazioni e la latenza sulla macchina virtuale saranno influenzate dall'aggiunta della configurazione TAP, dato che l'offload per il mirroring del traffico non è attualmente supportato dal networking accelerato di Azure.

Endpoint servizio di rete virtuale

Qual è la sequenza corretta di operazioni per la configurazione di endpoint di servizio in un servizio di Azure?

Esistono due passaggi per proteggere una risorsa del servizio di Azure tramite gli endpoint di servizio:

  1. Attivare gli endpoint di servizio per il servizio di Azure.
  2. Configurare elenchi di controllo di accesso di rete virtuale nel servizio di Azure.

Il primo passaggio è un'operazione sul lato rete e il secondo passaggio è un'operazione sul lato risorsa del servizio. Entrambi i passaggi possono essere eseguiti dallo stesso amministratore o da amministratori diversi in base alle autorizzazioni di controllo degli accessi in base al ruolo di Azure concesse al ruolo di amministratore. È consigliabile attivare gli endpoint di servizio per la rete virtuale prima di configurare gli elenchi di controllo di accesso di rete virtuale sul lato servizio di Azure. Di conseguenza, i passaggi devono essere eseguiti nella sequenza elencata in precedenza per configurare gli endpoint servizio di rete virtuale.

Nota

Entrambe le operazioni descritte in precedenza devono essere completate prima di poter limitare l'accesso al servizio di Azure alla rete virtuale e alla subnet consentite. Se si attivano esclusivamente gli endpoint di servizio per il servizio di Azure sul lato rete, non è possibile limitare l'accesso. È inoltre necessario configurare elenchi di controllo di accesso di rete virtuale sul lato servizio di Azure.

Alcuni servizi, ad esempio Azure SQL e Azure Cosmos DB, consentono eccezioni alla sequenza precedente tramite il IgnoreMissingVnetServiceEndpoint flag . Dopo aver impostato il flag su True, gli ACL della rete virtuale possono essere impostati sul lato servizio di Azure prima di configurare gli endpoint di servizio sul lato rete. I servizi di Azure forniscono questo flag per aiutare i clienti nei casi in cui sono configurati firewall IP specifici nei servizi di Azure e l'attivazione degli endpoint di servizio sul lato rete può causare una perdita di connettività perché l'indirizzo IP di origine cambia passando da indirizzo IPv4 pubblico a indirizzo privato. La configurazione di elenchi di controllo di accesso di rete virtuale sul lato servizio di Azure prima dell'impostazione degli endpoint di servizio sul lato rete può aiutare a evitare la perdita di connettività.

Tutti i servizi di Azure si trovano nella rete virtuale di Azure fornita dal cliente? Come funzionano gli endpoint di servizio di rete virtuale con i servizi di Azure?

No, non tutti i servizi di Azure si trovano nella rete virtuale del cliente. La maggior parte dei servizi dati di Azure, ad esempio Archiviazione di Azure, Azure SQL e Azure Cosmos DB, sono servizi multi-tenant a cui è possibile accedere tramite indirizzi IP pubblici. Per altre informazioni sull'integrazione della rete virtuale per i servizi di Azure, vedere qui.

Quando si usa la funzionalità di endpoint di servizio di rete virtuale (attivando l'endpoint di servizio di rete virtuale sul lato rete e configurando elenchi di controllo di accesso di rete virtuale appropriati sul lato servizio di Azure), l'accesso a un servizio di Azure è consentito solo da una rete virtuale e una subnet consentite.

In che modo gli endpoint di servizio di rete virtuale forniscono la sicurezza?

La funzionalità endpoint servizio di rete virtuale (attivazione dell'endpoint servizio di rete virtuale sul lato rete e configurazione degli ACL di rete virtuale appropriati sul lato servizio di Azure) limita l'accesso del servizio di Azure alla rete virtuale e alla subnet consentite, fornendo così una sicurezza a livello di rete e l'isolamento del traffico del servizio di Azure. Tutto il traffico che usa gli endpoint di servizio di rete virtuale transita attraverso il backbone Microsoft, fornendo così un altro livello di isolamento dalla rete Internet pubblica. Inoltre, i clienti possono scegliere di rimuovere completamente l'accesso a Internet pubblico dalle risorse dei servizi di Azure e di consentire il traffico solo dalla propria rete virtuale tramite una combinazione di firewall IP ed elenchi di controllo di accesso di rete virtuale, proteggendo così le risorse dei servizi di Azure dall'accesso non autorizzato.

Che cosa viene protetto dall'endpoint di servizio di rete virtuale, le risorse di rete virtuale o il servizio di Azure?

Gli endpoint di servizio di rete virtuale consentono di proteggere le risorse dei servizi di Azure. Le risorse di rete virtuale vengono protette tramite gruppi di sicurezza di rete (NSG, Network Security Group).

Sono previsti costi per l'uso di endpoint di servizio di rete virtuale?

No, non sono previsti costi aggiuntivi per l'uso di endpoint di servizio di rete virtuale.

È possibile attivare gli endpoint di servizio di rete virtuale e configurare elenchi di controllo di accesso di rete virtuale se la rete virtuale e le risorse dei servizi di Azure fanno parte di sottoscrizioni diverse?

Sì, è possibile. Le reti virtuali e le risorse dei servizi di Azure possono trovarsi nella stessa sottoscrizione o in sottoscrizioni diverse. L'unico requisito è che sia la rete virtuale che le risorse dei servizi di Azure si trovino nello stesso tenant di Active Directory (AD).

È possibile attivare gli endpoint di servizio di rete virtuale e configurare elenchi di controllo di accesso di rete virtuale se la rete virtuale e le risorse dei servizi di Azure fanno parte di tenant di AD diversi?

Sì, è possibile usare gli endpoint di servizio per Archiviazione di Azure e Azure Key Vault. Per i servizi rimanenti, gli endpoint servizio di rete virtuale e gli ACL di rete virtuale non sono supportati nei tenant di Active Directory.

Un indirizzo IP di un dispositivo locale connesso tramite il gateway di Rete virtuale di Azure o il gateway ExpressRoute può accedere al servizio PaaS di Azure tramite gli endpoint servizio di rete virtuale?

per impostazione predefinita, le risorse del servizio associate alle reti virtuali non sono raggiungibili da reti locali. Se si vuole consentire il traffico dall'ambiente locale, è necessario autorizzare anche gli indirizzi IP pubblici (generalmente NAT) dall'ambiente locale o da ExpressRoute. Questi indirizzi IP possono essere aggiunti tramite la configurazione del firewall IP per le risorse dei servizi di Azure.

È possibile usare la funzionalità endpoint servizio di rete virtuale per proteggere il servizio di Azure in più subnet all'interno di una rete virtuale o tra più reti virtuali?

Per proteggere i servizi di Azure in più subnet all'interno di una rete virtuale o tra più reti virtuali, abilitare gli endpoint di servizio sul lato rete su ognuna delle subnet in modo indipendente e quindi proteggere le risorse del servizio di Azure in tutte le subnet configurando gli ACL di rete virtuale appropriati sul lato servizio di Azure.

In che modo è possibile filtrare il traffico in uscita da una rete virtuale verso i servizi di Azure continuando a usare gli endpoint di servizio?

Se si vuole verificare o filtrare il traffico destinato a un servizio di Azure da una rete virtuale, è possibile distribuire un'appliance virtuale di rete nella rete virtuale. È quindi possibile applicare gli endpoint di servizio alla subnet in cui è distribuita l'appliance virtuale di rete e proteggere le risorse del servizio di Azure solo in questa subnet tramite elenchi di controllo di accesso di rete virtuale. Questo scenario può essere utile anche se si vuole limitare l'accesso al servizio di Azure dalla rete virtuale solo a risorse di Azure specifiche, usando il filtro dell'appliance virtuale di rete. Per altre informazioni, vedere il traffico in uscita con le appliance virtuali di rete.

Cosa accade quando si accede a un account del servizio di Azure con un elenco di controllo di accesso alla rete virtuale abilitato dall'esterno della rete virtuale?

Viene restituito l'errore HTTP 403 o HTTP 404.

Le subnet di una rete virtuale create in aree diverse possono accedere a un account del servizio di Azure in un'altra area?

Sì, per la maggior parte dei servizi di Azure, le reti virtuali create in aree diverse possono accedere ai servizi di Azure in un'altra area tramite gli endpoint di servizio di rete virtuale. Se, ad esempio un account di Azure Cosmos DB si trova nell'area Stati Uniti occidentali o Stati Uniti orientali e le reti virtuali si trovano in più aree, la rete virtuale può accedere ad Azure Cosmos DB. I servizi Archiviazione e SQL rappresentano eccezioni e per natura sono legati all'area, quindi sia la rete virtuale che il servizio di Azure devono trovarsi nella stessa area.

Un servizio di Azure può avere sia un ACL di rete virtuale che un firewall IP?

Sì, un ACL di rete virtuale e un firewall IP possono coesistere. Queste due funzionalità si completano reciprocamente per garantire isolamento e sicurezza.

Cosa accade se si elimina una rete virtuale o una subnet con un endpoint di servizio attivato per il servizio di Azure?

L'eliminazione delle reti virtuali e quella delle subnet sono operazioni indipendenti e sono supportate anche quando gli endpoint di servizio sono attivati per i servizi di Azure. Nei casi in cui i servizi di Azure dispongono di ACL di rete virtuale configurati, per tali reti virtuali e subnet, le informazioni ACL di rete virtuale associate a tale servizio di Azure vengono disabilitate quando viene eliminata una rete virtuale o una subnet con endpoint servizio di rete virtuale attivato.

Cosa accade se viene eliminato un account del servizio di Azure con un endpoint servizio di rete virtuale abilitato?

L'eliminazione di un account del servizio di Azure è un'operazione indipendente ed è supportata anche quando l'endpoint di servizio è abilitato sul lato rete e gli ACL della rete virtuale sono configurati sul lato servizio di Azure.

Cosa accade all'indirizzo IP di origine di una risorsa, come una macchina virtuale in una subnet, in cui viene abilitato un endpoint di servizio di rete virtuale?

Quando gli endpoint servizio di rete virtuale vengono abilitati, gli indirizzi IP di origine delle risorse nella subnet della rete virtuale passano dall'usare indirizzi IPV4 pubblici a indirizzi privati della rete virtuale di Azure per il traffico verso il servizio di Azure. Si noti che questo può causare errori di firewall IP specifici impostati sull'indirizzo IPV4 pubblico in precedenza nei servizi di Azure.

La route dell'endpoint di servizio ha sempre la precedenza?

Gli endpoint di servizio aggiungono una route di sistema che ha la precedenza sulle route BGP e fornisce un routing ottimale per il traffico dell'endpoint di servizio. Gli endpoint di servizio instradano sempre il traffico del servizio direttamente dalla rete virtuale al servizio nella rete backbone di Microsoft Azure. Per altre informazioni su come Azure seleziona una route, vedere Routing del traffico di rete virtuale di Azure.

Gli endpoint di servizio funzionano con ICMP?

No, il traffico ICMP originato da una subnet con endpoint di servizio abilitati non porta il percorso del tunnel del servizio all'endpoint desiderato. Gli endpoint di servizio gestiranno solo il traffico TCP. Ciò significa che se si vuole testare la latenza o la connettività a un endpoint tramite endpoint di servizio, gli strumenti come ping e tracert non mostreranno il percorso vero che verranno usate le risorse all'interno della subnet.

Come funziona un gruppo di sicurezza di rete in una subnet con gli endpoint di servizio?

Per raggiungere il servizio di Azure, i gruppi di sicurezza di rete devono consentire la connettività in uscita. Se i gruppi di sicurezza di rete sono aperti a tutto il traffico Internet in uscita, il traffico dell'endpoint di servizio dovrebbe funzionare. È anche possibile limitare il traffico in uscita solo agli IP del servizio che usano i tag del servizio.

Quali autorizzazioni sono necessarie per configurare gli endpoint di servizio?

Gli endpoint di servizio possono essere configurati in una rete virtuale in modo indipendente, da un utente con accesso in scrittura alla rete virtuale. Per proteggere le risorse del servizio di Azure in una rete virtuale, l'utente deve disporre dell'autorizzazione Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action per le subnet da aggiungere. Questa autorizzazione è inclusa nel ruolo di amministratore del servizio predefinito e può essere modificata creando ruoli personalizzati. Altre informazioni sui ruoli predefiniti e sull'assegnazione di autorizzazioni specifiche ai ruoli personalizzati.

È possibile filtrare il traffico di rete virtuale verso i servizi di Azure, consentendo solo risorse specifiche del servizio di Azure, tramite endpoint servizio di rete virtuale?

I criteri degli endpoint di servizio di rete virtuale permettono di filtrare il traffico di rete virtuale verso i servizi di Azure, consentendo l'accesso solo a risorse specifiche dei servizi di Azure tramite gli endpoint di servizio. I criteri degli endpoint forniscono un controllo di accesso granulare per il traffico di rete virtuale verso i servizi di Azure. È possibile ottenere altre informazioni sui criteri degli endpoint di servizio qui.

Azure Active Directory (Azure AD) supporta gli endpoint servizio di rete virtuale?

Azure Active Directory (Azure AD) non supporta gli endpoint di servizio in modo nativo. L'elenco completo dei servizi di Azure che supportano gli endpoint servizio di rete virtuale è disponibile qui. Si noti che il tag "Microsoft.AzureActiveDirectory" elencato nei servizi che supportano gli endpoint di servizio viene usato per supportare gli endpoint di servizio ad ADLS Gen 1. Per ADLS Gen 1, l'integrazione della rete virtuale per Azure Data Lake Storage Gen1 usa la sicurezza degli endpoint servizio di rete virtuale tra la rete virtuale e Azure Active Directory (Azure AD) per generare attestazioni di sicurezza aggiuntive nel token di accesso. Queste attestazioni vengono quindi usate per autenticare la rete virtuale nell'account Data Lake Storage Gen1 e consentire l'accesso. Altre informazioni sull'integrazione della rete virtuale di Azure Data Lake Store Gen1

Ci sono limiti per il numero di endpoint di servizio di rete virtuale che è possibile configurare dalla rete virtuale?

Non ci sono limiti per il numero totale di endpoint di servizio di rete virtuale in una rete virtuale. Per una risorsa del servizio di Azure ,ad esempio un account di archiviazione di Azure, i servizi possono applicare limiti al numero di subnet usate per proteggere la risorsa. La tabella seguente illustra alcuni limiti di esempio:

Servizio di Azure Limiti per le regole della rete virtuale
Archiviazione di Azure 200
SQL di Azure 128
Azure Synapse Analytics 128
Azure Key Vault 200
Azure Cosmos DB 64
Hub eventi di Azure 128
Bus di servizio di Azure 128
Azure Data Lake Store V1 100

Nota

I limiti sono soggetti a modifiche a discrezione del servizio di Azure. Per i dettagli, fare riferimento alla documentazione del servizio interessato.

Eseguire la migrazione delle risorse di rete classiche a Resource Manager

Che cos'è Azure Service Manager e il termine classico?

Azure Service Manager è il modello di distribuzione precedente di Azure responsabile della creazione, della gestione e dell'eliminazione delle risorse. La parola classica in un servizio di rete fa riferimento alle risorse gestite dal modello di Service Manager di Azure. Per altre informazioni, vedere Confronto tra modelli di distribuzione.

Informazioni su Azure Resource Manager

Azure Resource Manager è il modello di distribuzione e gestione più recente in Azure responsabile della creazione, della gestione e dell'eliminazione delle risorse nella sottoscrizione di Azure. Per altre informazioni, vedere Che cos'è Azure Resource Manager?

È possibile ripristinare la migrazione dopo il commit delle risorse in Resource Manager?

È possibile annullare la migrazione purché le risorse siano ancora nello stato preparato. Il rollback al modello di distribuzione precedente non è supportato dopo la migrazione delle risorse tramite l'operazione di commit.

È possibile ripristinare la migrazione se l'operazione di commit non è riuscita?

Non è possibile invertire una migrazione se l'operazione di commit non è riuscita. Tutte le operazioni di migrazione, inclusa l'operazione di commit, non possono essere modificate dopo l'avvio. È consigliabile ripetere l'operazione dopo un breve periodo. Se l'operazione continua a non riuscire, inviare una richiesta di supporto.

È possibile convalidare la sottoscrizione o le risorse per verificare se sono idonee per la migrazione?

Sì. Come parte della procedura di migrazione, il primo passaggio della preparazione per la migrazione consiste nel verificare se le risorse sono in grado di eseguire la migrazione. Nel caso in cui l'operazione di convalida non riesca, si riceveranno messaggi per tutti i motivi per cui non è possibile completare la migrazione.

Le risorse di gateway applicazione vengono migrate come parte della migrazione classica a Resource Manager rete virtuale?

gateway applicazione risorse non verranno migrate automaticamente come parte del processo di migrazione della rete virtuale. Se uno è presente nella rete virtuale, la migrazione non avrà esito positivo. Per eseguire la migrazione di una risorsa gateway applicazione a Resource Manager, è necessario rimuovere e ricreare il gateway applicazione al termine della migrazione.

L'Gateway VPN viene eseguita la migrazione come parte della migrazione classica a Resource Manager rete virtuale?

Gateway VPN risorse vengono migrate come parte del processo di migrazione della rete virtuale. La migrazione viene completata una rete virtuale alla volta senza altri requisiti. I passaggi di migrazione corrispondono alla migrazione di una rete virtuale senza un gateway VPN.

Esiste un'interruzione del servizio associata alla migrazione di gateway VPN classici a Resource Manager?

Non si verifica alcuna interruzione del servizio con la connessione VPN durante la migrazione a Resource Manager. Pertanto, i carichi di lavoro esistenti continueranno a funzionare senza perdita di connettività locale durante la migrazione.

È necessario riconfigurare il dispositivo locale dopo la migrazione del Gateway VPN a Resource Manager?

L'indirizzo IP pubblico associato al gateway VPN rimarrà invariato anche dopo la migrazione. Non è necessario riconfigurare il router locale.

Quali sono gli scenari supportati per la migrazione classica Gateway VPN a Resource Manager?

La maggior parte degli scenari comuni di connettività VPN è coperta dal modello classico per Resource Manager migrazione. Gli scenari supportati includono:

  • Connettività da punto a sito

  • Connettività da sito a sito con un Gateway VPN connesso a una posizione locale

  • Connettività da rete virtuale a rete virtuale tra due reti virtuali tramite gateway VPN

  • Più reti virtuali connesse alla stessa posizione locale

  • Connessione multisito

  • Reti virtuali abilitate per il tunneling forzato

Quali scenari non sono supportati per la migrazione classica di Gateway VPN a Resource Manager?

Gli scenari non supportati includono:

  • La rete virtuale con un gateway ExpressRoute e un Gateway VPN non è attualmente supportata.

  • Rete virtuale con un gateway ExpressRoute connesso a un circuito in una sottoscrizione diversa.

  • Scenari di transito in cui le estensioni di VM sono connesse ai server locali.

Dove è possibile trovare altre informazioni sulla migrazione da classica ad Azure Resource Manager?

Per altre informazioni, vedere Domande frequenti sulla migrazione da classica ad Azure Resource Manager.

Come è possibile segnalare un problema?

È possibile pubblicare le domande sui problemi di migrazione nella pagina Q A di Microsoft&. È consigliabile pubblicare tutte le domande in questo forum. Se si dispone di un contratto di supporto, è anche possibile inviare una richiesta di supporto.