Domande frequenti sulla rete virtuale di Azure
Nozioni di base
Che cos'è una rete virtuale?
Una rete virtuale è una rappresentazione della propria rete nel cloud, come fornito dal servizio Rete virtuale di Azure. Una rete virtuale è un isolamento logico del cloud di Azure dedicato alla sottoscrizione.
È possibile usare reti virtuali per effettuare il provisioning e gestire reti private virtuali (VPN) in Azure. Facoltativamente, è possibile collegare 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 un proprio blocco CIDR. È possibile collegare una rete virtuale 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, insieme alla segmentazione della rete virtuale in subnet.
Usare le reti virtuali per:
Creare una rete virtuale privata dedicata solo cloud. Per una soluzione personalizzata, non è sempre necessaria una configurazione cross-premise. Quando si crea una rete virtuale, i servizi e le VM (VM) all'interno della rete virtuale possono comunicare tra loro direttamente e in modo sicuro nel cloud. È possibile configurare connessioni endpoint per le macchine virtuali e i servizi che richiedono comunicazione Internet come parte della soluzione.
Estendere in modo sicuro il data center. Con la rete virtuale, è possibile creare reti VPN da sito a sito (S2S) tradizionali per scalare in modo sicuro la 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. È possibile connettere applicazioni basate sul cloud in modo sicuro a qualsiasi tipo di sistema locale, come mainframe e sistemi Unix.
Come posso iniziare a utilizzare il prodotto?
Per iniziare, vedere l'articolo Documentazione sulla Rete virtuale di Azure. Tale contenuto fornisce una panoramica e informazioni sulla distribuzione per tutte le funzionalità di rete virtuale.
È possibile usare la rete virtuale senza la connettività tra più sedi locali?
Sì. È possibile usare una rete virtuale senza connetterla all'ambiente locale. Ad esempio, è possibile eseguire controller di dominio Active Directory di Microsoft 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 virtuale di rete per l'ottimizzazione WAN di diversi fornitori tramite Azure Marketplace.
Impostazione
Quali sono gli strumenti da usare per creare una rete virtuale?
Per creare o configurare una rete virtuale, è possibile usare gli strumenti seguenti:
- Azure portal
- PowerShell
- Interfaccia della riga di comando di Azure
- File di configurazione di rete (
netcfg
, solo per reti virtuali classiche)
Quali intervalli di indirizzi è possibile usare nelle reti virtuali?
È consigliabile usare gli intervalli di indirizzi seguenti, enumerati in RFC 1918. IETF ha messo da parte questi intervalli per gli spazi indirizzi privati e non instradabili.
- Da 10.0.0.0 a 10.255.255.255 (prefisso 10/8)
- Da 172.16.0.0 a 172.31.255.255 (prefisso 172.16/12)
- Da 192.168.0.0 a 192.168.255.255 (prefisso 192.168/16)
È anche possibile distribuire lo spazio indirizzi condiviso riservato in RFC 6598, che viene considerato come uno spazio indirizzi IP privato in Azure:
- Da 100.64.0.0 a 100.127.255.255 (prefisso 100.64/10)
Altri spazi di indirizzi, inclusi tutti gli altri spazi indirizzi privati non instradabili riconosciuti da IETF, potrebbero funzionare ma 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 link)
- 168.63.129.16/32 (DNS interno)
È possibile disporre di 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ì. Per informazioni dettagliate, vedere Limiti di networking. 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 indirizzi e l'ultimo indirizzo, per un totale di cinque 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 eseguire il mapping degli indirizzi IP DNS di Azure allo spazio di rete virtuale.
- 192.168.1.255: indirizzo di trasmissione di rete.
Quali sono le dimensioni minime e massime consentite per 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 reti VLAN in Azure usando le 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 Route personalizzate.
Qual è il comportamento quando si applicano un NSG e una route definita dall'utente nella subnet?
Per il traffico in ingresso, vengono elaborate le regole in ingresso del gruppo di sicurezza di rete (NSG). Per il traffico in uscita, le regole in uscita dell’NSG vengono elaborate, seguite da regole UDR (User Defined Route).
Qual è il comportamento quando si applica un NSG a una NIC e a una subnet per una VM?
Quando si applicano NSG sia a una scheda di rete (NIC) che a una subnet per una macchina virtuale:
- Un NSG a livello di subnet, seguito da un NSG a livello di NIC, viene elaborato per il traffico in ingresso.
- Un NSG a livello di NIC, seguito da un NSG a livello di subnet, viene elaborato per il traffico in uscita.
Le reti virtual supportano il traffico multicast o broadcast?
No. La distribuzione multicast o broadcast non è supportata.
Quali protocolli è possibile usare nelle reti virtuali?
È possibile usare protocolli TCP, UDP, ESP, AH e ICMP TCP/IP nelle reti virtuali.
Unicast è supportato nelle reti virtuali. I pacchetti incapsulati IP in IP, multicast e broadcast e i pacchetti Generic Routing Encapsulation (GRE) sono bloccati nelle reti virtuali. Non è possibile usare Dynamic Host Configuration Protocol (DHCP) tramite Unicast (porta di origine UDP/68, porta di destinazione UDP/67). La porta di origine UDP 65330 è riservata all'Host.
È possibile distribuire un server DHCP in una rete virtuale?
Le reti virtuali di Azure forniscono servizi DHCP e DNS alle macchine virtuali di Azure. Tuttavia, è anche possibile distribuire un server DHCP in una VM di Azure per gestire i client locali tramite un agente di inoltro DHCP.
Il server DHCP in Azure è stato contrassegnato in precedenza come non accettabile perché la velocità del traffico verso la porta UDP/67 era limitata in Azure. Tuttavia, gli aggiornamenti recenti della piattaforma hanno rimosso la limitazione della frequenza, abilitando questa funzionalità.
Nota
Il client locale al server DHCP (porta di origine UDP/68, porta di destinazione UDP/67) non è ancora supportato in Azure, poiché questo traffico viene intercettato e gestito in modo differente. Ciò genera messaggi di timeout al momento del RINNOVO DHCP in T1 quando il client tenta di raggiungere direttamente il server DHCP in Azure. Il RINNOVO DHCP avrà esito positivo quando tale tentativo viene effettuato in T2 tramite l'agente di inoltro DHCP. Per altri dettagli sui timer T1 e T2 DHCP RENEW, vedere RFC 2131.
È possibile effettuare il ping di un gateway predefinito in una rete virtuale?
No. Un gateway predefinito fornito da Azure non risponde a un ping. È tuttavia possibile usare i ping nelle reti virtuali per verificare la connettività e la risoluzione dei problemi tra le VM.
È possibile usare tracert per diagnosticare la connettività?
Sì.
È possibile aggiungere subnet dopo la creazione della rete virtuale?
Sì. È possibile aggiungere subnet alle reti virtuali in qualsiasi momento, purché esistano entrambe le condizioni seguenti:
- L'intervallo di indirizzi della subnet non fa parte di un'altra subnet.
- È disponibile spazio 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 vengono distribuite VM o servizi.
È possibile modificare una rete virtuale dopo averlo creato?
Sì. È possibile aggiungere, rimuovere e modificare i blocchi CIDR usati da una rete virtuale.
È possibile connettersi a Internet se si stanno eseguendo i servizi in una rete virtuale?
Sì. Tutti i servizi distribuiti in una rete virtuale possono connettersi in uscita a Internet. Per altre informazioni sulle connessioni Internet in uscita in Azure, vedere Usare SNAT (Source Network Address Translation) per le connessioni in uscita.
Se si desidera effettuare la connessione in ingresso a una risorsa distribuita tramite Azure Resource Manager, la risorsa deve avere un indirizzo IP pubblico assegnato. Per altre informazioni, vedere Creare, modificare o eliminare un indirizzo IP pubblico di Azure.
A ciascun servizio cloud distribuito in Azure viene assegnato un indirizzo IP virtuale (VIP) indirizzabile pubblicamente. Per abilitare tali servizi in modo che accettino le connessioni da Internet, è necessario definire gli endpoint di input per la piattaforma distribuita come servizio (PaaS) per i ruoli PaaS e gli endpoint per le macchine virtuali.
IPv6 è supportato dalle reti virtuali?
Sì. Le reti virtuali possono essere solo IPv4 o dual stack (IPv4+IPv6). Per informazioni dettagliate, vedere Che cos'è IPv6 per la Rete virtuale di Azure?.
È possibile estendere una rete virtuale in più regioni?
No. Una rete virtuale è limitata a una singola regione. Tuttavia, una rete virtuale si estende su zone di disponibilità. Per altre informazioni sulle zone di disponibilità, vedere Che cosa sono le aree di Azure e le zone di disponibilità?.
È possibile connettere reti virtuali in differenti aree con il peering di rete virtuale. Per informazioni dettagliate, vedere Peering di reti virtuali.
Posso connettere una rete virtuale a un'altra rete virtuale in Azure?
Sì. È possibile connettere una rete virtuale a un'altra rete virtuale usando:
- Peering di reti virtuali. Per informazioni dettagliate, vedere Peering di reti virtuali.
- Un Gateway VPN di Azure. Per informazioni dettagliate, vedere Configurare una connessione Gateway VPN da rete a rete.
Risoluzione dei nomi (DSN)
Quali sono le opzioni DNS per le reti virtuali?
Usare la tabella delle decisioni in Risoluzione dei nomi per le risorse nelle reti virtuali di Azure per esaminare le opzioni DNS disponibili.
È possibile specificare server DNS per una rete virtuale?
Sì. È possibile specificare gli indirizzi IP per i server DNS nelle impostazioni della rete virtuale. L'impostazione viene applicata come server DNS predefinito o server per tutte le VM nella rete virtuale.
Quanti server DNS è possibile specificare?
Vedere Limiti relativi alla rete.
È 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 dei server DNS, è necessario eseguire un rinnovo del leasing DHCP in tutte le VM interessate nella rete virtuale. Le nuove impostazioni DNS diventano effettive dopo il rinnovo del leasing. Per le VM che eseguono Windows, è possibile rinnovare il leasing immettendo ipconfig /renew
direttamente nella VM. Per altri tipi di sistema operativo, vedere la documentazione relativa al rinnovo del leasing DHCP.
Cos'è il DNS fornito da Azure? Inoltre, funziona con le reti virtuali?
DNS fornito da Azure è un servizio DNS multi-tenant di 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:
- Per nome host per le VM e le istanze del ruolo nello stesso servizio cloud.
- Per dominio principale completo (FQDN) per le VM e le istanze del ruolo nella stessa rete virtuale.
Per altre informazioni sul DNS, vedere Risoluzione dei nomi per le risorse nelle reti virtuali di Azure.
Esiste una limitazione ai primi 100 servizi cloud in una rete virtuale per la risoluzione dei nomi tra tenant tramite IL DNS fornito da Azure. Se si utilizza il proprio server DNS, questa limitazione non viene applicata.
È possibile eseguire l'override delle impostazioni DNS per ogni VM o servizio cloud?
Sì. È possibile impostare i server DNS per ogni VM o 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 VM in una rete virtuale?
Sì. Tutte le schede di rete (NIC) collegate a una VM distribuita tramite il modello di distribuzione Resource Manager devono essere connesse a una rete virtuale. Facoltativamente, è possibile connettere le VM distribuite tramite il modello di distribuzione classica a una rete virtuale.
Quali sono i tipi di indirizzi IP che è possibile assegnare alle VM?
Privato: assegnato a ogni NIC all'interno di ogni VM tramite 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 è differente 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 tramite il metodo dinamico o statico rimane assegnato a una macchina virtuale (Resource Manager) finché la risorsa non viene eliminata. La differenza è che si seleziona l'indirizzo da assegnare quando si usa il metodo statico e Azure sceglie quando si usa il metodo dinamico.
- Classico: un indirizzo IP privato assegnato con il metodo dinamico potrebbe 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 NIC collegate a VM distribuite con il modello di distribuzione Resource Manager. È possibile assegnare l'indirizzo usando il metodo di allocazione statico o dinamico.
Tutte le VM e le istanze del ruolo dei servizi cloud di Azure distribuite tramite il modello di distribuzione classica esistono all'interno di un servizio cloud. Al servizio cloud viene assegnato un indirizzo 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 sono detti indirizzi IP pubblici a livello di istanza e possono essere assegnati in modo dinamico.
È possibile riservare un indirizzo IP privato per una VM che verrà creata in un secondo momento?
No. Non è possibile riservare un indirizzo IP privato. Se è disponibile un indirizzo IP privato, il server DHCP lo assegna a una VM o a un'istanza del ruolo. Indipendentemente dal fatto che la macchina virtuale possa o meno essere quella a cui si desidera assegnare l'indirizzo IP privato. È possibile tuttavia cambiare l'indirizzo IP privato di una VM esistente con qualsiasi indirizzo IP privato disponibile.
Gli indirizzi IP privati vengono modificati per le VM in una rete virtuale?
Dipende. Se la VM è stata distribuita usando Resource Manager, gli indirizzi IP non possono cambiare, indipendentemente dal fatto che gli indirizzi siano stati assegnati usando il metodo di allocazione statico o dinamico. Se la VM è stata distribuita usando il modello di distribuzione classica, gli indirizzi IP dinamici possono cambiare quando si avvia una VM nello stato arrestato (deallocato).
L'indirizzo viene rilasciato da una VM distribuita tramite uno dei modelli di distribuzione quando si elimina la VM.
È 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 Assegnare più indirizzi IP alle macchine virtuali.
Se l'indirizzo IP assegnato a una NIC 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 VM dall'interno del sistema operativo, cosa accade agli indirizzi IP?
Nessuna operazione. Gli indirizzi IP, pubblici, privati o indirizzi VIP pubblici, rimangano assegnati alla relativa VM o allo slot di distribuzione del servizio cloud.
È possibile spostare le VM da una subnet all'altra in una rete virtuale senza ripetere la distribuzione?
Sì. Per altre informazioni, vedere Spostare una macchina virtuale o un'istanza del ruolo in un'altra subnet.
È possibile configurare un indirizzo MAC statico per la macchina virtuale?
No. Non è possibile configurare in modo statico un indirizzo MAC.
L'indirizzo MAC resta invariato per la macchina virtuale dopo averla creata?
Sì. L'indirizzo MAC rimane invariato sia che la VM venga distribuita con il modello di distribuzione classica o Resource Manager, finché non viene eliminata.
In precedenza, l'indirizzo MAC è stato rilasciato se è stata arrestata (deallocata) la VM. Ma ora la macchina virtuale mantiene l'indirizzo MAC quando si trova nello stato deallocato. L'indirizzo MAC rimane assegnato alla scheda di rete fino a quando non si esegue una di queste attività:
- Eliminare la scheda di rete.
- Modificare l'indirizzo IP privato assegnato alla configurazione IP primaria della scheda di rete primaria.
È possibile eseguire la connessione a Internet da una VM in una rete virtuale?
Sì. Tutte le VM 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 alle reti virtuali
È possibile usare app Web con una rete virtuale?
Sì. È possibile distribuire la funzionalità App Web del servizio app di Azure all'interno di una rete virtuale usando un ambiente del servizio app. È quindi possibile:
- Connettere il back-end delle app alle reti virtuali usando l'integrazione della rete virtuale.
- Bloccare il traffico in ingresso all'app usando gli endpoint di servizio.
Per altre informazioni, vedere gli articoli seguenti:
- Funzionalità di rete del servizio app
- Usare un ambiente del servizio app
- Integrare un'app in una rete virtuale di Azure
- Configurare le restrizioni di accesso al Servizio app di Azure
È possibile distribuire i servizi cloud con i ruoli Web e di lavoro (PaaS) in una rete virtuale?
Sì. Facoltativamente, è possibile distribuire istanze del ruolo Servizi cloud nelle 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 Distribuire servizi di Azure dedicati in reti virtuali.
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 alle reti virtuali tramite l'uso di endpoint servizio di rete virtuale o Collegamento privato di Azure. Per informazioni dettagliate, vedere Endpoint servizio di rete virtuale e Informazioni sul collegamento privato di Azure.
È possibile spostare i servizi all'interno e all'esterno delle reti virtuali?
No. Non è possibile spostare i servizi da e verso le reti virtuali. Per spostare una risorsa in un'altra rete virtuale, è necessario eliminarla e ridistribuirla.
Sicurezza
Qual è il modello di sicurezza per le reti virtuali?
Le reti virtuali sono isolate da un'altra rete e da altri servizi 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 a una rete virtuale?
Sì. È possibile applicare gruppi di sicurezza di rete a singole subnet all'interno di una rete virtuale, NIC collegate a una rete virtuale o entrambe.
È possibile implementare un firewall tra le risorse connesse a una rete virtuale?
Sì. È possibile distribuire un'appliance virtuali di rete firewall di diversi fornitori tramite Azure Marketplace.
Sono disponibili informazioni sulla protezione delle reti virtuali?
Sì. Vedere Panoramica della sicurezza di rete di Azure.
Le reti virtuali archiviano i dati dei clienti?
No. Le reti virtuali non archiviano dati dei clienti.
È possibile impostare la proprietà FlowTimeoutInMinutes per un'intera sottoscrizione?
No. È necessario impostare la proprietà FlowTimeoutInMinutes nella rete virtuale. Il codice seguente consente di impostare automaticamente questa proprietà per sottoscrizioni di dimensioni maggiori:
$Allvnet = Get-AzVirtualNetwork
$time = 4 #The value should be 4 to 30 minutes (inclusive) to enable tracking, or null to disable tracking.
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 Azure Resource Manager e classico.
Sono disponibili strumenti di supporto per le reti virtuali?
Sì. Altre informazioni:
- Uso del portale di Azure per distribuire reti virtuali con i modelli di distribuzione Azure Resource Manager e classico.
- PowerShell per gestire le reti virtuali distribuite tramite il modello di distribuzione Resource Manager.
- L'interfaccia della riga di comando di Azure o l'interfaccia della riga di comando classica di Azure per distribuire e gestire le reti virtuali distribuite tramite i modelli di distribuzione Resource Manager e classica.
Peering di rete virtuale
Che cos'è il peering di rete virtuale?
Il peering di reti virtuali consente di connettere le reti virtuali. Usando una connessione di peering è 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 fossero all'interno della stessa rete. Queste reti virtuali possono trovarsi nella stessa area o in aree o differenti (noto anche come peering di reti virtuali globale).
È anche possibile creare connessioni di peering di rete virtuale tra sottoscrizioni di Azure.
È possibile creare una connessione di peering per una rete virtuale in un'area differente?
Sì. Il peering di rete virtuale globale consente di eseguire il peering di reti virtuali in aree differenti. Il peering di rete virtuale globale è disponibile in tutte le aree pubbliche di Azure, nelle aree cloud della Cina e nelle aree cloud per enti pubblici. Non è possibile eseguire il peering globale da aree pubbliche di Azure nelle aree cloud nazionali.
Quali sono i vincoli correlati al peering di rete virtuale globale e ai load balancer?
Se le due reti virtuali in due aree diverse sono sottoposte a peering tramite peering di reti virtuali globali, non sarà possibile connettersi alle risorse dietro un servizio di bilanciamento del carico di base tramite l'indirizzo IP front-end del servizio di bilanciamento del carico. Questa restrizione non esiste per un load balancer standard.
Le risorse seguenti possono usare load balancer di base, il che significa che non è possibile raggiungerli tramite l'IP front-end di un load balancer tramite il peering di rete virtuale globale. Tuttavia, è possibile usare il peering di rete virtuale globale per raggiungere le risorse direttamente tramite gli indirizzi IP della rete virtuale privata, se consentito.
- VM dietro i load balancer di base
- Set di scalabilità di macchine virtuali con load balancer di base
- Cache Redis di Azure
- Gateway applicazione di Azure v1
- Azure Service Fabric
- API di Gestione API di Azure stv1
- Servizi di dominio Microsoft Entra
- App per la logica di azure
- Azure HDInsight
- Azure Batch
- Ambiente del servizio app v1 e v2
È possibile connettersi a queste risorse tramite Azure ExpressRoute o connessioni da rete a rete tramite gateway di rete virtuale.
È possibile abilitare il peering di rete virtuale se le reti virtuali appartengono a sottoscrizioni all'interno di tenant Microsoft Entra differenti?
Sì. È possibile stabilire il peering di rete virtuale (locale o globale) se le sottoscrizioni appartengono a tenant Microsoft Entra differenti. A tale scopo, è possibile usare il portale di Azure, PowerShell o l'interfaccia della riga di comando di Azure.
La connessione peering di rete virtuale è in stato Avviato. Perché non è possibile connettersi?
Se la connessione di peering è in stato Avviato, è stato creato un solo link. Per stabilire una connessione riuscita, è necessario creare un link bidirezionale.
Ad esempio, per eseguire il peering di VNetA a VNetB, è necessario creare un link da VNetA a VNetB e da VNetB a VNetA. La creazione di entrambi i collegamenti modifica lo stato su Connesso.
La connessione peering di rete virtuale è in stato Disconnesso. Perché non è possibile creare una connessione di peering?
Se la connessione peering di rete virtuale si trova in uno stato Disconnesso, uno dei collegamenti creati è stato eliminato. Per ristabilire una connessione di peering, è necessario eliminare il link rimanente e ricreare entrambi.
È possibile eseguire il peering della rete virtuale con una rete virtuale che si trova in una sottoscrizione differente?
Sì. È possibile eseguire il peering di reti virtuali tra sottoscrizioni e aree diverse.
È possibile eseguire il peering di due reti virtuali con intervalli di indirizzi corrispondenti o sovrapposti?
No. Non è possibile abilitare il peering di rete virtuale se gli spazi di indirizzi si sovrappongono.
È possibile eseguire il peering di una rete virtuale a due reti virtuali con l'opzione Usa gateway remoto abilitata in entrambi i peering?
No. È possibile abilitare l'opzione Usa gateway remoto in un solo peering a una delle reti virtuali.
È possibile spostare una rete virtuale con una connessione di peering a un'altra rete virtuale?
No. Non è possibile spostare una rete virtuale con una connessione di peering a un'altra rete virtuale. È necessario eliminare la connessione di peering prima di spostare la rete virtuale.
Quanto costano i collegamenti di peering di rete virtuale?
Non è previsto alcun addebito per la creazione di una connessione peering di rete virtuale. Viene addebitato il trasferimento dei dati tra connessioni peering. Per altre informazioni, vedere la pagina dei prezzi della rete virtuale di Microsoft Azure.
Il traffico di peering di rete virtuale è crittografato?
Quando il traffico di Azure si sposta tra i data center (al di fuori dei limiti fisici non controllati da Microsoft o per conto di Microsoft), la crittografia del data-link layer MACsec viene usata nell'hardware di rete sottostante. Questa crittografia è applicabile al traffico di peering di rete virtuale.
Perché la connessione peering risulta disconnessa?
Le connessioni di peering di rete virtuale passano a uno stato Disconnesso quando viene eliminato un link di peering di 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. È necessario eseguire manualmente il peering di VNetA alla VNet.
Sono presenti limitazioni relative alla larghezza di banda per le connessioni peering?
No. Il peering di reti virtuali, 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 relativi al peering di rete virtuale?
Provare la guida alla risoluzione dei problemi.
TAP di rete virtuale
Quali aree di Azure sono disponibili per la TAP di rete virtuale?
L'anteprima del punto di accesso del terminale di rete virtuale (TAP) è disponibile in tutte le aree di Azure. È necessario distribuire le schede di rete monitorate, la risorsa punto di accesso terminale di rete virtuale e l'agente di raccolta o la soluzione di analisi 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 una scheda di rete, una copia completa di tutto il traffico in ingresso e in uscita nella scheda di rete viene trasmesso alla destinazione TAP.
È possibile aggiungere più configurazioni TAP a una scheda di rete monitorata?
Una scheda di rete monitorata può avere solo una configurazione TAP. Verificare con la singola soluzione partner la possibilità di inviare in streaming più copie del traffico TAP agli strumenti di analisi scelti.
Può la stessa risorsa TAP di rete virtuale aggregare il traffico dalle schede di rete monitorate in più di una rete virtuale?
Sì. È possibile usare la stessa risorsa TAP di rete virtuale per aggregare il traffico con mirroring da schede di rete monitorate in reti virtuali con peering nella stessa sottoscrizione o in una sottoscrizione differente.
La risorsa TAP di rete virtuale e il load balancer di destinazione o la scheda di rete di destinazione devono essere nella stessa sottoscrizione. Tutte le sottoscrizioni devono trovarsi nello stesso tenant di Microsoft Entra.
Ci sono considerazioni sulle prestazioni del traffico di produzione se abilito una configurazione TAP di rete virtuale su una scheda di rete?
Tap di rete virtuale è disponibile in anteprima. Durante l'anteprima, non esiste alcun contratto di servizio. Non è consigliabile usare la funzionalità per i carichi di lavoro di produzione.
Quando si abilita una scheda di rete di una macchina virtuale con una configurazione TAP, le stesse risorse sull'host di Azure assegnate alla macchina virtuale per inviare il traffico di produzione vengono utilizzate 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?
È possibile aggiungere una configurazione TAP in una scheda di rete collegata a una macchina virtuale abilitata con rete accelerata per Linux o Windows. Tuttavia, l'aggiunta della configurazione TAP influirà sulle prestazioni e la latenza nella macchina virtuale perché la rete accelerata di Azure attualmente non supporta l'offload per il traffico di mirroring.
Endpoint servizio di rete virtuale
Qual è la sequenza corretta di operazioni per la configurazione di endpoint di servizio in un servizio di Azure?
Ci sono due passaggi per la protezione di una risorsa di un servizio di Azure tramite gli endpoint di servizio:
- Attivare gli endpoint di servizio per il servizio di Azure.
- Configurare gli elenchi di controllo di accesso alla rete virtuale (ACL) nel servizio di Azure.
Il primo passaggio è un'operazione sul lato rete e il secondo passaggio è un'operazione sul lato risorsa del servizio. Gli stessi amministratori o amministratori differenti possono eseguire i passaggi, in base alle autorizzazioni di controllo degli accessi in base al ruolo (RBAC) di Azure concesse al ruolo di amministratore.
È consigliabile attivare gli endpoint di servizio per la rete virtuale prima di configurare gli ACL di rete virtuale sul lato servizio di Azure. Per configurare gli endpoint servizio di rete virtuale, è necessario eseguire i passaggi nella sequenza precedente.
Nota
È necessario completare entrambe le operazioni precedenti 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. È anche necessario configurare gli ACL 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
, è possibile configurare gli ACL di rete virtuale sul lato servizio di Azure prima di attivare gli endpoint di servizio sul lato rete. I servizi di Azure forniscono questo flag per aiutare i clienti nei casi in cui i firewall IP specifici sono configurati nei servizi di Azure.
L'attivazione degli endpoint di servizio sul lato rete può causare un calo della connettività, perché l’indirizzo IP di origine passa da un indirizzo IPv4 pubblico a un indirizzo privato. La configurazione di ACL di rete virtuale sul lato servizio di Azure prima dell'attivazione degli endpoint di servizio sul lato rete può aiutare a evitare la perdita di connettività.
Nota
Se si abilita l'endpoint di servizio in determinati servizi come "Microsoft.AzureActiveDirectory", è possibile visualizzare le connessioni agli indirizzi IPV6 nei log di accesso. Microsoft usa un intervallo privato IPV6 interno per questo tipo di connessioni.
Tutti i servizi di Azure si trovano nella rete virtuale di Azure fornita dal cliente? Come funziona un endpoint servizio di rete virtuale con i servizi di Azure?
Non tutti i servizi di Azure si trovano nella rete virtuale del cliente. La maggior parte dei servizi dati di Azure (come Archiviazione di Azure, Azure SQL e Azure Cosmos DB), è costituita da servizi multi-tenant a cui è possibile accedere tramite indirizzi IP pubblici. Per altre informazioni, vedere Distribuire servizi di Azure dedicati in reti virtuali.
Quando si attivano gli endpoint servizio di rete virtuale sul lato rete e si configurano gli ACL di rete virtuale appropriati sul lato servizio di Azure, l'accesso a un servizio di Azure è limitato da una rete virtuale e una subnet consentite.
In che modo gli endpoint servizio di rete virtuale garantiscono la sicurezza?
Gli endpoint servizio di rete virtuale limitano l'accesso del servizio di Azure alla rete virtuale e alla subnet consentite. In questo modo, forniscono sicurezza a livello di rete e isolamento del traffico del servizio di Azure.
Tutto il traffico che usa endpoint servizio di rete virtuale passa sul backbone Microsoft per fornire un altro livello di isolamento dalla rete Internet pubblica. I clienti possono anche scegliere di rimuovere completamente l'accesso a Internet pubblico alle risorse del servizio di Azure e consentire il traffico solo dalla rete virtuale tramite una combinazione di ACL di rete virtuale e firewall IP. La rimozione dell'accesso a Internet consente di proteggere le risorse del servizio di Azure dall'accesso non autorizzato.
Cosa protegge l'endpoint servizio di rete virtuale, ovvero risorse di rete virtuale o risorse del 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.
È previsto un costo per l'uso degli endpoint servizio di rete virtuale?
No. Non sono previsti costi aggiuntivi per l'uso degli endpoint servizio di rete virtuale.
È possibile attivare gli endpoint di servizio di rete virtuale e configurare ACL di rete virtuale se la rete virtuale e le risorse dei servizi di Azure fanno parte di sottoscrizioni differenti?
Si, è possibile. Le reti virtuali e le risorse dei servizi di Azure possono trovarsi nella stessa sottoscrizione o in sottoscrizioni differenti. L'unico requisito è che sia la rete virtuale che le risorse dei servizi di Azure si trovino nello stesso tenant di Microsoft Entra.
È possibile attivare gli endpoint servizio di rete virtuale e configurare gli ACL di rete virtuale se la rete virtuale e le risorse del servizio di Azure appartengono a tenant Microsoft Entra differenti?
Sì, è possibile quando si usano gli endpoint di servizio per Archiviazione di Azure e Azure Key Vault. Per altri servizi, gli endpoint servizio di rete virtuale e gli ACL di rete virtuale non sono supportati nei tenant di Microsoft Entra.
Un indirizzo IP di un dispositivo locale connesso tramite un gateway di rete virtuale (VPN) di Azure o il gateway di ExpressRoute può accedere al servizio PaaS di Azure tramite endpoint di servizio di rete virtuale?
per impostazione predefinita, le risorse del servizio associate alle reti virtuali non sono raggiungibili da reti locali. Se si desidera consentire il traffico dall'ambiente locale, è necessario autorizzare anche gli indirizzi IP pubblici (generalmente NAT) dall'ambiente locale o da ExpressRoute. È possibile aggiungere questi indirizzi IP tramite la configurazione del firewall IP per le risorse dei servizi di Azure.
È possibile usare gli endpoint servizio di rete virtuale per proteggere i servizi 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 in ogni subnet in modo indipendente. Proteggere quindi 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 ACL di rete virtuale.
Questo scenario può essere utile anche se si desidera 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 Distribuire NVA a disponibilità elevata.
Cosa accade quando un utente accede a un account del servizio di Azure con un ACL di rete virtuale abilitato dall'esterno della rete virtuale?
Il servizio restituisce un 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 differenti 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.
Archiviazione di Azure e AZURE SQL sono eccezioni e sono di natura regionale. Sia la rete virtuale che il servizio di Azure devono trovarsi nella stessa area.
Un servizio di Azure può avere un ACL di rete virtuale e un firewall IP?
Sì. Un ACL di rete virtuale e un firewall IP possono coesistere. Le funzionalità si completano reciprocamente per contribuire a garantire isolamento e sicurezza.
Cosa accade se si elimina una rete virtuale o una subnet con endpoint di servizio attivato per i servizi di Azure?
L'eliminazione delle reti virtuali e l'eliminazione delle subnet sono operazioni indipendenti. Sono supportati anche quando si attivano gli endpoint di servizio per i servizi di Azure.
Se si configurano gli ACL di rete virtuale per i servizi di Azure, le informazioni ACL associate a tali servizi di Azure vengono disabilitate quando si elimina una rete virtuale o una subnet con endpoint servizio di rete virtuale attivati.
Cosa accade se si elimina un account del servizio di Azure con un endpoint servizio di rete virtuale attivato?
L'eliminazione di un account del servizio di Azure è un'operazione indipendente. È supportato anche se è stato attivato l'endpoint di servizio sul lato rete e si configurano gli ACL di rete virtuale sul lato servizio di Azure.
Cosa accade all'indirizzo IP di origine di una risorsa (ad esempio una macchina virtuale in una subnet) con endpoint servizio di rete virtuale attivati?
Quando si abilitano gli endpoint servizio di rete virtuale, gli indirizzi IP di origine delle risorse nella subnet della rete virtuale passano dall'usare indirizzi IPv4 pubblici a indirizzi IP privati della rete virtuale di Azure per il traffico verso il servizio di Azure. Tale passaggio può causare errori nei firewall IP impostati in precedenza su un indirizzo IPv4 pubblico nei servizi di Azure.
La route degli endpoint di servizio ha sempre la precedenza?
Gli endpoint di servizio aggiungono una route di sistema che ha la precedenza sulle route BGP (Border Gateway Protocol) 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 un percorso, vedere Routing del traffico di rete virtuale.
Gli endpoint di servizio funzionano con ICMP?
No. Il traffico ICMP originato da una subnet con endpoint di servizio abilitati non porterà il percorso del tunnel del servizio all'endpoint desiderato. Gli endpoint di servizio gestiscono solo il traffico TCP. Se si desidera 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 le risorse all'interno della subnet eseguiranno.
Come funzionano gli NSG 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 gli NSG 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 indirizzi IP del servizio usando i tag del servizio.
Quali autorizzazioni sono necessarie per configurare gli endpoint di servizio?
È possibile configurare gli endpoint di servizio in una rete virtuale in modo indipendente se si ha accesso in scrittura a tale rete.
Per proteggere le risorse del servizio di Azure in una rete virtuale, è necessario 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 tramite la creazione di ruoli personalizzati.
Per altre informazioni sui ruoli predefiniti e sull'assegnazione di autorizzazioni specifiche ai ruoli personalizzati, vedere Ruoli personalizzati di Azure.
È possibile filtrare il traffico di rete virtuale verso i servizi di Azure sugli endpoint di servizio?
È possibile usare i criteri degli endpoint di servizio di rete virtuale per 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.
Per ulteriori informazioni, vedere Criteri degli endpoint servizio di rete virtuale per Archiviazione di Azure.
Microsoft Entra ID supporta gli endpoint servizio di rete virtuale?
Microsoft Entra ID non supporta gli endpoint servizio in modo nativo. Per un elenco completo dei servizi di Azure che supportano gli endpoint servizio di rete virtuale, vedere Endpoint servizio di rete virtuale.
In tale elenco, il tag Microsoft.AzureActiveDirectory elencato nei servizi che supportano gli endpoint del servizio viene usato per supportare gli endpoint di servizio in Azure Data Lake Storage Gen1. L'integrazione della rete virtuale per Data Lake Storage Gen1 usa la sicurezza dell'endpoint servizio di rete virtuale tra la rete virtuale dell'utente e Microsoft Entra ID 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.
Ci sono limiti per il numero di endpoint di servizio di rete virtuale che è possibile configurare dalla rete virtuale?
Non viene applicato alcun limite al numero totale di endpoint di servizio in una rete virtuale. Per una risorsa del servizio di Azure, ad esempio un account di Archiviazione di Azure, i servizi potrebbero applicare limiti al numero di subnet usate per la protezione della risorsa. La tabella seguente illustra alcuni limiti di esempio:
Servizio di Azure | Limiti per le regole di rete virtuale |
---|---|
Archiviazione di Azure | 200 |
Azure SQL | 128 |
Azure Synapse Analytics | 128 |
Azure Key Vault | 200 |
Azure Cosmos DB | 64 |
Hub eventi di Azure | 128 |
Bus di servizio di Azure | 128 |
Nota
I limiti sono soggetti a modifiche a discrezione del servizio di Azure. Per i dettagli, fare riferimento alla documentazione del servizio interessato.
Migrazione delle risorse di rete classiche a Resource Manager
Che cos'è Azure Service Manager e che cosa significa il termine "classico"?
Azure Service Manager è il vecchio modello di distribuzione di Azure responsabile della creazione, della gestione e dell'eliminazione delle risorse. La parola classico in un servizio di rete fa riferimento alle risorse gestite dal modello di Azure Service Manager. Per altre informazioni, vedere il confronto dei 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 Cosa è 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 aver eseguito correttamente 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 provare a 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ì. Il primo passaggio per la preparazione della migrazione consiste nel verificare che sia possibile eseguire la migrazione delle risorse. Se la convalida non riesce, si riceveranno messaggi per tutti i motivi per cui non è possibile completare la migrazione.
Le risorse del gateway applicazione vengono migrate come parte della migrazione della rete virtuale dal modello classico a Resource Manager?
Le risorse del gateway applicazione di Azure non vengono migrate automaticamente come parte del processo di migrazione della rete virtuale. Se uno è presente nella rete virtuale, la migrazione non riuscirà. Per eseguire la migrazione di una risorsa del gateway applicazione a Resource Manager, è necessario rimuovere e ricreare l'istanza del gateway applicazione al termine della migrazione.
Le risorse del Gateway VPN vengono migrate come parte della migrazione della rete virtuale dal modello classico a Resource Manager?
Le risorse del Gateway VPN di Azure 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 sono uguali a per la migrazione di una rete virtuale senza un Gateway VPN.
Un'interruzione del servizio è associata alla migrazione di Gateway VPN classici a Resource Manager?
Quando si esegue la migrazione a Resource Manager, non si verifica alcuna interruzione del servizio con la connessione VPN. I carichi di lavoro esistenti continueranno a funzionare con connettività locale completa 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 rimane invariato dopo la migrazione. Non è necessario riconfigurare il router locale.
Quali sono gli scenari supportati per la migrazione del Gateway VPN dal modello classico a Resource Manager?
La migrazione dal modello classico a Resource Manager copre la maggior parte degli scenari comuni di connettività VPN. Gli scenari supportati includono:
Connettività da punto a sito.
Connettività da sito a sito con un Gateway VPN connesso a uno percorso locale.
Connettività da rete a rete tra due reti virtuali che usano Gateway VPN.
Più reti virtuali connesse alla stesso percorso locale.
Connettività a più siti.
Reti virtuali con tunneling forzato abilitato.
Quali scenari non sono supportati per la migrazione del Gateway VPN dal modello classico a Resource Manager?
Gli scenari non supportati includono:
Un rete virtuale con gateway ExpressRoute e un Gateway VPN.
Una rete virtuale con un gateway ExpressRoute connesso a un circuito in una sottoscrizione differente.
Scenari di transito in cui le estensioni di VM sono connesse ai server locali.
Dove è possibile trovare altre informazioni sulla migrazione dal modello classico a Resource Manager?
Come è possibile segnalare un problema?
È possibile pubblicare domande sui problemi di migrazione nella pagina Microsoft Q&A. Ti consigliamo di pubblicare tutte le tue domande su questo forum. Se si dispone di un contratto di supporto, è anche possibile inviare una richiesta di supporto.