Domande frequenti sulla rete WAN virtuale
La rete WAN virtuale di Azure è disponibile a livello generale?
Sì, la rete WAN virtuale di Azure è disponibile a livello generale. Tuttavia, la rete WAN virtuale è costituita da diverse funzionalità e diversi scenari. Per alcune funzionalità o alcuni scenari all'interno della rete WAN virtuale, Microsoft applica il tag di anteprima. In questi casi, la funzionalità specifica o lo scenario stesso è disponibile in anteprima. Se non si usa una funzionalità di anteprima specifica, si applica il normale supporto della disponibilità generale. Per altre informazioni sul supporto di anteprima, vedere Condizioni per l'utilizzo supplementari per le anteprime di Microsoft Azure.
Quali località e aree sono disponibili?
Per visualizzare le aree disponibili per la rete WAN virtuale, vedere Prodotti disponibili in base all'area. Specificare WAN virtuale come nome del prodotto.
Per usare la rete WAN virtuale di Azure, è necessario avere un'architettura hub-spoke con dispositivi SD-WAN/VPN?
La rete WAN virtuale offre molte funzionalità integrate in un singolo pannello di controllo, ad esempio connettività VPN sito/da sito a sito, connettività utente/P2S, connettività ExpressRoute, connettività di rete virtuale, interconnettività VPN ExpressRoute, connettività transitiva da rete virtuale a rete virtuale, routing centralizzato, sicurezza di Firewall e Gestione firewall di Azure, monitoraggio, crittografia ExpressRoute e molte altre. Non è necessario che tutti questi casi d'uso inizino a usare la WAN virtuale. È possibile iniziare semplicemente con uno solo.
L'architettura della rete WAN virtuale è di tipo hub-spoke, con scalabilità e prestazioni predefinite in cui i rami (dispositivi VPN/SD-WAN), gli utenti (client VPN di Azure, client openVPN o IKEv2), i circuiti ExpressRoute e le reti virtuali fungono da spoke per uno o più hub virtuali. Tutti gli hub sono connessi in una mesh completa in una rete WAN virtuale standard, per cui è possibile usare il backbone Microsoft per la connettività tra qualsiasi spoke. Gli utenti possono configurare manualmente l'architettura hub-spoke con dispositivi SD-WAN/VPN nel portale della rete WAN virtuale di Azure oppure usare le apparecchiature CPE dei partner di rete WAN virtuale (SD-WAN/VPN) per configurare la connettività con Azure.
I partner di reti WAN virtuali forniscono l'automazione per la connettività, ovvero la possibilità di esportare le informazioni sui dispositivi in Azure, scaricare la configurazione di Azure e stabilire la connettività con l'hub della rete WAN virtuale di Azure. Per la connettività VPN utente/da punto a sito, sono supportati il client VPN di Azure, il client OpenVPN o il client IKEv2.
È possibile disabilitare gli hub completamente connessi in una mesh in una rete WAN virtuale?
La WAN virtuale è disponibile in due versioni: Base e Standard. Nella rete WAN virtuale Base gli hub non sono in mesh. In una rete WAN virtuale Standard, gli hub sono connessi in una mesh e vengono collegati automaticamente quando la rete WAN virtuale viene configurata per la prima volta. L'utente non deve eseguire alcuna operazione specifica. L'utente non deve anche disabilitare o abilitare la funzionalità per ottenere hub con mesh. La rete WAN virtuale offre molte opzioni di routing per indirizzare il traffico tra qualsiasi spoke (rete virtuale, VPN o ExpressRoute). Offre la facilità di hub completamente connessi in una mesh, oltre alla flessibilità di routing del traffico in base alle esigenze.
Come vengono gestite le zone di disponibilità e la resilienza nella rete WAN virtuale?
La rete WAN virtuale è un insieme di hub e servizi resi disponibili all'interno dell'hub. L'utente può avere un numero qualsiasi di reti WAN virtuali in base alle esigenze. In un hub della rete WAN virtuale sono presenti più servizi, ad esempio VPN, ExpressRoute e così via. Ognuno di questi servizi viene distribuito automaticamente in un'area di zone di disponibilità (tranne Firewall di Azure), cioè se l'area supporta le zone di disponibilità. Se un'area diventa una zona di disponibilità dopo la distribuzione iniziale nell'hub, l'utente può ricreare i gateway, il che attiverà una distribuzione nella zona di disponibilità. Il provisioning di tutti i gateway viene eseguito in un hub in modalità attiva-attiva, il che implica una resilienza incorporata all'interno di un hub. Per ottenere resilienza tra aree, gli utenti possono connettersi a più hub.
Attualmente, Firewall di Azure può essere distribuito per supportare le zone di disponibilità usando il portale di Gestione firewall di Azure, PowerShell o l'interfaccia della riga di comando. Attualmente non è possibile configurare un firewall esistente da distribuire tra le zone di disponibilità. Sarà necessario eliminare e ridistribuire Firewall di Azure.
Anche se il concetto di rete WAN virtuale è globale, la risorsa rete WAN virtuale effettiva è basata su Resource Manager e viene distribuita a livello di area. Se nell'area della rete WAN virtuale si verifica un problema, tutti gli hub al suo interno continueranno a funzionare normalmente, ma l'utente non sarà in grado di creare nuovi hub fino a quando l'area della rete WAN virtuale non sarà disponibile.
È possibile condividere il firewall in un hub protetto con altri hub?
No, ogni hub virtuale di Azure deve avere il proprio firewall. La distribuzione di route personalizzate per puntare al firewall di un altro hub protetto avrà esito negativo e non verrà completata correttamente. Prendere in considerazione la possibilità di convertire tali hub in hub protetti con i propri firewall.
Quali client sono supportati dalla VPN utente (da punto a sito) della rete WAN virtuale di Azure?
La rete WAN virtuale supporta il client VPN di Azure, il client OpenVPN o qualsiasi client IKEv2. L'autenticazione Microsoft Entra è supportata con il client VPN di Azure. È necessario almeno il sistema operativo client Windows 10 versione 17763.0 o successiva. I client OpenVPN possono supportare l'autenticazione basata su certificato. Dopo aver selezionato l'autenticazione basata su certificato nel gateway, verrà visualizzato il file the.ovpn* da scaricare nel dispositivo. IKEv2 supporta sia l'autenticazione basata su certificato che RADIUS.
Per la VPN utente (da punto a sito), perché il pool di client P2S è diviso in due route?
Ogni gateway ha due istanze. La divisione serve a fare in modo che ogni istanza del gateway possa allocare in modo indipendente gli IP client per i client connessi e che il traffico dalla rete virtuale venga reinstradato all'istanza corretta per evitare l'hop tra istanze.
Come si possono aggiungere server DNS per i client da punto a sito?
Per aggiungere server DNS per i client da punto a sito, sono disponibili due opzioni. Il primo metodo è preferibile, perché aggiunge i server DNS personalizzati al gateway invece che al client.
Per aggiungere i server DNS personalizzati, usare lo script di PowerShell seguente. Sostituire i valori con quelli del proprio ambiente.
// Define variables $rgName = "testRG1" $virtualHubName = "virtualHub1" $P2SvpnGatewayName = "testP2SVpnGateway1" $vpnClientAddressSpaces = $vpnServerConfiguration1Name = "vpnServerConfig1" $vpnClientAddressSpaces = New-Object string[] 2 $vpnClientAddressSpaces[0] = "192.168.2.0/24" $vpnClientAddressSpaces[1] = "192.168.3.0/24" $customDnsServers = New-Object string[] 2 $customDnsServers[0] = "7.7.7.7" $customDnsServers[1] = "8.8.8.8" $virtualHub = $virtualHub = Get-AzVirtualHub -ResourceGroupName $rgName -Name $virtualHubName $vpnServerConfig1 = Get-AzVpnServerConfiguration -ResourceGroupName $rgName -Name $vpnServerConfiguration1Name // Specify custom dns servers for P2SVpnGateway VirtualHub while creating gateway createdP2SVpnGateway = New-AzP2sVpnGateway -ResourceGroupName $rgname -Name $P2SvpnGatewayName -VirtualHub $virtualHub -VpnGatewayScaleUnit 1 -VpnClientAddressPool $vpnClientAddressSpaces -VpnServerConfiguration $vpnServerConfig1 -CustomDnsServer $customDnsServers // Specify custom dns servers for P2SVpnGateway VirtualHub while updating existing gateway $P2SVpnGateway = Get-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName $updatedP2SVpnGateway = Update-AzP2sVpnGateway -ResourceGroupName $rgName -Name $P2SvpnGatewayName -CustomDnsServer $customDnsServers // Re-generate Vpn profile either from PS/Portal for Vpn clients to have the specified dns serversIn alternativa, se si usa il client VPN di Azure per Windows 10, è possibile modificare il file XML del profilo scaricato e aggiungere i tag <dnsservers><dnsserver></dnsserver></dnsservers> prima di importarlo.
<azvpnprofile> <clientconfig> <dnsservers> <dnsserver>x.x.x.x</dnsserver> <dnsserver>y.y.y.y</dnsserver> </dnsservers> </clientconfig> </azvpnprofile>
Per la VPN utente (da punto a sito), quanti client sono supportati?
La tabella seguente descrive il numero di connessioni simultanee e la velocità effettiva aggregata del gateway VPN da punto a sito supportato in unità di scala diverse.
| Unità di scala | Istanze del gateway | Connessioni simultanee supportate | Velocità effettiva aggregata |
|---|---|---|---|
| 1 | 2 | 500 | 0,5 Gbps |
| 2 | 2 | 500 | 1 Gbps |
| 3 | 2 | 500 | 1,5 Gbps |
| 4 | 2 | 1000 | 2 Gbps |
| 5 | 2 | 1000 | 2,5 Gbps |
| 6 | 2 | 1000 | 3 Gbps |
| 7 | 2 | 5000 | 3,5 Gbps |
| 8 | 2 | 5000 | 4 Gbps |
| 9 | 2 | 5000 | 4,5 Gbps |
| 10 | 2 | 5000 | 5 Gbps |
| 11 | 2 | 10000 | 5,5 Gbps |
| 12 | 2 | 10000 | 6 Gbps |
| 13 | 2 | 10000 | 6,5 Gbps |
| 14 | 2 | 10000 | 7 Gbps |
| 15 | 2 | 10000 | 7,5 Gbps |
| 16 | 2 | 10000 | 8 Gbps |
| 17 | 2 | 10000 | 8,5 Gbps |
| 18 | 2 | 10000 | 9 Gbps |
| 19 | 2 | 10000 | 9,5 Gbps |
| 20 | 2 | 10000 | 10 Gbps |
| 40 | 4 | 20000 | 20 Gbps |
| 60 | 6 | 30000 | 30 Gbps |
| 80 | 8 | 40000 | 40 Gbps |
| 100 | 10 | 50000 | 50 Gbps |
| 120 | 12 | 60000 | 60 Gbps |
| 140 | 14 | 70000 | 70 Gbps |
| 160 | 16 | 80000 | 80 Gbps |
| 180 | 18 | 90000 | 90 Gbps |
| 200 | 20 | 100000 | 100 Gbps |
Si supponga, ad esempio, che l'utente scelga 1 unità di scala. Ogni unità di scala implica la distribuzione di un gateway attivo-attivo e ognuna delle istanze (in questo caso 2) supporta fino a 500 connessioni. Anche se è possibile ottenere 500 * 2 connessioni per ogni gateway, questo non significa che se ne pianificano 1000 invece di 500 per questa unità di scala. Se si supera il numero consigliato di connessioni, possono essere richiesti interventi di manutenzione per le istanze, durante i quali la connettività per le 500 connessioni aggiuntive potrebbe interrompersi.
Per i gateway con unità di scala superiori a 20, vengono distribuite coppie di istanze del gateway a disponibilità elevata aggiuntive per fornire capacità aggiuntiva per la connessione degli utenti. Ogni coppia di istanze supporta fino a 10.000 utenti aggiuntivi. Ad esempio, se si distribuisce un gateway con 100 unità di scala, vengono distribuite 5 coppie di gateway (10 istanze totali) e fino a 50.000 (10.000 utenti x 5 coppie di gateway) che gli utenti simultanei possono connettersi.
Assicurarsi anche di pianificare i tempi di inattività nel caso in cui si decida di aumentare o ridurre l'unità di scala o di cambiare la configurazione da punto a sito nel gateway VPN.
Cosa sono le unità di scala del gateway della rete WAN virtuale?
Un'unità di scala è un'unità definita per selezionare una velocità effettiva aggregata di un gateway nell'hub virtuale. 1 unità di scala della rete VPN = 500 Mbps. 1 unità di scala di ExpressRoute = 2 Gbps. Esempio: 10 unità di scala della rete VPN corrispondono a 500 Mbps * 10 = 5 Gbps
Qual è la differenza tra un gateway di rete virtuale di Azure (gateway VPN) e un gateway VPN di rete WAN virtuale di Azure?
La rete WAN virtuale offre connettività da sito a sito su larga scala ed è ideale per velocità effettiva, scalabilità e semplicità d'uso. La connessione di un sito a un gateway VPN WAN virtuale è diversa da un normale gateway di rete virtuale che usa un gateway di tipo "VPN da sito a sito". Quando si vuole connettere utenti remoti alla rete WAN virtuale, si usa un tipo di gateway "VPN da punto a sito". I gateway VPN da punto a sito e da sito a sito sono entità separate nell'hub della rete WAN virtuale e devono essere distribuite singolarmente. Analogamente, quando si esegue la connessione di un circuito ExpressRoute a un hub WAN virtuale, viene usata una risorsa diversa per il gateway ExpressRoute rispetto al normale gateway di rete virtuale che usa il tipo di gateway "ExpressRoute".
La rete WAN virtuale supporta fino a 20 Gbps di velocità effettiva aggregata sia per VPN che per ExpressRoute. La rete WAN virtuale dispone anche di automazione per la connettività con un ecosistema di partner per dispositivi del ramo CPE. I dispositivi del ramo CPE eseguono includono automazione incorporata per il provisioning automatico e la connessione alla rete WAN virtuale di Azure. Questi dispositivi sono disponibili da un ecosistema di partner VPN e SD-WAN in continua crescita. Vedere l'elenco dei partner preferiti.
In che modo la rete WAN virtuale è diversa dal gateway di rete virtuale di Azure?
Una VPN di gateway di rete virtuale è limitata a 100 tunnel. Per le connessioni, è consigliabile usare la rete WAN virtuale per VPN su larga scala. È possibile eseguire fino a 1.000 connessioni di ramo per ogni hub virtuale con un aggregato di 20 Gbps per hub. Una connessione è un tunnel attivo-attivo dal dispositivo VPN locale all'hub virtuale. È anche possibile avere più hub virtuali per area, il che significa che è possibile connettere più di 1.000 rami a una singola area di Azure distribuendo più hub della rete WAN virtuale in tale area di Azure, ognuno con il proprio gateway VPN da sito a sito.
Qual è l'algoritmo consigliato e i pacchetti al secondo per ogni istanza da sito a sito nell'hub della rete WAN virtuale? Quanti tunnel supportano per ogni istanza? Qual è la velocità effettiva massima supportata in un singolo tunnel?
La rete WAN virtuale supporta 2 istanze del gateway VPN da sito a sito attive in un hub virtuale. Ciò significa che in un hub virtuale sono presenti 2 istanze del gateway VPN attive e attive. Durante le operazioni di manutenzione, ogni istanza viene aggiornata una a una per cui un utente potrebbe riscontrare una breve diminuzione della velocità effettiva aggregata di un gateway VPN.
Mentre la VPN della rete WAN virtuale supporta molti algoritmi, è consigliabile GCMAES256 sia per la crittografia IPSEC che per l'integrità per ottenere prestazioni ottimali. AES256 e SHA256 sono considerati meno efficienti e pertanto è possibile prevedere una riduzione delle prestazioni, ad esempio la latenza e le riduzioni dei pacchetti per tipi di algoritmo simili.
I pacchetti al secondo o PPS sono un fattore del numero totale di pacchetti e della velocità effettiva supportata per ogni istanza. È possibile comprendere meglio questo aspetto con un esempio. Si supponga che un'istanza del gateway VPN da sito a sito a 500 Mbps con unità di scala 1 venga distribuita in un hub della rete WAN virtuale. Supponendo una dimensione di pacchetto pari a 1400, previsto PPS per l'istanza del gateway VPN al massimo = [(500 Mbps * 1024 * 1024) /8/1400] ~ 47000.
La rete WAN virtuale ha concetti di connessione VPN, connessione di collegamento e tunnel. Una singola connessione VPN è costituita da connessioni di collegamento. La rete WAN virtuale supporta fino a 4 connessioni di collegamento in una connessione VPN. Ogni connessione di collegamento è costituita da due tunnel IPsec che terminano in due istanze di un gateway VPN attivo-attivo distribuito in un hub virtuale. Il numero totale di tunnel che possono terminare in una singola istanza attiva è 1000, il che implica anche che la velocità effettiva per 1 istanza sarà disponibile aggregata in tutti i tunnel che si connettono a tale istanza. Ogni tunnel ha anche determinati valori di velocità effettiva. Nei casi di più tunnel connessi a un gateway di unità di scala con valore inferiore, è consigliabile valutare la necessità per tunnel e pianificare un gateway VPN che rappresenta un valore aggregato per la velocità effettiva in tutti i tunnel che terminano nell'istanza VPN.
Valori per varie unità di scala supportate nella rete WAN virtuale
| Unità di scala | Velocità effettiva massima per tunnel (Mbps) | Numero massimo di PPS per tunnel | Velocità effettiva massima per istanza (Mbps) | Numero massimo di PPS per istanza |
|---|---|---|---|---|
| 1 | 500 | 47K | 500 | 47K |
| 2 | 1000 | 94K | 1000 | 94K |
| 3 | 1500 | 140K | 1500 | 140K |
| 4 | 1500 | 140K | 2000 | 187K |
| 5 | 1500 | 140K | 2500 | 234K |
| 6 | 1500 | 140K | 3000 | 281K |
| 7 | 2300 | 215K | 3500 | 328K |
| 8 | 2300 | 215K | 4000 | 374K |
| 9 | 2300 | 215K | 4500 | 421K |
| 10 | 2300 | 215K | 5000 | 468K |
| 11 | 2300 | 215K | 5500 | 515K |
| 12 | 2300 | 215K | 6000 | 562K |
| 13 | 2300 | 215K | 6500 | 609K |
| 14 | 2300 | 215K | 7000 | 655K |
| 15 | 2300 | 215K | 7500 | 702K |
| 16 | 2300 | 215K | 8000 | 749K |
| 17 | 2300 | 215K | 8500 | 796K |
| 18 | 2300 | 215K | 9000 | 843K |
| 19 | 2300 | 215K | 9500 | 889K |
| 20 | 2300 | 215K | 10000 | 936K |
Nota
Tutti i numeri sono basati sull'algoritmo GCM.
Quali provider di dispositivo (partner di WAN virtuale) sono supportati?
Al momento, molti partner supportano l'esperienza di rete WAN virtuale completamente automatizzata. Per altre informazioni, vedere Virtual WAN partners(Partner di WAN virtuali).
Quali sono i passaggi di Virtual WAN partner automation (Automazione dei partner della rete WAN virtuale)?
Per i passaggi di automazione dei partner, vedere Virtual WAN partner automation (Automazione dei partner della rete WAN virtuale).
È necessario usare il dispositivo di un partner preferito?
No. È possibile usare qualsiasi dispositivo che supporti la VPN e soddisfi i requisiti di Azure per il supporto di IKEv2/IKEv1 IPsec. La rete WAN virtuale include anche soluzioni di partner CPE che automatizzano la connettività alla rete WAN virtuale di Azure semplificando la configurazione di connessioni VPN IPSec su larga scala.
In che modo i partner di WAN virtuale automatizzano la connettività con la WAN virtuale di Azure?
Soluzioni di connettività definite dal software gestiscono in genere i propri dispositivi di ramo usando un controller o un centro di provisioning dei dispositivi. Il controller può usare le API di Azure per automatizzare la connettività alla WAN virtuale di Azure. L'automazione include il caricamento di informazioni sui rami, il download della configurazione di Azure, la configurazione di tunnel IPSec in hub virtuali di Azure e la configurazione automatica della connettività dal dispositivo di ramo alla rete WAN virtuale di Azure. Quando si dispone di centinaia di rami, la connessione tramite i partner CPE di WAN virtuale è semplice poiché l'esperienza di onboarding elimina la necessità di impostare, configurare e gestire la connettività IPsec su larga scala. Per altre informazioni, vedere Virtual WAN partner automation (Automazione dei partner di WAN virtuale).
Cosa accade se un dispositivo in uso non è incluso nell'elenco dei partner della rete WAN virtuale? È comunque possibile usarlo per connettersi alla VPN della rete WAN virtuale di Azure?
Sì, purché il dispositivo supporti IPsec IKEv1 o IKEv2. I partner della rete WAN virtuale automatizzano la connettività dal dispositivo agli endpoint VPN. Ciò implica l'automazione di passaggi quali il "caricamento di informazioni sui rami", "IPsec e configurazione" e "connettività". Poiché il dispositivo in uso non proviene da un ecosistema di partner della rete WAN virtuale, sarà necessario assumersi il carico di effettuare manualmente la configurazione di Azure e aggiornare il dispositivo per configurare la connettività IPsec.
In che modo vengono accettati i nuovi partner non inclusi nell'elenco dei partner iniziale?
Tutte le API della rete WAN virtuale sono OpenAPI. Per valutare la fattibilità tecnica, vedere la documentazione sull'automazione dei partner della rete WAN virtuale. Un partner ideale è quello che ha un dispositivo di cui è possibile eseguire il provisioning per la connettività IPSec IKEv1 o IKEv2. Una volta che l'azienda ha completato l'attività di automazione per il dispositivo CPE in base alle linee guida fornite in precedenza, è possibile contattare azurevirtualwan@microsoft.com per essere inseriti nella sezione Connettività tramite partner. Se si vuole che una soluzione di una specifica azienda venga inclusa nell'elenco di partner della rete WAN virtuale, chiedere all'azienda di inviare un messaggio di posta elettronica all'indirizzo azurevirtualwan@microsoft.com.
In che modo la rete WAN virtuale supporta i dispositivi SD-WAN?
I partner della rete WAN virtuale automatizzano la connettività IPsec agli endpoint VPN di Azure. Se il partner della rete WAN virtuale è un provider di SD-WAN, il controller SD-WAN gestisce l'automazione e la connettività IPsec agli endpoint VPN di Azure. Se il dispositivo SD-WAN richiede un proprio endpoint anziché una VPN di Azure per qualsiasi funzionalità SD-WAN proprietaria, è possibile distribuire l'endpoint SD-WAN in una rete virtuale di Azure e coesistere con la rete WAN virtuale di Azure.
La rete WAN virtuale supporta il peering BGP e offre anche la possibilità di distribuire appliance virtuali di rete in un hub della rete WAN virtuale.
Quanti dispositivi VPN possono connettersi a un singolo hub?
Sono supportate fino a 1.000 connessioni per ogni hub virtuale. Ogni connessione è costituita da quattro collegamenti e ciascuna connessione del collegamento supporta due tunnel in una configurazione attivo-attivo. I tunnel terminano in un gateway VPN dell'hub virtuale di Azure. I collegamenti rappresentano il collegamento all'ISP fisico nel dispositivo ramo/VPN.
Che cosa si intende per connessione da dispositivo di ramo alla rete WAN virtuale di Azure?
Una connessione da un ramo o un dispositivo VPN alla rete WAN virtuale di Azure è una connessione VPN che si connette virtualmente al sito VPN e al gateway VPN di Azure in un hub virtuale.
Cosa accade se il dispositivo VPN locale ha solo 1 tunnel a un gateway VPN della rete WAN virtuale di Azure?
Una connessione WAN virtuale di Azure è costituita da 2 tunnel. Un gateway VPN della rete WAN virtuale viene distribuito in un hub virtuale in modalità attiva-attiva, il che implica che sono presenti tunnel separati dai dispositivi locali che terminano in istanze separate. Si tratta della raccomandazione per tutti gli utenti. Tuttavia, se l'utente sceglie di avere solo 1 tunnel a una delle istanze del gateway VPN della rete WAN virtuale, se per qualsiasi motivo (manutenzione, patch e così via) l'istanza del gateway viene portata offline, il tunnel verrà spostato nell'istanza attiva secondaria e l'utente potrebbe riscontrare una riconnessione. Le sessioni BGP non verranno spostate tra istanze.
Cosa accade durante la reimpostazione del gateway in un gateway VPN della rete WAN virtuale?
Il pulsante Reimpostazione gateway deve essere usato se i dispositivi locali funzionano tutti come previsto, ma la connessione VPN da sito a sito in Azure è in stato Disconnesso. I gateway VPN della rete WAN virtuale vengono sempre distribuiti in stato attivo-attivo per la disponibilità elevata. Ciò significa che in qualsiasi momento è presente più di un'istanza distribuita in un gateway VPN. Quando si usa il pulsante Reimpostazione gateway, riavvia le istanze nel gateway VPN in modo sequenziale in modo che le connessioni non vengano interrotte. Si verificherà un breve gap man mano che le connessioni passano da un'istanza all'altra, ma questo gap dovrebbe essere inferiore a un minuto. Si noti inoltre che la reimpostazione dei gateway non modificherà gli indirizzi IP pubblici.
Questo scenario si applica solo alle connessioni S2S.
Il dispositivo VPN locale può connettersi a più hub?
Sì. Il flusso del traffico inizialmente proviene dal dispositivo locale verso la rete perimetrale Microsoft più vicina e quindi all'hub virtuale.
Sono disponibili nuove risorse di Gestione risorse per la WAN virtuale?
Sì, la rete WAN virtuale include nuove risorse di Resource Manager. Per altre informazioni, vedere la panoramica.
È possibile distribuire e usare l'appliance virtuale di rete preferita (in una rete virtuale di appliance virtuale di rete) con la rete WAN virtuale di Azure?
Sì, è possibile connettere la rete virtuale dell'appliance virtuale di rete preferita alla rete WAN virtuale di Azure.
Posso creare un'appliance virtuale di rete all'interno dell'hub virtuale?
Un'appliance virtuale di rete può essere distribuita all'interno di un hub virtuale. Per la procedura, vedere Informazioni sulle appliance virtuali di rete in un hub della rete WAN virtuale.
Un rete virtuale spoke può avere un gateway di rete virtuale?
No. La rete virtuale spoke non può avere un gateway di rete virtuale se è connessa all'hub virtuale.
Una rete virtuale spoke può avere un server di route di Azure?
No. La rete virtuale spoke non può avere un server di route se è connesso all'hub della rete WAN virtuale.
È disponibile il supporto per BGP nella connettività VPN?
Sì, BGP è supportato. Quando si crea un sito VPN, è possibile inserirvi i parametri BGP. Ciò implica che tutte le connessioni create in Azure per tale sito verranno abilitate per BGP.
Sono disponibili informazioni sulle licenze o i prezzi per la WAN virtuale?
Sì. Vedere la pagina dei Prezzi.
È possibile costruire la rete WAN virtuale di Azure con un modello di Resource Manager?
Una semplice configurazione di una rete WAN virtuale con un hub e un sito VPN può essere creata usando un modello di avvio rapido. La rete WAN virtuale è principalmente un REST o un servizio gestito dal Portale.
Le reti virtuali spoke connesse a un hub virtuale possono comunicare tra loro (transito V2V)?
Sì. La rete WAN virtuale Standard supporta la connettività transitiva da rete virtuale a rete virtuale tramite l'hub della rete WAN virtuale a cui sono connesse le reti virtuali. Nella terminologia della rete WAN virtuale, si fa riferimento a questi percorsi come "transito locale di rete virtuale in rete WAN virtuale" per le reti virtuali connesse a un hub rete WAN virtuale e "transito globale di rete virtuale in rete WAN virtuale" per le reti virtuali connesse tramite più hub rete WAN virtuale in due o più aree.
In alcuni scenari, le reti virtuali spoke possono anche essere collegate direttamente in peering tra loro usando il peering di reti virtuali oltre al transito locale o globale della rete virtuale nella rete WAN virtuale. In questo caso, il peering di reti virtuali ha la precedenza sulla connessione transitiva tramite l'hub della rete WAN virtuale.
La connettività tra succursali è consentita nella rete WAN virtuale?
Sì, la connettività tra succursali è disponibile nella rete WAN virtuale. Il ramo è concettualmente applicabile a un sito VPN, a circuiti ExpressRoute o a utenti di VPN utente/da punto a sito. La connessione da ramo a ramo è abilitata per impostazione predefinita e può essere individuata nelle impostazioni di configurazione della rete WAN. Ciò consente ai rami VPN o agli utenti di connettersi ad altri rami VPN e la connettività di transito è abilitata anche tra gli utenti VPN ed ExpressRoute.
Il traffico da ramo a ramo passa attraverso la rete WAN virtuale di Azure?
Sì. Il traffico da ramo a ramo attraversa la rete WAN virtuale di Azure.
La rete WAN virtuale richiede ExpressRoute da ogni sito?
No. La rete WAN virtuale non richiede ExpressRoute da ogni sito. I siti potrebbero essere connessi a una rete del provider usando un circuito ExpressRoute. Per i siti connessi tramite ExpressRoute a un hub virtuale e VPN IPsec nello stesso hub, l'hub virtuale fornisce connettività di transito tra la VPN e l'utente ExpressRoute.
È previsto un limite di velocità effettiva di rete o di connessioni quando si usa la rete WAN virtuale di Azure?
La velocità effettiva della rete viene assegnata per servizio in un hub della rete WAN virtuale. In ogni hub la velocità effettiva aggregata della VPN è fino a 20 Gbps, la velocità effettiva aggregata di ExpressRoute è fino a 20 Gbps e la velocità effettiva aggregata della VPN utente/VPN da punto a sito è fino a 200 Gbps. Il router nell'hub virtuale supporta fino a 50 Gbps per i flussi di traffico da rete virtuale a rete virtuale e presuppone un totale di carico di lavoro di 2000 macchine virtuali in tutte le reti virtuali connesse a un singolo hub virtuale.
Per proteggere la capacità iniziale senza dover attendere l'aumento del numero di istanze dell'hub virtuale quando è necessaria una maggiore velocità effettiva, è possibile impostare la capacità minima o modificare in base alle esigenze. Vedere Informazioni sulle impostazioni dell'hub virtuale - Capacità dell'hub. Per implicazioni sui costi, vedere il costo unità infrastruttura di routing nella pagina Prezzi della rete WAN virtuale di Azure.
I siti VPN si connettono a un hub tramite connessioni. La rete WAN virtuale supporta fino a 1000 connessioni o 2000 tunnel IPsec per ogni hub virtuale. Quando gli utenti remoti si connettono all'hub virtuale, si connettono al gateway VPN P2S, che supporta fino a 100.000 utenti a seconda dell'unità di scala (larghezza di banda) scelta per il gateway VPN P2S nell'hub virtuale.
È possibile usare NAT-T nelle connessioni VPN?
Sì, l'attraversamento NAT (NAT-T) è supportato. Il gateway VPN della rete WAN virtuale NON eseguirà alcuna funzionalità simile a NAT nei pacchetti interni da/verso i tunnel IPsec. In questa configurazione verificare che il dispositivo locale avvii il tunnel IPsec.
Come è possibile configurare un'unità di scala per un'impostazione specifica, ad esempio 20 Gbps?
Passare al gateway VPN all'interno di un hub nel portale, quindi fare clic sull'unità di scala per passare all'impostazione appropriata.
La rete WAN virtuale consente al dispositivo locale di usare più ISP in parallelo o si tratta sempre di un singolo tunnel VPN?
Le soluzioni per dispositivi locali possono applicare criteri per distribuire il traffico tra più tunnel nell'hub della rete WAN virtuale di Azure (gateway VPN nell'hub virtuale).
Che cos'è l'architettura di transito globale?
Per informazioni, vedere Architettura di rete di transito globale e rete WAN virtuale.
In quale modo il traffico viene indirizzato sul backbone di Azure?
Il traffico segue il modello: dispositivo di succursale ->ISP->rete perimetrale microsoft->Microsoft DC (hub VNet)->rete perimetrale microsoft->ISP->dispositivo del ramo
In questo modello, cosa serve in ogni sito? Semplicemente una connessione Internet?
Sì. Una connessione a Internet e un dispositivo fisico che supporti IPsec, preferibilmente dei partner di WAN virtuale integrati Microsoft. Facoltativamente è possibile gestire manualmente la configurazione e la connettività ad Azure dal dispositivo preferito.
Come si abilita la route predefinita (0.0.0.0/0) per una connessione (VPN, ExpressRoute o rete virtuale)?
Un hub virtuale può propagare una route predefinita appresa a una connessione di rete virtuale/VPN da sito a sito/ExpressRoute se il flag è su "Abilitato" nella connessione. Questo flag è visibile quando l'utente modifica una connessione di rete virtuale, VPN o ExpressRoute. Per impostazione predefinita, questo flag è disabilitato quando un sito o un circuito ExpressRoute sono connessi a un hub. Questa funzionalità è abilitata per impostazione predefinita quando si aggiunge una connessione di rete virtuale per connettere una rete virtuale a un hub virtuale.
La route predefinita non ha origine nell'hub della rete WAN virtuale; la route predefinita viene propagata se è già stata appresa dall'hub della rete WAN virtuale a seguito della distribuzione di un firewall nell'hub o se per un altro sito connesso è abilitato il tunneling forzato. Una route predefinita non viene propagata tra hub (inter-hub).
È possibile creare più hub della rete WAN virtuale nella stessa area?
Sì. I clienti possono ora creare più di un hub nella stessa area per la stessa rete WAN virtuale di Azure.
In che modo l'hub virtuale in una rete WAN virtuale seleziona il percorso migliore per una route da più hub?
Per informazioni, vedere la pagina delle preferenze di routing dell'hub virtuale.
L'hub della rete WAN virtuale consente la connettività tra circuiti ExpressRoute?
Il transito tra ER e ER avviene sempre tramite Copertura globale. I gateway dell'hub virtuale vengono distribuiti in un controller di dominio o in aree di Azure. Quando due circuiti ExpressRoute si connettono tramite Copertura globale, non è necessario che il traffico passi direttamente dai router perimetrali al controller di dominio dell'hub virtuale.
Esiste un concetto di peso nei circuiti ExpressRoute o nelle connessioni VPN della rete WAN virtuale di Azure?
Quando più circuiti ExpressRoute sono connessi a un hub virtuale, il peso del routing sulla connessione fornisce un meccanismo che consente a ExpressRoute nell'hub virtuale di preferire un circuito rispetto all'altro. Non esiste alcun meccanismo per impostare un peso su una connessione VPN. Azure preferisce sempre una connessione ExpressRoute rispetto a una connessione VPN all'interno di un singolo hub.
La rete WAN virtuale preferisce ExpressRoute rispetto a VPN per il traffico in uscita da Azure?
Sì. La rete WAN virtuale preferisce ExpressRoute rispetto alla VPN per il traffico in uscita in Azure. Tuttavia, è possibile configurare la preferenza di routing dell'hub virtuale per modificare la preferenza predefinita. Per la procedura, vedere Configurare le preferenze di routing dell'hub virtuale.
Quando un hub della rete WAN virtuale include un circuito ExpressRoute a cui è connesso un sito VPN, per quale motivo una route di connessione VPN verrebbe preferita rispetto a ExpressRoute?
Quando un circuito ExpressRoute è connesso a un hub virtuale, i router di Microsoft Edge sono il primo nodo per la comunicazione tra l'ambiente locale e Azure. Questi router perimetrali comunicano con i gateway ExpressRoute della rete WAN virtuale, che a loro volta riconoscono le route del router dell'hub virtuale che controlla tutte le route tra qualsiasi gateway nella rete WAN virtuale. I router Microsoft Edge elaborano le route ExpressRoute dell'hub virtuale con una priorità più alta rispetto alle route riconosciute dall'ambiente locale.
Se per qualsiasi motivo la connessione VPN diventa il mezzo principale da cui l'hub virtuale riconosce le route (ad esempio negli scenari di failover tra ExpressRoute e VPN), a meno che il sito VPN non abbia un percorso di routing simmetrico più lungo, l'hub virtuale continuerà a condividere le route riconosciute dalla VPN con il gateway ExpressRoute. In questo modo i router di Microsoft Edge preferiscono le route VPN rispetto alle route locali.
Quando due hub (hub 1 e 2) sono connessi e un circuito ExpressRoute è connesso a entrambi, qual è il percorso con cui una rete virtuale connessa all'hub 1 raggiunge una rete virtuale connessa all'hub 2?
Il comportamento corrente è quello di preferire il percorso del circuito ExpressRoute rispetto a quello da hub a hub per la connettività da rete virtuale a rete virtuale. Tuttavia, questa scelta non è consigliata in una configurazione di rete WAN virtuale. Per risolvere questo problema, è possibile eseguire una delle due operazioni seguenti:
Configurare più circuiti ExpressRoute (provider diversi) per connettersi a un hub e usare la connettività da hub a hub fornita dalla rete WAN virtuale per i flussi di traffico tra aree.
Configurare AS-Path come preferenza di routing hub per l'hub virtuale. In questo modo il traffico tra 2 hub attraversa il router dell'hub virtuale in ogni hub e usa il percorso da hub a hub anziché il percorso ExpressRoute (che attraversa i router di Microsoft Edge). Per altre informazioni, vedere Configurare le preferenze di routing dell'hub virtuale.
Quando è presente un circuito ExpressRoute connesso come collegamento di prua a un hub della rete WAN virtuale e a una rete virtuale autonoma, qual è il percorso della rete virtuale autonoma per raggiungere l'hub della rete WAN virtuale?
Per le nuove distribuzioni, questa connettività è bloccata per impostazione predefinita. Per consentire questa connettività, è possibile abilitare questi interruttori del gateway ExpressRoute nel pannello "Modifica hub virtuale" e nel pannello "Gateway di rete virtuale" nel portale. È tuttavia consigliabile mantenere questi interruttori disabilitati e creare invece una connessione di rete virtuale per connettere direttamente le reti virtuali autonome a un hub della rete WAN virtuale. Successivamente, il traffico da rete virtuale a rete virtuale passerà attraverso il router dell'hub della rete WAN virtuale, che offre prestazioni migliori rispetto al percorso ExpressRoute. Il percorso ExpressRoute include il gateway ExpressRoute, che ha limiti di larghezza di banda inferiori rispetto al router hub, nonché i router/MSEE di Microsoft Enterprise Edge, che è un hop aggiuntivo nel percorso dati.
Nel diagramma seguente è necessario abilitare entrambi gli interruttori per consentire la connettività tra la rete virtuale autonoma 4 e le reti virtuali connesse direttamente all'hub 2 (VNet 2 e VNet 3): Consentire il traffico dalle reti WAN virtuali remote per il gateway di rete virtuale e Consentire il traffico da reti WAN non virtuali per il gateway ExpressRoute dell'hub virtuale. Se un server di route di Azure viene distribuito nella rete virtuale autonoma 4 e il server di route è abilitato da ramo a ramo, la connettività verrà bloccata tra la rete virtuale 1 e la rete virtuale autonoma 4.
L'abilitazione o la disabilitazione dell'interruttore influirà solo sul flusso di traffico seguente: il flusso del traffico tra l'hub della rete WAN virtuale e le reti virtuali autonome tramite il circuito ExpressRoute. L'abilitazione o la disabilitazione dell'interruttore non comporta tempi di inattività per tutti gli altri flussi di traffico (ad esempio, la rete virtuale da sito locale a spoke 2 non sarà interessata, la rete virtuale dalla 2 alla rete virtuale 3 non saranno interessate e così via).
È possibile creare hub in gruppi di risorse diversi nella rete WAN virtuale?
Sì. Questa opzione è attualmente disponibile solo tramite PowerShell. Il portale della rete WAN virtuale richiede che gli hub si trovino nello stesso gruppo di risorse della risorsa della rete WAN virtuale stessa.
Qual è lo spazio indirizzi hub consigliato durante la creazione dell'hub?
Lo spazio indirizzi dell'hub della rete WAN virtuale consigliato è /23. L'hub della rete WAN virtuale assegna subnet a vari gateway (ExpressRoute, VPN da sito a sito, VPN da punto a sito, Firewall di Azure, Router hub virtuale). Per gli scenari in cui le appliance virtuali di rete vengono distribuite all'interno di un hub virtuale, viene in genere ritagliato un /28 per le istanze dell'appliance virtuale di rete. Tuttavia, se l'utente deve effettuare il provisioning di più appliance virtuali di rete, potrebbe essere assegnata una subnet /27. Pertanto, tenendo presente un'architettura futura, mentre gli hub della rete WAN virtuale vengono distribuiti con una dimensione minima di /24, lo spazio indirizzi dell'hub consigliato in fase di creazione per l'input dell'utente è /23.
È disponibile il supporto per IPv6 nella rete WAN virtuale?
IPv6 non è supportato nell'hub della rete WAN virtuale e nei relativi gateway. Attualmente non è neanche supportata la connessione di una rete virtuale con supporto per IPv4 e IPv6 a una rete WAN virtuale.
Per lo scenario della VPN da punto a sito (utente) con breakout Internet tramite Firewall di Azure, si dovrà probabilmente disattivare la connettività IPv6 nel dispositivo client per forzare il traffico verso l'hub della rete WAN virtuale. Il motivo è che i moderni dispositivi usano gli indirizzi IPv6.
Qual è la versione consigliata dell'API da usare per gli script che automatizzano varie funzionalità della rete WAN virtuale?
È necessaria almeno la versione 05-01-2022 (1° maggio 2022).
Sono previsti limiti per la rete WAN virtuale?
Vedere la sezione Limiti della rete WAN virtuale nella pagina Limiti della sottoscrizione e del servizio.
Quali sono le differenze tra i tipi di rete WAN virtuale (Basic e Standard)?
Vedere Reti WAN virtuali Basic e Standard. Per i prezzi, vedere la pagina dei Prezzi.
La rete WAN virtuale archivia i dati dei clienti?
No. La rete WAN virtuale non archivia i dati dei clienti.
Esistono provider di servizi gestiti in grado di gestire la rete WAN virtuale per gli utenti come servizio?
Sì. Per un elenco delle soluzioni dei provider di servizi gestiti abilitate tramite Azure Marketplace, vedere Offerte di Azure Marketplace da partner MSP di rete di Azure.
In che modo il routing dell'hub della rete WAN virtuale differisce dal server di route di Azure in una rete virtuale?
Sia l'hub della rete WAN virtuale di Azure che il server di route di Azure forniscono funzionalità di peering BGP (Border Gateway Protocol) che possono essere usate dalle appliance virtuali di rete (Appliance virtuale di rete) per annunciare gli indirizzi IP dall'appliance virtuale di rete alle reti virtuali di Azure dell'utente. Le opzioni di distribuzione differiscono nel senso che il server di route di Azure viene in genere distribuito da una rete virtuale dell'hub cliente autogestito, mentre la rete WAN virtuale di Azure offre un servizio hub completamente mesh a zero a cui i clienti connettono i vari spoke end point (rete virtuale di Azure, rami locali con VPN da sito a sito o SDWAN, utenti remoti con VPN da punto a sito/connessioni private con ExpressRoute) e godono del peering BGP per le appliance virtuali di rete distribuite nella rete virtuale spoke insieme ad altre funzionalità VWAN come la connettività di transito per la rete virtuale a rete virtuale, la connettività di transito tra VPN ed ExpressRoute, il routing personalizzato/avanzato, l'associazione e la propagazione delle route personalizzate, la finalità/i criteri di routing senza problemi di sicurezza tra aree, l'hub protetto/il firewall di Azure e così via. Per altre informazioni sul peering BGP della rete WAN virtuale, vedere Come eseguire il peering BGP con un hub virtuale.
Se si usa un provider di sicurezza di terze parti (Zscaler, iBoss o Checkpoint) per proteggere il traffico Internet, perché non viene visualizzato il sito VPN associato al provider di sicurezza di terze parti nel portale di Azure?
Quando si sceglie di distribuire un provider di partner di sicurezza per proteggere l'accesso a Internet per gli utenti, il provider di sicurezza di terze parti crea un sito VPN per conto dell'utente. Poiché il provider di sicurezza di terze parti viene creato automaticamente dal provider e non è un sito VPN creato dall'utente, questo sito VPN non verrà visualizzato nel portale di Azure.
Per altre informazioni sulle opzioni disponibili provider di sicurezza di terze parti e su come configurare questa impostazione, vedere Distribuire un provider di partner di sicurezza.
Le community BGP generate dall'ambiente locale verranno mantenute nella rete WAN virtuale?
Sì, le community BGP generate dall'ambiente locale verranno mantenute nella rete WAN virtuale.
Le community BGP generate dai peer BGP (in una rete virtuale collegata) verranno mantenute nella rete WAN virtuale?
Sì, le community BGP generate dai peer BGP verranno mantenute nella rete WAN virtuale. Le community vengono mantenute nello stesso hub e tra connessioni interhub. Questo vale anche per gli scenari della rete WAN virtuale che usano criteri di finalità di routing.
Quali numeri ASN sono supportati per le reti locali collegate in remoto che eseguono BGP?
È possibile usare ASN pubblici o ASN privati per le reti locali. Non è possibile usare gli intervalli riservati da Azure o IANA:
- Numeri ASN riservati da Azure:
- ASN pubblici: 8074, 8075, 12076
- ASN privati: 65515, 65517, 65518, 65519, 65520
- ASN riservati da IANA: 23456, 64496-64511, 65535-65551
Esiste un modo per modificare l'ASN per un gateway VPN?
No. La rete WAN virtuale non supporta le modifiche ASN per i gateway VPN.
Nella rete WAN virtuale quali sono le prestazioni stimate dello SKU del gateway ExpressRoute?
| Unità di scala | Connessioni al secondo | Megabit al secondo | Pacchetti al secondo |
|---|---|---|---|
| 1 unità di scala |
14.000 | 2.000 | 200.000 |
| 2 unità di scala |
28.000 | 4.000 | 400.000 |
| 3 unità di scala |
42.000 | 6.000 | 600,000 |
| 4 unità di scala |
56.000 | 8.000 | 800,000 |
| 5 unità di scala |
70.000 | 10,000 | 1\.000.000 |
| 6 unità di scala |
84.000 | 12,000 | 1,200,000 |
| 7 unità di scala |
98.000 | 14.000 | 1.400.000 |
| 8 unità di scala |
112.000 | 16.000 | 1,600,000 |
| 9 unità di scala |
126.000 | 18.000 | 1.800.000 |
| 10 unità di scala |
140.000 | 20.000 | 2,000,000 |
Le unità di scala 2-10, durante le operazioni di manutenzione, mantengono la velocità effettiva aggregata. Tuttavia, l'unità di scala 1, durante un'operazione di manutenzione, può visualizzare una leggera variazione dei numeri di velocità effettiva.
Se si connette un circuito Locale ExpressRoute a un hub della rete WAN virtuale, sarà possibile accedere solo alle aree nella stessa località metropolitana del circuito locale?
I circuiti locali possono essere connessi solo ai gateway ExpressRoute nella rispettiva area di Azure. Non esiste tuttavia alcuna limitazione per instradare il traffico alle reti virtuali spoke in altre aree.
Perché viene visualizzato un messaggio e un pulsante denominato "Update router to latest software version" (Aggiorna il router alla versione più recente del software) nel portale?
Nota
A partire dal 1° luglio 2024, gli hub sulla versione precedente verranno ritirati in fasi e smetteranno di funzionare come previsto.
L'infrastruttura basata su Servizi cloud a livello di Azure è deprecata. Di conseguenza, il team della rete WAN virtuale sta lavorando per aggiornare i router virtuali dall'infrastruttura di Servizi cloud corrente alle distribuzioni basate su set di scalabilità di macchine virtuali. Tutti gli hub virtuali appena creati verranno distribuiti automaticamente nell'infrastruttura basata sui set di scalabilità di macchine virtuali più recenti. Se si passa alla risorsa hub della rete WAN virtuale e viene visualizzato il messaggio e il pulsante, è possibile aggiornare il router alla versione più recente facendo clic sul pulsante. Se si vuole sfruttare le nuove funzionalità della rete WAN virtuale, ad esempio il peering BGP con l'hub, è necessario aggiornare il router dell'hub virtuale tramite il portale di Azure. Se il pulsante non è visibile, aprire un caso di supporto.
Sarà possibile aggiornare il router dell'hub virtuale solo se tutte le risorse (gateway/tabelle di route/connessioni di rete virtuale) nell'hub sono in uno stato riuscito. Assicurarsi che tutte le reti virtuali spoke si trovino in sottoscrizioni attive/abilitate e che le reti virtuali spoke non vengano eliminate. Inoltre, poiché questa operazione richiede la distribuzione di nuovi router hub virtuali basati su set di scalabilità di macchine virtuali, si verifica un tempo di inattività previsto di 1-2 minuti per il traffico da rete virtuale a rete virtuale attraverso lo stesso hub e 5-7 minuti per tutti gli altri flussi di traffico attraverso l'hub. Pianificare una finestra di manutenzione di almeno 30 minuti, perché il tempo di inattività può durare fino a 30 minuti nello scenario peggiore. All'interno di una singola risorsa della rete WAN virtuale, gli hub devono essere aggiornati uno alla volta anziché aggiornare più contemporaneamente. Quando la versione del router indica "Più recenti", l'hub viene eseguito l'aggiornamento. Dopo questo aggiornamento non verranno apportate modifiche al comportamento di routing.
Esistono diversi aspetti da notare con l'aggiornamento del router dell'hub virtuale:
Se è già stato configurato il peering BGP tra l'hub della rete WAN virtuale e un'appliance virtuale di rete in una rete virtuale spoke, sarà necessario eliminare e quindi ricreare il peer BGP. Poiché gli indirizzi IP del router dell'hub virtuale cambiano dopo l'aggiornamento, sarà necessario riconfigurare l'appliance virtuale di rete per eseguire il peering con i nuovi indirizzi IP del router dell'hub virtuale. Questi indirizzi IP sono rappresentati come campo "virtualRouterIps" nel codice JSON della risorsa dell'hub virtuale.
Se si dispone di un'appliance virtuale di rete nell'hub virtuale, è necessario collaborare con il partner dell'appliance virtuale di rete per ottenere istruzioni su come aggiornare l'hub della rete WAN virtuale.
Se l'hub virtuale è configurato con più di 15 unità di infrastruttura di routing, passare nell'hub virtuale a 2 unità di infrastruttura di routing prima di tentare l'aggiornamento. È possibile eseguire il ridimensionamento dell'hub a più di 15 unità di infrastruttura di routing dopo l'aggiornamento dell'hub.
Se l'aggiornamento non riesce per qualsiasi motivo, l'hub verrà ripristinato automaticamente alla versione precedente per assicurarsi che sia ancora attiva una configurazione funzionante.
Altre cose da notare:
L'utente dovrà avere un ruolo di proprietario o collaboratore per visualizzare uno stato accurato della versione del router hub. Se a un utente viene assegnato un ruolo di lettore alla risorsa e alla sottoscrizione della rete WAN virtuale, il portale di Azure visualizza all'utente che il router hub deve essere aggiornato alla versione più recente, anche se l'hub è già nella versione più recente.
Se si modifica lo stato della sottoscrizione della rete virtuale spoke da disabilitato a abilitato e quindi si aggiorna l'hub virtuale, sarà necessario aggiornare la connessione di rete virtuale dopo l'aggiornamento dell'hub virtuale (ad esempio, è possibile configurare la connessione di rete virtuale per propagarsi a un'etichetta fittizia).
Se l'hub è connesso a un numero elevato di reti virtuali spoke (60 o più), è possibile notare che 1 o più peering di reti virtuali spoke entreranno in uno stato di errore dopo l'aggiornamento. Per ripristinare lo stato corretto di questi peering di reti virtuali dopo l'aggiornamento, è possibile configurare le connessioni di rete virtuali da propagare a un'etichetta fittizia oppure eliminare e ricreare queste rispettive connessioni di rete virtuali.
Perché il router dell'hub virtuale richiede un indirizzo IP pubblico con porte aperte?
Questi endpoint pubblici sono necessari per la piattaforma SDN e la gestione sottostante di Azure per comunicare con il router dell'hub virtuale. Poiché il router dell'hub virtuale è considerato parte della rete privata del cliente, la piattaforma sottostante di Azure non è in grado di accedere direttamente e gestire il router hub tramite gli endpoint privati a causa dei requisiti di conformità. La connettività agli endpoint pubblici del router hub viene autenticata tramite certificati e Azure esegue controlli di sicurezza di routine di questi endpoint pubblici. Di conseguenza, non costituiscono un'esposizione alla sicurezza dell'hub virtuale.
Esiste un limite di route per i client OpenVPN che si connettono a un gateway P2S VPN di Azure?
Il limite di route per i client OpenVPN è 1000.
Come viene calcolato il contratto di servizio della rete WAN virtuale?
La rete WAN virtuale è una piattaforma di rete distribuita come servizio con un contratto di servizio del 99,95%. Tuttavia, la rete WAN virtuale combina molti componenti diversi, ad esempio Firewall di Azure, VPN da sito a sito, ExpressRoute, VPN da punto a sito e appliance virtuali di rete WAN virtuale/appliance virtuali di rete virtuale.
Il contratto di servizio per ogni componente viene calcolato singolarmente. Ad esempio, se ExpressRoute ha un tempo di inattività di 10 minuti, la disponibilità di ExpressRoute verrà calcolata come (Numero massimo di minuti disponibili - tempo di inattività) / Minuti massimi disponibili * 100.
È possibile modificare lo spazio degli indirizzi della rete virtuale in una rete virtuale spoke connessa all'hub?
Sì, questa operazione può essere eseguita automaticamente senza aggiornare o reimpostare la connessione di peering. Tenere presente quanto segue:
- Non è necessario fare clic sul pulsante "Sincronizza" nel pannello Peering. Dopo aver modificato lo spazio degli indirizzi della rete virtuale, il peering reti virtuali verrà sincronizzato automaticamente con la rete virtuale dell'hub virtuale.
- Assicurarsi che lo spazio indirizzi aggiornato non si sovrapponga allo spazio indirizzi per le reti virtuali spoke esistenti nella rete WAN virtuale.
Altre informazioni su come modificare lo spazio degli indirizzi della rete virtuale sono disponibili qui.
Manutenzione del gateway controllato dal cliente della rete WAN virtuale
Quali servizi sono inclusi nell'ambito della configurazione di manutenzione dei gateway di rete?
Per la rete WAN virtuale, è possibile configurare finestre di manutenzione per gateway VPN da sito a sito e gateway ExpressRoute.
Quale manutenzione è supportata o non è supportata dalla manutenzione controllata dal cliente?
I servizi di Azure passano attraverso aggiornamenti periodici di manutenzione per migliorare funzionalità, affidabilità, prestazioni e sicurezza. Dopo aver configurato una finestra di manutenzione per le risorse, la manutenzione del sistema operativo guest e del servizio vengono eseguite durante tale finestra. Questi aggiornamenti riguardano la maggior parte degli elementi di manutenzione che interessano i clienti.
Gli aggiornamenti dell'infrastruttura dell'host e del data center sottostanti non sono coperti dalla manutenzione controllata dal cliente. Inoltre, se si verifica un problema di sicurezza con gravità elevata che potrebbe compromettere i clienti, Azure potrebbe dover eseguire l'override del controllo cliente della finestra di manutenzione e implementare la modifica. Si tratta di eventi rari a cui si fa ricorso solo in casi estremi.
È possibile ricevere una notifica avanzata della manutenzione?
Al momento, la notifica avanzata non può essere abilitata per la manutenzione delle risorse del gateway di rete.
È possibile configurare una finestra di manutenzione più breve di cinque ore?
Al momento, è necessario configurare una finestra minima di cinque ore nel fuso orario preferito.
È possibile configurare una pianificazione di manutenzione che non si ripete ogni giorno?
In questo momento, è necessario configurare una finestra di manutenzione giornaliera.
Le risorse di configurazione della manutenzione devono trovarsi nella stessa area della risorsa del gateway?
Sì.
È necessario distribuire un'unità di scala gateway minima per essere idonea per la manutenzione controllata dal cliente?
No.
Quanto tempo è necessario per rendere effettivi i criteri di configurazione della manutenzione dopo l'assegnazione alla risorsa del gateway?
Potrebbero essere necessarie fino a 24 ore prima che i gateway di rete seguano la pianificazione della manutenzione dopo che i criteri di manutenzione sono stati associati alla risorsa del gateway.
Come pianificare le finestre di manutenzione quando si usa VPN ed ExpressRoute in uno scenario di coesistenza?
Quando si usano VPN ed ExpressRoute in uno scenario di coesistenza o ogni volta che si dispone di risorse che fungono da backup, è consigliabile configurare finestre di manutenzione separate. Questo approccio garantisce che la manutenzione non influisca contemporaneamente sulle risorse di backup.
È stata pianificato una finestra di manutenzione per una data futura per una risorsa. Le attività di manutenzione verranno sospese su questa risorsa fino ad allora?
No, le attività di manutenzione non verranno sospese nella risorsa durante il periodo che precede la finestra di manutenzione pianificata. Per i giorni non coperti nel programma di manutenzione, la manutenzione continua come di consueto nella risorsa.
Passaggi successivi
Per altre informazioni sulla rete WAN virtuale, vedere Informazioni sulla rete WAN virtuale.
Commenti e suggerimenti
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedere https://aka.ms/ContentUserFeedback.
Invia e visualizza il feedback per