Questa pagina è stata utile?
I suggerimenti relativi al contenuto di questa pagina sono importanti. Comunicaceli.
Altri suggerimenti?
1500 caratteri rimanenti
Esporta (0) Stampa
Espandi tutto

Domande frequenti sulla rete virtuale

Aggiornamento: giugno 2015

Informazioni di base sulla rete virtuale

Configurazione della rete virtuale

Connettività tra più sedi locali di reti virtuali (VPN)

Connettività multisito e tra reti virtuali

Rete virtuale e risoluzione dei nomi (DNS)

Rete virtuale e macchine virtuali

Rete virtuale e servizi

Rete virtuale e sicurezza

API, schemi e strumenti

Rete virtuale consente di effettuare il provisioning e la gestione delle reti private virtuali (VPM) in Azure e, facoltativamente, di collegare le VPN all'infrastruttura IT locale per creare soluzioni ibride e per più sedi locali. Con la rete virtuale, gli amministratori IT possono controllare la topologia di rete, inclusa la configurazione di DNS e di intervalli di indirizzi IP.
Per altre informazioni, vedere Panoramica di Rete virtuale.

Usare la rete virtuale per:

  • Creare una rete virtuale privata solo cloud dedicata

    Per questa soluzione 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 tra loro direttamente e in modo sicuro nel cloud. In questo modo il traffico rimane al sicuro all'interno della rete virtuale ma allo stesso tempo è consentita la configurazione di connessioni di endpoint per le macchine virtuali e i servizi che richiedono la comunicazione Internet nell'ambito della soluzione.

  • Estendere in modo sicuro il data center

    Con la rete virtuale, è possibile creare reti VPN da sito a sito tradizionali per scalare in modo sicuro la capacità del data center. Nella rete virtuale viene usato il protocollo IPSEC standard del settore per fornire una connessione protetta tra il gateway VPN aziendale e Azure. Aggiungere il numero di macchine desiderato nel gateway VPN.

  • Abilitare scenari cloud ibridi

    La rete virtuale offre la flessibilità necessaria per supportare una gamma di scenari cloud ibridi. È possibile connettere in modo sicuro le applicazioni basate sul cloud a qualsiasi tipo di sistema locale, ad esempio sistemi UNIX e mainframe.

Per visualizzare una tabella che faciliti la scelta dell'opzione di progettazione di rete più adatta alle proprie esigenze, vedere Panoramica di Rete virtuale.

Nella pagina relativa alle risorse sono disponibili informazioni utili per iniziare. In questa pagina sono presenti collegamenti alle procedure di configurazione comuni e informazioni utili sugli aspetti da tenere in considerazione durante la progettazione della rete virtuale.

La rete virtuale può essere usata con un'ampia gamma di servizi di Azure diversi, ad esempio Servizi cloud (PaaS), Macchine virtuali e App Web. Esistono, tuttavia, alcuni servizi non supportati nella rete virtuale. Controllare il servizio specifico che si desidera usare e verificare che sia compatibile.

Sì. La rete virtuale può essere usata senza la connettività da sito a sito. Ciò risulta particolarmente utile se si desidera eseguire controller di dominio e farm di SharePoint in Azure.

Per creare o configurare una rete virtuale, è possibile:

È possibile usare intervalli di indirizzi IP pubblici e qualsiasi intervallo di indirizzi IP definito in RFC1918.

Non esiste alcun limite per il numero di subnet che si possono usare in una rete virtuale. Tutte le subnet devono essere completamente indipendenti nello spazio degli indirizzi della rete virtuale e non devono sovrapporsi tra loro.

Vengono riservati alcuni indirizzi IP in ogni subnet. Il primo e l'ultimo degli indirizzi IP delle subnet vengono riservati per la conformità al protocollo. Inoltre, vengono riservati pochi altri indirizzi IP per i servizi.

La subnet più piccola supportata è /29 e la più grande è /8 (in base alle definizioni di subnet CIDR). Vengono riservati alcuni indirizzi IP da ogni subnet.

Le reti virtuali sono sovrapposizioni di livello 3. Non è supportata la semantica di livello 2.

No. Non sono supportati criteri di routing personalizzati con le reti virtuali.

No. Non è supportato né il traffico multicast né quello broadcast.

Sono supportati i protocolli basati su IP standard. Tuttavia, vengono bloccati il traffico multicast, il traffico broadcast, i pacchetti incapsulati IP-in-IP e i pacchetti Generic Routing Encapsulation (GRE). Tra i protocolli standard che funzionano sono inclusi:

  • TCP

  • UDP

  • ICMP

No. Non è supportato il ping del gateway predefinito di una subnet.

È possibile aggiungere subnet alle reti virtuali in qualsiasi momento purché l'indirizzo subnet non faccia parte di un'altra subnet nella rete virtuale.

È possibile aggiungere, rimuovere, espandere o compattare una subnet se non sono presenti macchine virtuali o servizi distribuiti al suo interno mediante i cmdlet di PowerShell o il file NETCFG. È inoltre possibile aggiungere, rimuovere, espandere o compattare qualsiasi prefisso purché le subnet che contengono le macchine virtuali o i servizi non vengano interessati dalla modifica.

È possibile modificare gli indirizzi delle subnet purché non siano presenti macchine virtuali o servizi distribuiti al loro interno mediante i cmdlet di PowerShell o il file NETCFG. Non è possibile modificare né eliminare una subnet dopo che sono stati distribuiti in essa servizi o macchine virtuali.

Sì. È possibile connettere a Internet tutti i servizi distribuiti in una rete virtuale. A ogni servizio cloud distribuito in Azure è assegnato un VIP indirizzabile pubblicamente. Sarà necessario definire gli endpoint di input per i ruoli PaaS e gli endpoint per le macchine virtuali per consentire a questi servizi di accettare connessioni da Internet.

No. Non è supportato IPv6 con le reti virtuali.

No. Una rete virtuale è limitata a una singola regione.

Sì. Per creare la comunicazione tra reti virtuali, è possibile usare le API REST o Windows PowerShell. Vedere Configure VNet to VNet Connectivity.

Reti virtuali supporta le seguenti connessioni tra più sedi locali:

  • Site-to-site, per la connessione VPN tramite IPsec (IKE v1 e IKE v2)

  • Point-to-site, per la connessione VPN tramite SSTP (Secure Sockets Tunneling Protocol)

  • ExpressRoute, per la connessione sicura diretta dalla rate WAN, non sulla rete Internet pubblica

Le connessioni da sito a sito consentono di connettere qualsiasi computer locale a qualsiasi macchina virtuale o istanza del ruolo all'interno della rete virtuale, a seconda della configurazione di routing. Questa opzione è ottimale per una connessione cross-premise sempre disponibile ed è adatta per le configurazioni ibride. Si basa su un dispositivo VPN IPSec (dispositivo hardware o software) da distribuire in corrispondenza del perimetro della rete per la connettività. Per creare questo tipo di connessione, è necessario disporre dell'hardware VPN richiesto e di un indirizzo IP IPv4 accessibile pubblicamente.

Le connessioni da punto a sito consentono di connettere un singolo computer a qualsiasi elemento all'interno della rete virtuale. Usa il client VPN di Windows. La configurazione da punto a sito prevede l'installazione di un certificato e di un pacchetto di configurazione client VPN che contiene le impostazioni che consentono al computer di connettersi a qualsiasi macchina virtuale o istanza del ruolo all'interno della rete virtuale. Si tratta di un'ottima opzione quando si desidera connettersi a una rete virtuale ma non ci si trova nella sede locale. È consigliabile anche quando non si dispone dell'hardware VPN o dell'indirizzo IP IPv4 accessibile pubblicamente, entrambi necessari per una connessione da sito a sito.

Nota: È possibile configurare la rete virtuale in modo da usare sia la connettività da punto a sito che la connettività da sito a sito contemporaneamente, purché la connessione da sito a sito venga creata usando un gateway dinamico. Per altre informazioni, vedere Informazioni sulla connettività cross-premise protetta della rete virtuale.

Non è possibile connettersi a più siti tramite Windows PowerShell e le API REST di Azure. Vedere la sezione delle domande frequenti relative alla Connettività multisito e tra reti virtuali.

Abbiamo approvato un set di dispositivi VPN da sito a sito standard in partnership con fornitori di dispositivi. Per un elenco dei dispositivi VPN sicuramente compatibili, i modelli di configurazione corrispondenti e le relative specifiche, fare clic qui. Tutti i dispositivi appartenenti ai gruppi di dispositivi di cui è indicata la compatibilità nota dovrebbero funzionare con Rete virtuale. Per agevolare la configurazione del dispositivo VPN, fare riferimento al modello di configurazione del dispositivo corrispondente al gruppo di dispositivi appropriato.

Se un dispositivo non è elencato tra i dispositivi VPN con compatibilità nota e si desidera usarlo per la connessione VPN, è necessario verificare che soddisfi i requisiti minimi. I dispositivi che soddisfano i requisiti minimi dovrebbero funzionare correttamente con la rete virtuale. Di seguito sono elencati i requisiti minimi dei dispositivi sia per configurazioni di ruote statiche sia per configurazioni di route dinamiche. Per altre informazioni, fare clic qui. Contattare il produttore del dispositivo per assistenza e istruzioni di configurazione.

Sono supportati server RRAS (Routing e Accesso remoto) in Windows Server 2012 per la configurazione da sito a sito per la connettività tra più sedi locali.

Con il gateway dovrebbero funzionare anche altre soluzioni software VPN, purché siano conformi alle implementazioni di IPSec standard del settore. Per istruzioni sulla configurazione e sull'assistenza, contattare il fornitore del software.

Sono supportati i sistemi operativi seguenti:

  • Windows 7 (solo versione a 64 bit)

  • Windows Server 2008 R2

  • Windows 8 (solo versione a 64 bit)

  • Windows Server 2012

No. L'assistenza è limitata solo alle versioni dei sistemi operativi Windows elencati in precedenza.

Sono supportati fino a 128 client VPN da poter connettere a una rete virtuale.

Attualmente, sono supportati solo i certificati radice autofirmati.

Sì. Viene usato SSTP (Secure Sockets Tunneling Protocol) per effettuare il tunneling tramite firewall. Questo tunnel verrà visualizzato come connessione HTTPs.

Per impostazione predefinita, tramite il computer client non verrà ristabilita automaticamente la connessione VPN.

La riconnessione automatica e il DNS dinamico non sono supportati attualmente nelle VPN da punto a sito.

Sì. Funzionano entrambe le soluzioni se si dispone di un gateway VPN con routing dinamico per la rete virtuale. Non sono supportate configurazioni da punto a sito in gateway VPN con routing statico.

Sì, è possibile. Ma i prefissi IP delle reti virtuali non devono essere sovrapposti e gli spazi degli indirizzi da punto a sito non devono sovrapporsi tra le reti virtuali.

È difficile determinare esattamente la velocità effettiva tramite i tunnel VPN. IPSec e SSTP sono protocolli VPN con un elevato livello di crittografia. La velocità effettiva è limitata inoltre dalla latenza e dalla larghezza di banda tra le sedi locali e Internet.

Le VPN con routing statico sono anche denominate VPN basate su criteri. Le VPN basate su criteri crittografano e reindirizzano i pacchetti tramite un'interfaccia basata su criteri definiti dal cliente. I criteri vengono in genere definiti come elenco di accesso.

Le VPN con routing dinamico sono anche denominate VPN basate su route. Le VPN basate su route dipendono da un'interfaccia tunnel creata appositamente per l'inoltro di pacchetti. Qualsiasi pacchetto in arrivo nell'interfaccia tunnel verrà inoltrato tramite la connessione VPN.

No. È necessario prima creare il gateway per ottenere l'indirizzo IP. L'indirizzo IP verrà modificato se si elimina e si ricrea il gateway VPN.

Viene generata una chiave già condivisa (PSK) quando viene creato il gateway VPN. Questa chiave deve essere usata per l'autenticazione. La PSK può essere rigenerata in qualsiasi momento e la relativa lunghezza può essere modificata in base alle esigenze.

Sì, è possibile usare l'API di impostazione della chiave precondivisa e il cmdlet di PowerShell per configurare sia la VPN con routing statico che le VPN con routing dinamico di Azure.

Si è limitati all'uso di chiavi già condivise per l'autenticazione.

È disponibile un servizio gateway che viene eseguito per abilitare la connettività tra più sedi locali. Sono necessari 2 indirizzi IP dal dominio di routing per abilitare il routing tra le sedi locali e il cloud. All'utente viene richiesto di specificare almeno una subnet /29 da cui sia possibile selezionare gli indirizzi IP per la configurazione delle route.

Tenere presente che non è necessario distribuire le macchine virtuali o le istanze del ruolo nella subnet del gateway.

Aggiungere tutti gli intervalli che si desidera inviare tramite il gateway per la rete virtuale nella pagina Reti in Reti locali.

No. Non è supportata la configurazione di route. Sarà necessario usare il gateway della rete virtuale per la connettività tra più sedi locali.

Sì, è protetto mediante la crittografia IPsec/IKE.

Al massimo 10 in combinazione. Ad esempio, una rete virtuale di Azure può connettersi a 6 siti locali e 4 reti virtuali.

Sì, è possibile usare VPN da punto a sito con i gateway VPN che si connettono a più siti locali e altre reti virtuali

No, non sono supportati i tunnel ridondanti tra una rete virtuale di Azure e un sito locale.

No, in presenza di spazi degli indirizzi sovrapposti, il caricamento di NETCFG o la creazione della rete virtuale ha esito negativo.

No, tutti i tunnel VPN, incluse le VPN da punto a sito, condividono lo stesso gateway VPN di Azure e la larghezza di banda disponibile.

Il traffico in transito tramite gateway VPN di Azure è possibile, ma si basa su spazi di indirizzi definiti in modo statico nel file di configurazione NETCFG. Il protocollo BGP non è ancora supportato con le reti virtuali di Azure e i gateway VPN. Senza BGP, la definizione manuale degli spazi di indirizzi in transito in NETCFG è soggetta a errori e non è consigliata.

Sì. Non esistono vincoli di regione. Una rete virtuale può connettersi a un'altra rete virtuale nella stessa regione o in un'altra area di Azure.

No, per impostazione predefinita vengono generate chiavi precondivise diverse per connessioni VPN diverse. È tuttavia possibile usare la nuova API REST di impostazione della chiave gateway VPN o il cmdlet di PowerShell per impostare il valore di chiave che si preferisce. La chiave DEVE essere una stringa alfanumerica di lunghezza compresa tra 1 e 128 caratteri.

In Azure viene addebitato un costo solo il traffico che passa da un'area di Azure a un'altra. L'addebito per il traffico si basa sulla stessa tariffa applicata per il traffico dei dati in uscita indicata nella pagina dei prezzi di Azure.

Sì. È possibile specificare gli indirizzi IP per server DNS nella definizione della rete virtuale. Questi verranno applicati come server DNS predefiniti per tutte le macchine virtuali nella rete virtuale.

È possibile specificare fino a 12 server DNS.

Sì. È possibile modificare l'elenco dei server DNS per la rete virtuale in qualsiasi momento. Se si modifica l'elenco dei server DNS, sarà necessario riavviare tutte le macchine virtuali nella rete virtuale affinché sia possibile selezionare il relativo nuovo server DNS.

Usare la tabella decisioni nella pagina Azure Name Resolution per visualizzare tutte le opzioni DNS disponibili.

Il DNS fornito da Azure è un servizio DNS multi-tenant offerto da Microsoft. Tutte le macchine virtuali vengono registrate in questo servizio, che fornisce la risoluzione dei nomi in base al nome host per le macchine virtuali all'interno dello stesso servizio cloud e in base al nome di dominio completo per le macchine virtuali nella stessa rete virtuale. Nota: attualmente esiste una limitazione ai primi 100 servizi cloud nella rete virtuale relativa alla risoluzione dei nomi tra tenant mediante il DNS fornito da Azure. Se si usa un server DNS di proprietà, questa restrizione non si applica.

Sì. È possibile impostare i server DNS in base al singolo servizio cloud per ignorare le impostazioni di rete predefinite. Tuttavia, si consiglia di usare il più possibile il DNS a livello di rete.

No. Non è supportata la possibilità di specificare un suffisso DNS personalizzato per le reti virtuali.

Sono supportate tutte le distribuzioni Linux supportate da Azure.

  • Un indirizzo IP interno (DIP) è un indirizzo IP assegnato a ogni macchina virtuale da DHCP. Non è pubblico. Se è stata creata una rete virtuale, l'indirizzo IP interno viene assegnato dall'intervallo specificato. Se non si dispone di una rete virtuale, verrà comunque assegnato un indirizzo IP interno. L'indirizzo IP interno rimarrà assegnato alla macchina virtuale per la relativa durata, a meno questa non venga arrestata (deallocata).

  • Un VIP pubblico è l'indirizzo IP pubblico assegnato al servizio cloud. Non viene assegnato direttamente alla scheda di interfaccia di rete (NIC) della macchina virtuale. Il VIP rimane assegnato al servizio cloud fino a quando tutte le macchine virtuali in questo servizio non sono arrestate (deallocate) o eliminate. A questo punto, viene rilasciato.

  • DIP: se viene distribuita in una rete virtuale, alla macchina virtuale viene assegnato sempre un indirizzo IP interno (DIP) da un pool di indirizzi IP interni specificato. Le macchine virtuali comunicano all'interno della rete virtuale usando i DIP. Sebbene il DIP venga assegnato da Azure, è possibile richiedere un DIP statico per la propria macchina virtuale se quest'ultima viene distribuita usando PowerShell. Vedere Configure a Static Internal IP Address (DIP) for a VM.

  • VIP: la macchina virtuale è associata anche a un indirizzo VIP, che tuttavia non viene mai assegnato direttamente alla macchina virtuale. Un VIP è un indirizzo IP pubblico che può essere assegnato al servizio cloud. Se lo si desidera, è possibile riservare un VIP per il servizio cloud. Vedere Virtual IP Address (VIP) Reservation.

  • PIP: se lo si desidera, la macchina virtuale può anche ricevere un indirizzo IP pubblico (PIP) a livello di istanza. Il PIP è associato direttamente alla macchina virtuale anziché al servizio cloud. PIP è attualmente in anteprima. Vedere Instance-level Public IP Addresses.

Azure userà DHCP per assegnare un indirizzo IP interno a ciascuna macchina virtuale e istanza PaaS dalla subnet specificata.

Sì. Per specificare il DIP, è necessario creare la macchina virtuale usando i cmdlet di PowerShell. Esistono cmdlet che consentono di specificare il DIP che verrà ricevuto dalla macchina virtuale. È necessario verificare che il DIP specificato non sia usato da un'altra macchina virtuale o da un altro servizio nella rete virtuale. Una volta specificato, il DIP rimarrà associato alla macchina virtuale per tutta la sua durata, anche se questa viene arrestata (deallocata). Se la macchina virtuale viene riavviata dopo essere stata arrestata (deallocata), userà il DIP specificato in precedenza. Non è necessario specificare il DIP per una macchina virtuale, a meno che tale funzionalità non sia necessaria.

No. Non è possibile riservare un DIP. Se un DIP è disponibile, può essere assegnato a una macchina virtuale dal server DHCP. Tale macchina virtuale potrebbe non essere la stessa a cui si desidera assegnare il DIP. È tuttavia possibile sostituire il DIP di una macchina virtuale già creata con un indirizzo disponibile usando PowerShell. Quando il DIP desiderato diventa disponibile nel sistema, è possibile specificarlo al momento della creazione della nuova macchina virtuale. È inoltre possibile rilasciare un DIP da una macchina virtuale usando PowerShell. Se si rilascia un DIP, alla macchina virtuale ne verrà assegnato uno nuovo.

Gli indirizzi IP interni rimarranno assegnati alla macchina virtuale per la relativa durata, a meno che questa non venga arrestata (deallocata). Quando una macchina virtuale viene arrestata (deallocata), l'indirizzo IP interno viene rilasciato a meno che non sia stato definito un DIP statico usando PowerShell. Se la macchina virtuale viene semplicemente arrestata e non è in stato di arresto (deallocazione), il relativo indirizzo IP rimane assegnato.

No. Le proprietà delle interfacce delle macchine virtuali non devono essere modificate. Eventuali modifiche possono provocare una potenziale perdita di connettività alla macchina virtuale.

Nessuno. Gli indirizzi IP (sia il VIP pubblico sia il DIP interno) rimarranno associati al servizio cloud o alla macchina virtuale. Nota: se si desidera semplicemente arrestare la macchina virtuale, non usare il portale di gestione. Attualmente, se si seleziona il pulsante di arresto la macchina virtuale viene arrestata (deallocata).

Lo stato di arresto (deallocazione) può essere specificato nel portale di gestione selezionando l'arresto della macchina virtuale. È diverso dal semplice arresto di una macchina virtuale dall'interno della macchina stessa. Quando si esegue l'arresto (deallocazione) di una macchina virtuale, non si arresta solo la macchina virtuale, ma si specifica di rilasciare anche l'indirizzo IP interno, nonché l'indirizzo VIP pubblico, purché il VIP pubblico non sia usato da altre macchine virtuali, dato che il VIP viene assegnato al servizio cloud e non direttamente alla macchina virtuale. Quando la macchina virtuale viene riallocata, è necessario selezionare un nuovo VIP pubblico, se la macchina virtuale non appartiene a un servizio cloud che già ne dispone di uno, e un nuovo indirizzo IP interno.

L'unico modo per mantenere il DIP di una macchina virtuale anche durante lo stato di arresto (deallocazione) consiste nel definire un indirizzo IP statico per quella macchina virtuale. Se si deve eseguire l'arresto (deallocazione) della macchina virtuale, ma si desidera mantenere il DIP originale, è possibile specificarlo al momento della ridistribuzione della macchina virtuale usando PowerShell, purché il DIP non sia stato già assegnato a un'altra macchina virtuale nella rete virtuale.

Sì. A tale scopo, è possibile usare PowerShell. Per altre informazioni, fare clic qui.

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

No. L'indirizzo MAC di una macchina virtuale può cambiare per diverse ragioni. Se lo stato della macchina virtuale è quello di arresto (deallocazione), se si modifica la dimensione della macchina virtuale oppure in caso di correzione del servizio o di manutenzione pianificata del server host, l'indirizzo MAC non viene mantenuto.

Sì. È possibile connettere a Internet tutti i servizi distribuiti in una rete virtuale. Inoltre, a ogni servizio cloud distribuito in Azure è assegnato un VIP indirizzabile pubblicamente. Sarà necessario definire gli endpoint di input per i ruoli PaaS e gli endpoint per le macchine virtuali per consentire a questi servizi di accettare connessioni da Internet.

Entrambe le opzioni sono possibili. Se RDP è abilitato ed è stato creato un endpoint, è possibile connettersi alla macchina virtuale tramite il VIP. In tal caso, specificare il VIP e la porta a cui si desidera connettersi. Sarà necessario configurare la porta sulla macchina virtuale per il traffico. In genere, è possibile salvare le impostazioni per la connessione RDP al computer nel portale di gestione. Le impostazioni conterranno le informazioni necessarie sulla connessione.

Se si dispone di una rete virtuale per cui è configurata la connettività tra più sedi locali, è possibile connettersi alla macchina virtuale usando il DIP interno, ma anche usando il DIP interno di un'altra macchina virtuale presente nella stessa rete virtuale. Non è possibile usare RDP sulla macchina virtuale tramite DIP se si esegue la connessione da una posizione esterna alla rete virtuale. Se ad esempio è configurata una rete virtuale da punto a sito e non si stabilisce una connessione dal computer, non è possibile connettersi alla macchina virtuale tramite DIP.

No. Attraverso il gateway della rete virtuale passerà solo il traffico con un IP di destinazione incluso negli intervalli di indirizzi IP di rete locale specificati per la rete virtuale. Il traffico che dispone di un IP di destinazione nella rete virtuale rimarrà all'interno della rete stessa. Il restante traffico verrà inviato alle reti pubbliche tramite il bilanciamento del carico. Per la risoluzione dei problemi, è importante assicurarsi che nella rete locale siano elencati tutti gli intervalli da inviare tramite il gateway. Verificare che gli intervalli di indirizzi nella rete locale non si sovrappongano agli intervalli di indirizzi presenti nella rete virtuale. È inoltre necessario verificare che il server DNS in uso risolva il nome nell'indirizzo IP appropriato.

Sono supportati solo i servizi di calcolo nelle reti virtuali. Questi servizi sono limitati ai servizi cloud (ruoli Web e di lavoro) e alle macchine virtuali.

Un sito Web di Azure non può essere distribuito in una rete virtuale. Tuttavia, le app Web possono connettersi e accedere alle risorse in una rete virtuale di Azure se per la rete virtuale è configurata la funzionalità Point-to-Site.
Per altre informazioni, vedere i seguenti articoli:

Integrazione della rete virtuale di app Web

Uso dell'integrazione della rete virtuale e di connessioni ibride con le app Web

Integrazione del sito Web di Azure con una Rete Virtuale di Azure

No. Non sono supportati i database SQL con le reti virtuali.

Sì. È possibile distribuire i servizi PaaS nelle reti virtuali. Questa operazione può essere effettuata senza modificare il codice.

È possibile effettuare questa operazione specificando il nome della rete virtuale e i mapping di ruolo/della subnet nella sezione relativa alla configurazione di rete della configurazione del servizio. Non è necessario aggiornare i file binari.

No. Non è supportata la possibilità di spostare i servizi all'interno e all'esterno delle reti virtuali. Sarà necessario eliminare e ridistribuire il servizio nelle reti virtuali.

Azure usa DHCP per assegnare un indirizzo IP interno a ogni macchina virtuale e un'istanza di PaaS dalla subnet di rete virtuale specificata.

Le reti virtuali sono completamente isolate da un'altra rete e da altri servizi ospitati nell'infrastruttura di Azure. Il limite di attendibilità corrisponde al limite della rete virtuale.

No. Non sono supportati ACL per subnet all'interno delle reti virtuali. Tuttavia, è possibile definirne in endpoint di input per le macchine virtuali che sono state distribuite in una rete virtuale. Nota: non è necessario distribuire una macchina virtuale in una rete virtuale per la definizione di un ACL per l'endpoint di input.

Sì. Sono disponibili API REST per la gestione di reti virtuali e la connettività tra più sedi. Per altre informazioni, fare clic qui.

Sì. Sono disponibili strumenti da riga di comando e di PowerShell per diverse piattaforme. Per altre informazioni, fare clic qui.

Di seguito sono riportate alcune risorse per iniziare:

Vedere anche

Microsoft sta conducendo un sondaggio in linea per comprendere l'opinione degli utenti in merito al sito Web di MSDN. Se si sceglie di partecipare, quando si lascia il sito Web di MSDN verrà visualizzato il sondaggio in linea.

Si desidera partecipare?
Mostra:
© 2015 Microsoft