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. Esistono funzionalità o scenari all'interno di rete WAN virtuale in cui Microsoft applica il tag Preview. In questi casi, la funzionalità specifica o lo scenario stesso è disponibile in anteprima. Se non si usa una funzionalità di anteprima specifica, viene applicato il normale supporto per la 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 informazioni, vedere Località e aree disponibili.
Per usare la rete WAN virtuale di Azure, è necessario avere un'architettura hub-spoke con dispositivi SD-WAN/VPN?
rete WAN virtuale offre molte funzionalità integrate in un unico riquadro di vetro, ad esempio connettività VPN da sito/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, Firewall di Azure e Sicurezza di Gestione firewall, Monitoraggio, Crittografia ExpressRoute e molte altre funzionalità. Non è necessario che tutti questi casi d'uso inizino a usare rete WAN virtuale. È possibile iniziare semplicemente con uno solo.
L'architettura rete WAN virtuale è un'architettura hub-spoke con scalabilità e prestazioni integrate in cui rami (dispositivi VPN/SD-WAN), utenti (client VPN di Azure, client openVPN o IKEv2), circuiti ExpressRoute, reti virtuali fungono da spoke per 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 da punto a sito/utente, è supportato il client VPN di Azure, OpenVPN o il client IKEv2.
È possibile disabilitare gli hub completamente connessi in una mesh in una rete WAN virtuale?
rete WAN virtuale è disponibile in due versioni: Basic e Standard. In Rete WAN virtuale basic gli hub non sono 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. 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 rete WAN virtuale sono presenti più servizi come VPN, ExpressRoute e così via. Ognuno di questi servizi viene distribuito automaticamente in zone di disponibilità (ad eccezione di Firewall di Azure), se l'area supporta 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à. Viene effettuato il provisioning di tutti i gateway in un hub come attivo-attivo, implicando la resilienza incorporata all'interno di un hub. Per ottenere resilienza tra aree, gli utenti possono connettersi a più hub.
Attualmente, è possibile distribuire Firewall di Azure per supportare zone di disponibilità tramite il portale di Firewall di Azure Manager, PowerShell o l'interfaccia della riga di comando. Attualmente non è possibile configurare un firewall esistente da distribuire tra le zone di disponibilità. È necessario eliminare e ridistribuire il 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 l'area della rete WAN virtuale stessa dovesse avere un problema, tutti gli hub nella rete WAN virtuale continueranno a funzionare così come sono, ma l'utente non sarà in grado di creare nuovi hub finché non sarà disponibile l'area della rete WAN virtuale.
È 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.
Quale client supporta la VPN utente (da punto a sito) di Azure rete WAN virtuale?
La rete WAN virtuale supporta il client VPN di Azure, il client OpenVPN o qualsiasi client IKEv2. L'autenticazione Di 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 con estensione ovpn* da scaricare nel dispositivo. IKEv2 supporta sia l'autenticazione basata su certificato che RADIUS.
Per VPN utente (da punto a sito): perché il pool di client da punto a sito è suddiviso in due route?
Ogni gateway ha due istanze. La suddivisione avviene in modo che ogni istanza del gateway possa allocare in modo indipendente gli INDIRIZZI IP client per i client connessi e il traffico dalla rete virtuale viene instradato all'istanza del gateway corretta per evitare l'hop dell'istanza tra gateway.
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 | Connessione 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. Poiché è possibile ottenere 500 connessioni * 2 per gateway, non significa che si prevede 1000 anziché 500 per questa unità di scala. È possibile che le istanze debbano essere gestite durante le quali la connettività per i 500 aggiuntivi potrebbe essere interrotta se si supera il numero di connessioni consigliate.
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 VPN implicano 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. Quando si connette un sito a un gateway VPN rete WAN virtuale, è diverso da un normale gateway di rete virtuale che usa un tipo di gateway "VPN da sito a sito". Quando si vuole connettere utenti remoti a 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 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".
rete WAN virtuale supporta una velocità effettiva aggregata fino a 20 Gbps 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 Partner preferito.
In che modo la rete WAN virtuale è diversa dal gateway di rete virtuale di Azure?
Una VPN del gateway di rete virtuale è limitata a 100 tunnel. Per le connessioni, è consigliabile usare la rete WAN virtuale per VPN su larga scala. È possibile connettersi fino a 1.000 connessioni di succursale per ogni hub virtuale con aggregazione 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 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 in rete WAN virtuale hub? Quanti tunnel supportano per ogni istanza? Qual è la velocità effettiva massima supportata in un singolo tunnel?
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 alla sola a causa della quale un utente potrebbe riscontrare una breve diminuzione della velocità effettiva aggregata di un gateway VPN.
Anche se rete WAN virtuale VPN supporta molti algoritmi, è consigliabile GCMAES256 sia per la crittografia IP edizione Standard C 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. Questo è meglio compreso con un esempio. Si supponga che un'istanza del gateway VPN da sito a sito a 500 Mbps 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.
rete WAN virtuale ha concetti di connessione VPN, connessione di collegamento e tunnel. Una singola connessione VPN è costituita da connessioni di collegamento. 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 in 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 | 187.000 |
| 5 | 1500 | 140K | 2500 | 234 K |
| 6 | 1500 | 140K | 3000 | 281.000 |
| 7 | 2300 | 215.000 | 3500 | 328 K |
| 8 | 2300 | 215.000 | 4000 | 374 K |
| 9 | 2300 | 215.000 | 4500 | 421.000 |
| 10 | 2300 | 215.000 | 5000 | 468 K |
| 11 | 2300 | 215.000 | 5500 | 515.000 |
| 12 | 2300 | 215.000 | 6000 | 562 K |
| 13 | 2300 | 215.000 | 6500 | 609.000 |
| 14 | 2300 | 215.000 | 7000 | 655 K |
| 15 | 2300 | 215.000 | 7500 | 702K |
| 16 | 2300 | 215.000 | 8000 | 749.000 |
| 17 | 2300 | 215.000 | 8500 | 796.000 |
| 18 | 2300 | 215.000 | 9000 | 843.000 |
| 19 | 2300 | 215.000 | 9500 | 889.000 |
| 20 | 2300 | 215.000 | 10000 | 936.000 |
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 delle informazioni sui rami, il download della configurazione di Azure, la configurazione dei tunnel IPsec negli hub virtuali di Azure e la configurazione automatica della connettività dal dispositivo di succursale ad Azure rete WAN virtuale. 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 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 non proviene da un ecosistema di partner rete WAN virtuale, è necessario eseguire l'operazione pesante di eseguire manualmente la configurazione di Azure e aggiornare il dispositivo per configurare la connettività IPsec.
Come vengono inseriti i nuovi partner non elencati nell'elenco dei partner di lancio?
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 è un cliente che vuole che una determinata soluzione aziendale venga elencata come partner rete WAN virtuale, chiedere all'azienda di contattare il rete WAN virtuale inviando un messaggio di posta elettronica a 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 rete WAN virtuale è un provider SD-WAN, è implicito che il controller SD-WAN gestisce l'automazione e la connettività IPsec ai punti finali 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 il punto finale SD-WAN in una rete virtuale di Azure e coesistere con Azure rete WAN virtuale.
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 in Azure rete WAN virtuale è 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 di Azure rete WAN virtuale?
Una connessione rete WAN virtuale di Azure è costituita da 2 tunnel. Un gateway VPN 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 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 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. rete WAN virtuale i gateway VPN vengono sempre distribuiti in uno 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. Ci sarà 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 da sito a sito.
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 Azure rete WAN virtuale?
Sì, è possibile connettere la rete virtuale dell'appliance virtuale di rete preferita all'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 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 è connesso 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 rete WAN virtuale si fa riferimento a questi percorsi come "transito locale rete WAN virtuale rete virtuale" per le reti virtuali connesse a un hub rete WAN virtuale all'interno di una singola area e "transito globale rete WAN virtuale rete virtuale" per le reti virtuali connesse tramite più rete WAN virtuale hub in due o più aree.
In alcuni scenari, le reti virtuali spoke possono anche essere sottoposte direttamente a peering tra loro usando il peering di rete virtuale oltre al transito di rete virtuale locale o globale rete WAN virtuale rete 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 siti VPN, circuiti ExpressRoute o utenti VPN da punto a sito/utente. L'abilitazione di branch-to-branch è abilitata per impostazione predefinita e può trovarsi 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 l'rete WAN virtuale di Azure.
La rete WAN virtuale richiede ExpressRoute da ogni sito?
No. 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 VPN è fino a 20 Gbps, la velocità effettiva di aggregazione ExpressRoute è fino a 20 Gbps e la velocità effettiva di aggregazione VPN vpn da punto a sito utente è 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 2000 carichi di lavoro di 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 Routing Infrastructure Unit cost (Costo unità infrastruttura di routing) nella pagina Prezzi di Azure rete WAN virtuale.
Quando i siti VPN si connettono a un hub, lo fanno con le 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 da sito a sito, che supporta fino a 100.000 utenti a seconda dell'unità di scala (larghezza di banda) scelta per il gateway VPN da sito a sito nell'hub virtuale.
È possibile usare NAT-T nelle connessioni VPN?
Sì, è supportato l'attraversamento NAT (NAT-T). Il gateway VPN 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 branch ->ISP-Microsoft network edge-Microsoft>> DC (hub VNet)->Microsoft network edge-ISP-branch>> device
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.
Ricerca per categorie abilitare 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. È abilitata per impostazione predefinita quando viene aggiunta una connessione di rete virtuale per connettere una rete virtuale a un hub virtuale.
La route predefinita non ha origine nell'hub rete WAN virtuale. La route predefinita viene propagata se è già appresa dall'hub rete WAN virtuale come risultato della distribuzione di un firewall nell'hub o se un altro sito connesso ha 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 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 arrivi da tutti i 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ì. rete WAN virtuale preferisce ExpressRoute rispetto alla VPN per il traffico in uscita da 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 rete WAN virtuale dispone di un circuito ExpressRoute e di un sito VPN connesso, cosa fa sì che una route di connessione VPN sia 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 Di Microsoft Edge elaborano le route ExpressRoute dell'hub virtuale con una preferenza superiore rispetto alle route apprese in locale.
Per qualsiasi motivo, se la connessione VPN diventa il supporto primario per l'hub virtuale per apprendere le route da (ad esempio scenari di failover tra ExpressRoute e VPN), a meno che il sito VPN non abbia una lunghezza del percorso AS più lunga, l'hub virtuale continuerà a condividere le route apprese 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 c'è un circuito ExpressRoute connesso come collegamento di prua a entrambi gli hub, qual è il percorso per una rete virtuale connessa all'hub 1 per raggiungere una rete virtuale connessa nell'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, questo non è consigliato in una configurazione 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 da 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 rete WAN virtuale e a una rete virtuale autonoma, qual è il percorso della rete virtuale autonoma per raggiungere l'hub 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 disabilitati questi interruttori e creare invece una connessione Rete virtuale per connettere direttamente le reti virtuali autonome a un hub rete WAN virtuale. Successivamente, il traffico da rete virtuale a rete virtuale attraversa il router hub 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 Microsoft Enterprise Edge/M edizione Standard E, 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 rete WAN virtuale remote per il gateway di rete virtuale e Consentire il traffico da reti non rete WAN virtuale 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 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 2 alla rete virtuale 3 non sarà interessata e così via).
È possibile creare hub in gruppi di risorse diversi in rete WAN virtuale?
Sì. Questa opzione è attualmente disponibile solo tramite PowerShell. Il portale di rete WAN virtuale richiede che gli hub si trovino nello stesso gruppo di risorse della risorsa rete WAN virtuale stessa.
Qual è lo spazio indirizzi hub consigliato durante la creazione dell'hub?
Lo spazio indirizzi dell'hub rete WAN virtuale consigliato è /23. rete WAN virtuale hub assegna subnet a vari gateway (ExpressRoute, VPN da sito a sito, VPN da punto a sito, Firewall di Azure, router dell'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 rete WAN virtuale hub vengono distribuiti con una dimensione minima di /24, lo spazio indirizzi dell'hub consigliato al momento della creazione per l'input dell'utente è /23.
È disponibile il supporto per IPv6 nella rete WAN virtuale?
IPv6 non è supportato nell'hub 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 VPN utente da punto a sito con interruzione Internet tramite Firewall di Azure, è probabile che sia necessario disattivare la connettività IPv6 nel dispositivo client per forzare il traffico verso l'hub rete WAN virtuale. Questo perché i dispositivi moderni, per impostazione predefinita, usano indirizzi IPv6.
Qual è la versione consigliata dell'API da usare per gli script che automatizzano varie funzionalità della rete WAN virtuale?
È necessaria una versione minima di 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. rete WAN virtuale non archivia 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 rete WAN virtuale routing dell'hub differisce dal server di route di Azure in una rete virtuale?
Sia l'hub 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 del cliente autogestito, mentre Azure rete WAN virtuale fornisce un servizio hub completamente mesh senza tocco a cui i clienti connettono i vari spoke (rete virtuale di Azure, rami locali con VPN da sito a sito o SDWAN, utenti remoti con VPN da punto a sito/vpn utente remoto e connessioni private con ExpressRoute) e godono del peering BGP per appliance virtuali di rete distribuito nella rete virtuale spoke insieme ad altre funzionalità vWAN, ad esempio la connettività di transito per la rete virtuale da 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 per la sicurezza tra aree, l'hub protetto/il firewall di Azure e così via. Per altre informazioni sul peering BGP 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 nella 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 in rete WAN virtuale?
Sì, le community BGP generate dall'ambiente locale verranno mantenute in rete WAN virtuale.
Le community BGP generate dai peer BGP (in un Rete virtuale collegato) verranno mantenute in rete WAN virtuale?
Sì, le community BGP generate dai peer BGP verranno mantenute in rete WAN virtuale. Le community vengono mantenute nello stesso hub e tra connessioni interhub. Questo vale anche per gli scenari di rete WAN virtuale che usano i 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. 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 | Mega bit 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 ExpressRoute Local a un hub 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 da gennaio 2024, il team rete WAN virtuale ha avviato l'aggiornamento degli hub virtuali alla versione più recente. Se l'hub non è stato aggiornato, ma ora si nota che la versione del router dell'hub è "più recente", l'hub è stato aggiornato dal team rete WAN virtuale.
L'infrastruttura basata su Servizi cloud a livello di Azure è deprecata. Di conseguenza, il team rete WAN virtuale sta lavorando per aggiornare i router virtuali dall'infrastruttura 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 su set di scalabilità di macchine virtuali più recente. Se si passa alla risorsa hub rete WAN virtuale e viene visualizzato questo messaggio e il pulsante, è possibile aggiornare il router alla versione più recente facendo clic sul pulsante . Se si vuole sfruttare le nuove funzionalità di rete WAN virtuale, ad esempio il peering BGP con l'hub, è necessario aggiornare il router dell'hub virtuale tramite 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. All'interno di una singola risorsa rete WAN virtuale, gli hub devono essere aggiornati uno alla volta anziché aggiornare più contemporaneamente. Quando la versione del router indica "Latest", 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 rete WAN virtuale e un'appliance virtuale di rete in una rete virtuale spoke, è 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 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 lettore alla risorsa e alla sottoscrizione 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 reti virtuali dopo l'aggiornamento, è possibile configurare le connessioni di rete virtuale da propagare a un'etichetta fittizia oppure eliminare e ricreare queste rispettive connessioni di rete virtuale.
Perché il router dell'hub virtuale richiede un indirizzo IP pubblico con porte aperte?
Questi endpoint pubblici sono necessari per la piattaforma SDN e 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à. Connessione ivity 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 VPN da punto a sito di Azure?
Il limite di route per i client OpenVPN è 1000.
Come viene calcolato rete WAN virtuale contratto di servizio?
rete WAN virtuale è una piattaforma di rete distribuita come servizio con un contratto di servizio del 99,95%. Tuttavia, 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 hub/rete integrata rete WAN 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. Altre informazioni su come modificare lo spazio degli indirizzi della rete virtuale sono disponibili qui.
rete WAN virtuale manutenzione del gateway controllata dal cliente
Quali servizi sono inclusi nell'ambito della configurazione di manutenzione dei gateway di rete?
Per rete WAN virtuale, è possibile configurare le 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 viene eseguita durante tale finestra. Questi aggiornamenti riguardano la maggior parte degli elementi di manutenzione che causano problemi per 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 rare occorrenze che verrebbero usate 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?
A questo punto, è necessario configurare almeno un intervallo 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 della configurazione di 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 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 associati alla risorsa gateway.
Come pianificare le finestre di manutenzione quando si usa VPN ed ExpressRoute in uno scenario di coesistenza?
Quando si lavora con 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.
Ho pianificato una finestra di manutenzione per una data futura per una delle mie risorse. 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 prima della finestra di manutenzione pianificata. Per i giorni non coperti nella pianificazione della manutenzione, la manutenzione continua come di consueto nella risorsa.
Passaggi successivi
Per altre informazioni sulle rete WAN virtuale, vedere Informazioni su rete WAN virtuale.