Introduzione alla rete resistente dell'hub di Azure Stack

Panoramica della progettazione di rete

Progettazione della rete fisica

La soluzione resistente dell'hub di Azure Stack richiede un'infrastruttura fisica resiliente e a disponibilità elevata per supportare il funzionamento e i servizi. I collegamenti da ToR a Border sono limitati ai supporti SFP+ o SFP28 e a 1 GB, 10 GB o 25 GB di velocità. Rivolgersi al fornitore dell'hardware oem (Original Equipment Manufacturer) per la disponibilità.

Il diagramma seguente presenta la progettazione consigliata per l'hub di Azure Stack resistente.

Progettazione di rete logica

Una progettazione di rete logica rappresenta un'astrazione di un'infrastruttura di rete fisica. Vengono usati per organizzare e semplificare le assegnazioni di rete per host, macchine virtuali e servizi. Nell'ambito della creazione della rete logica, i siti di rete vengono creati per definire:

• reti locali virtuali (VLAN)
• Subnet IP
• Coppie subnet/VLAN IP

Tutti associati alla rete logica in ogni posizione fisica.

La tabella seguente illustra le reti logiche e gli intervalli di subnet IPv4 associati che è necessario pianificare:

Rete logica	Descrizione	Size
IP virtuale pubblico (VIP)	L'hub di Azure Stack resistente usa un totale di 31 indirizzi da questa rete. Otto indirizzi IP pubblici vengono usati per un piccolo set di servizi robusti dell'hub di Azure Stack e il resto viene usato dalle macchine virtuali tenant. Se si prevede di usare servizio app e i provider di risorse SQL, vengono usati altri 7 indirizzi. I rimanenti 15 INDIRIZZI IP sono riservati per i servizi di Azure futuri.	/26 (62 host)- /22 (1022 host) Consigliato = /24 (254 host)
Infrastruttura switch	Indirizzi IP da punto a punto per scopi di routing, interfacce di gestione dei commutatori dedicati e indirizzi di loopback assegnati al commutatore.	/26
Infrastruttura	Usato per i componenti interni robusti dell'hub di Azure Stack per comunicare.	/24
Privato	Usato per la rete di archiviazione, gli indirizzi VIP privati, i contenitori dell'infrastruttura e altre funzioni interne.	/20
Baseboard Management Controller (BMC)	Usato per comunicare con i controller di gestione della scheda di base negli host fisici.	/26

Infrastruttura di rete

L'infrastruttura di rete per l'hub di Azure Stack resistente è costituita da diverse reti logiche configurate nei commutatori. Il diagramma seguente illustra queste reti logiche e come si integrano con i commutatori top-of-rack (TOR), il controller di gestione delle schede di base e i commutatori border (customer network).

Diagramma di rete logica resistente dell'hub di Azure Stack:

Rete BMC

Questa rete è dedicata alla connessione di tutti i controller di gestione della scheda di base (noti anche come BMC o processori di servizio) alla rete di gestione. Gli esempi includono: iDRAC, iLO, iBMC e così via. Per comunicare con qualsiasi nodo BMC viene usato un solo account BMC. Se presente, l'host del ciclo di vita hardware (HLH) si trova in questa rete e può fornire software specifico dell'OEM per la manutenzione o il monitoraggio hardware.

HLH ospita anche la macchina virtuale di distribuzione (DVM). La DVM viene usata durante la distribuzione resistente dell'hub di Azure Stack e viene rimossa al termine della distribuzione. La DVM richiede l'accesso a Internet negli scenari di distribuzione connessa per testare, convalidare e accedere a più componenti. Questi componenti possono trovarsi all'interno e all'esterno della rete aziendale, ad esempio NTP, DNS e Azure. Per altre informazioni sui requisiti di connettività, vedere la sezione NAT nell'integrazione del firewall resistente dell'hub di Azure Stack.

Rete privata

La rete /20 (4096 host IP) è privata per l'area resistente dell'hub di Azure Stack. Non si espande oltre il commutatore di bordo dei dispositivi dell'area resistente dell'hub di Azure Stack. Questa rete è suddivisa in più subnet, ad esempio:

• Rete di archiviazione: una rete /25 (128 IP) usata per supportare l'uso del traffico di archiviazione SMB (Spaces Direct and Server Message Block) e della migrazione in tempo reale delle macchine virtuali.
• Rete IP virtuale interna: rete /25 dedicata agli indirizzi VIP solo interni per il servizio di bilanciamento del carico software.
• Rete contenitore: rete /23 (512 INDIRIZZI IP) dedicata al traffico solo interno tra contenitori che eseguono servizi di infrastruttura

Le dimensioni per la rete privata sono /20 (4096 IP) di spazio IP privato. Questa rete è privata per il sistema resistente dell'hub di Azure Stack. Non viene instradato oltre i dispositivi del commutatore di bordo del sistema resistente dell'hub di Azure Stack e può essere riutilizzato in più sistemi robusti dell'hub di Azure Stack. Anche se la rete è privata per l'hub di Azure Stack resistente, non deve sovrapporsi ad altre reti nel data center. Per indicazioni sullo spazio IP privato, è consigliabile seguire RFC 1918.

Lo spazio IP privato /20 è suddiviso in più reti, che consentono l'esecuzione dell'infrastruttura di sistema resistente dell'hub di Azure Stack nei contenitori nelle versioni future. Per informazioni dettagliate, vedere le note sulla versione 1910. Questo nuovo spazio IP privato consente di ridurre lo spazio IP instradabile necessario prima della distribuzione.

Rete dell'infrastruttura resistente dell'hub di Azure Stack

La rete /24 è dedicata ai componenti robusti dell'hub di Azure Stack interno, per comunicare e scambiare dati tra loro. Questa subnet può essere instradabile esternamente della soluzione resistente dell'hub di Azure Stack al data center. Non è consigliabile usare indirizzi IP instradabili Pubblici o Internet in questa subnet. Questa rete viene pubblicizzata al Border, ma la maggior parte dei relativi INDIRIZZI IP è protetta da elenchi di Controllo di accesso (ACL). Gli indirizzi IP consentiti per l'accesso si trovano all'interno di un intervallo ridotto, equivalente a una rete /27. Gli indirizzi IP ospitano servizi come il punto finale con privilegi (PEP) e il backup robusto dell'hub di Azure Stack.

Rete VIP pubblica

La rete VIP pubblica viene assegnata al controller di rete nell'hub di Azure Stack resistente. Non è una rete logica sul commutatore. Il bilanciamento del carico software usa il pool di indirizzi e assegna le reti /32 per i carichi di lavoro del tenant. Nella tabella di routing del commutatore questi indirizzi IP /32 vengono annunciati come route disponibili tramite BGP (Border Gateway Protocol). Questa rete contiene indirizzi pubblici accessibili esternamente. L'infrastruttura resistente dell'hub di Azure Stack riserva i primi 31 indirizzi da questa rete VIP pubblica, mentre il resto viene usato dalle macchine virtuali tenant. Le dimensioni di rete in questa subnet possono variare da un minimo di /26 (64 host) a un massimo di /22 (1022 host). È consigliabile pianificare una rete /24.

Commutare la rete dell'infrastruttura

La rete /26 è la subnet che contiene le subnet IP da punto a punto instradabili /30 (due indirizzi IP host) e i loopback. Si tratta di subnet /32 dedicate per la gestione dei commutatori in banda e l'ID router BGP. Questo intervallo di indirizzi IP deve essere instradabile all'esterno della soluzione resistente dell'hub di Azure Stack al data center. Gli indirizzi IP possono essere privati o pubblici.

Rete di gestione dei commutatori

La rete /29 (sei indirizzi IP host) è dedicata alla connessione delle porte di gestione dei commutatori. Questa rete consente l'accesso fuori banda per la distribuzione, la gestione e la risoluzione dei problemi. Viene calcolato dalla rete dell'infrastruttura del commutatore menzionata in precedenza.

Panoramica della progettazione DNS

Per accedere agli endpoint robusti dell'hub di Azure Stack (portale, amministratore, gestione, amministrazione) dall'esterno dell'hub di Azure Stack robusto, è necessario integrare i servizi DNS robusti dell'hub di Azure Stack con i server DNS che ospitano le zone DNS da usare nell'hub di Azure Stack resistente.

Spazio dei nomi DNS resistente dell'hub di Azure Stack

Quando si distribuisce l'hub di Azure Stack, è necessario fornire alcune informazioni importanti relative al DNS.

Campo	Descrizione	Esempio
Region	Posizione geografica della distribuzione resistente dell'hub di Azure Stack.	est
Nome di dominio esterno	Nome della zona da usare per la distribuzione resistente dell'hub di Azure Stack.	cloud.fabrikam.com
Nome di dominio interno	Nome della zona interna usata per i servizi di infrastruttura nell'hub di Azure Stack resistente. È integrato e privato del servizio directory (non raggiungibile dall'esterno della distribuzione resistente dell'hub di Azure Stack).	azurestack.local
Server d'inoltro DNS	Server DNS usati per inoltrare query DNS, zone DNS e record ospitati all'esterno dell'hub di Azure Stack robusti, nella intranet aziendale o in Internet pubblico. È possibile modificare il valore del server d'inoltro DNS con il cmdlet Set-AzSDnsForwarder dopo la distribuzione.
Prefisso di denominazione (facoltativo)	Il prefisso di denominazione che si vuole che i nomi dei computer delle istanze dell'istanza del ruolo dell'infrastruttura dell'hub di Azure Stack siano robusti. Se non specificato, il valore predefinito è "azs".	Azs

Il nome di dominio completo (FQDN) della distribuzione e degli endpoint dell'hub di Azure Stack è la combinazione del parametro Region e del parametro External Domain Name. Usando i valori degli esempi nella tabella precedente, il nome di dominio completo per questa distribuzione resistente dell'hub di Azure Stack sarà: east.cloud.fabrikam.com

Di conseguenza, alcuni degli endpoint per questa distribuzione saranno simili agli URL seguenti:

• https://portal.east.cloud.fabrikam.com
• https://adminportal.east.cloud.fabrikam.com

Per usare questo spazio dei nomi DNS di esempio per una distribuzione resistente dell'hub di Azure Stack, sono necessarie le condizioni seguenti:

• La zona fabrikam.com viene registrata con un registrar di dominio, un server DNS aziendale interno o entrambi. La registrazione dipende dai requisiti di risoluzione dei nomi.
• Nella zona fabrikam.com è presente il dominio figlio cloud.fabrikam.com.
• I server DNS che ospitano le zone fabrikam.com e cloud.fabrikam.com possono essere raggiunti dalla distribuzione resistente dell'hub di Azure Stack.

Per risolvere i nomi DNS per gli endpoint e le istanze dell'hub di Azure Stack robusti dall'esterno dell'hub di Azure Stack, è necessario integrare i server DNS. Inclusi i server che ospitano la zona DNS esterna per l'hub di Azure Stack robusti, con i server DNS che ospitano la zona padre da usare.

Etichette dei nomi DNS

Hub di Azure Stack resistente supporta l'aggiunta di un'etichetta di nome DNS a un indirizzo IP pubblico per consentire la risoluzione dei nomi per gli indirizzi IP pubblici. Le etichette DNS sono un modo pratico per consentire agli utenti di raggiungere app e servizi ospitati nell'hub di Azure Stack in base al nome. L'etichetta del nome DNS usa uno spazio dei nomi leggermente diverso rispetto agli endpoint dell'infrastruttura. Dopo lo spazio dei nomi di esempio precedente, lo spazio dei nomi per le etichette dei nomi DNS sarà * .east.cloudapp.cloud.fabrikam.com.

Se un tenant specifica Myapp nel campo nome DNS di una risorsa indirizzo IP pubblico, crea un record A per myapp nella zona east.cloudapp.cloud.fabrikam.com nel server DNS esterno resistente dell'hub di Azure Stack. Il nome di dominio completo risultante sarà: myapp.east.cloudapp.cloud.fabrikam.com.

Se si vuole sfruttare questa funzionalità e usare questo spazio dei nomi, è necessario integrare i server DNS. Inclusi i server che ospitano la zona DNS esterna per l'hub di Azure Stack sono robusti e i server DNS che ospitano anche la zona padre da usare. Questo spazio dei nomi è diverso da quello usato per gli endpoint servizio robusti dell'hub di Azure Stack, quindi è necessario creare una delega aggiuntiva o una regola di inoltro condizionale.

Per altre informazioni sul funzionamento dell'etichetta del nome DNS, vedere "Uso di DNS" nell'hub di Azure Stack resistente.

Risoluzione e delega

Esistono due tipi di server DNS:

• Un server DNS autorevole ospita le zone DNS e risponde alle query DNS solo per i record presenti in tali zone.
• Un server DNS ricorsivo non ospita le zone DNS. ma risponde a tutte le query DNS, chiamando i server DNS autorevoli per raccogliere tutti i dati necessari.

L'hub di Azure Stack robusto include server DNS autorevoli e ricorsivi. I server ricorsivi vengono usati per risolvere i nomi di tutto tranne la zona privata interna e la zona DNS pubblica esterna per la distribuzione resistente dell'hub di Azure Stack.

Risoluzione dei nomi DNS esterni dall'hub di Azure Stack resistente

Per risolvere i nomi DNS per gli endpoint esterni all'hub di Azure Stack robusto (ad esempio: www.bing.com), è necessario fornire server DNS per l'hub di Azure Stack robusti per inoltrare le richieste DNS, per cui l'hub di Azure Stack non è autorevole. I server DNS a cui l'hub di Azure Stack ha eseguito le richieste di inoltro sono necessari nel foglio di lavoro distribuzione (nel campo Server d'inoltro DNS). Specificare almeno due server in questo campo per assicurare la tolleranza di errore. Senza questi valori, la distribuzione resistente dell'hub di Azure Stack ha esito negativo. È possibile modificare i valori del server di inoltro DNS con il cmdlet Set-AzSDnsForwarder dopo la distribuzione.

Panoramica della progettazione del firewall

È consigliabile usare un dispositivo firewall per proteggere l'hub di Azure Stack resistente. I firewall consentono di difendersi in caso di attacchi DDOS (Distributed Denial of Service), di rilevamento delle intrusioni e di ispezione del contenuto. Possono tuttavia diventare anche un collo di bottiglia della velocità effettiva per i servizi di archiviazione di Azure, ad esempio BLOB, tabelle e code.

Se viene usata una modalità di distribuzione disconnessa, è necessario pubblicare l'endpoint AD FS. Per altre informazioni, vedere l'articolo Sull'identità di integrazione del data center.

Gli endpoint di Azure Resource Manager (amministratore), del portale di amministrazione e di Key Vault (amministratore) non richiedono necessariamente la pubblicazione esterna. Ad esempio, come provider di servizi, è possibile limitare la superficie di attacco amministrando solo l'hub di Azure Stack resistente dall'interno della rete e non da Internet.

Per le organizzazioni aziendali, la rete esterna può essere la rete aziendale esistente. In questo scenario, è necessario pubblicare gli endpoint per gestire l'hub di Azure Stack resistente dalla rete aziendale.

Network Address Translation

Nat (Network Address Translation) è il metodo consigliato per consentire alla macchina virtuale di distribuzione (DVM) di accedere alle risorse esterne durante la distribuzione. Anche per le macchine virtuali ERCS (Emergency Recovery Console) o l'endpoint con privilegi (PEP) durante la registrazione e la risoluzione dei problemi.

Il NAT può anche offrire un'alternativa agli indirizzi IP pubblici nella rete esterna o agli indirizzi VIP pubblici. Non è tuttavia consigliabile ricorrere a questa soluzione perché limita l'esperienza utente del tenant e aumenta il livello di complessità. Un'opzione possibile consiste in un NAT uno-a-uno che richiede comunque un indirizzo IP pubblico per ogni indirizzo IP utente nel pool. Un'altra opzione consiste in un NAT molti-a-uno che richiede una regola NAT per ogni indirizzo VIP utente per tutte le porte che un utente può usare.

Di seguito sono indicati alcuni degli svantaggi derivanti dall'uso di NAT per un indirizzo VIP pubblico:

• Sovraccarico durante la gestione delle regole del firewall, in quanto gli utenti controllano i propri endpoint e le regole di pubblicazione nello stack SDN (Software-Defined Networking). Gli utenti devono contattare l'operatore robusto dell'hub di Azure Stack per pubblicare i propri INDIRIZZI VIP e aggiornare l'elenco delle porte.
• Anche se l'uso del NAT limita l'esperienza utente, consente all'operatore di avere un controllo completo sulla pubblicazione delle richieste.
• Per gli scenari di cloud ibrido con Azure, tenere presente che Azure non supporta la configurazione di un tunnel VPN verso un endpoint tramite NAT.

Intercettazione SSL

È attualmente consigliabile disabilitare qualsiasi intercettazione SSL (ad esempio l'offload di decrittografia) in tutto il traffico resistente dell'hub di Azure Stack. Se è supportato negli aggiornamenti futuri, verranno fornite indicazioni su come abilitare l'intercettazione SSL per l'hub di Azure Stack resistente.

Scenario del firewall di distribuzione Edge

In una distribuzione perimetrale, l'hub di Azure Stack è distribuito direttamente dietro il router perimetrale o il firewall. In questi scenari è supportato che il firewall sia al di sopra del bordo (scenario 1) in cui supporta sia le configurazioni del firewall attivo-attivo che attivo-passivo. Può anche fungere da dispositivo di bordo (scenario 2), in cui supporta solo la configurazione del firewall attivo-attivo. Lo scenario 2 si basa su ECMP (Equal Cost Multi Path) con BGP o routing statico per il failover.

Gli indirizzi IP instradabili pubblici vengono specificati per il pool VIP pubblico dalla rete esterna, in fase di distribuzione. Ai fini della sicurezza, gli indirizzi IP instradabili pubblici non sono consigliati in nessun'altra rete in uno scenario perimetrale. Questo scenario consente a un utente di sperimentare l'esperienza cloud autonoma completa come in un cloud pubblico quale Azure.

Scenario di firewall di rete perimetrale o intranet aziendale

In una distribuzione intranet aziendale o perimetrale, l'hub di Azure Stack è distribuito in un firewall a più zone o tra il firewall perimetrale e il firewall di rete aziendale interno. Il traffico viene quindi distribuito tra la rete perimetrale protetta e le zone non protette, come descritto di seguito:

• Zona sicura: rete interna che usa indirizzi IP interni o aziendali instradabili. La rete sicura può essere divisa. Può avere accesso in uscita a Internet tramite NAT del firewall. In genere è accessibile dall'interno del data center tramite la rete interna. Tutte le reti robuste dell'hub di Azure Stack devono trovarsi nella zona sicura, ad eccezione del pool VIP pubblico della rete esterna.
• Zona perimetrale. La rete perimetrale è la posizione in cui vengono in genere distribuite app esterne o con connessione Internet, ad esempio server Web. In genere viene monitorato da un firewall per evitare attacchi come DDoS e intrusioni (hacking) consentendo comunque il traffico in ingresso specificato da Internet. Solo il pool VIP pubblico della rete esterna dell'hub di Azure Stack deve risiedere nella zona della rete perimetrale.
• Zona non protetta. Rete esterna, Internet. La distribuzione dell'hub di Azure Stack resistente nella zona non protetta non è consigliata.

Panoramica della progettazione VPN

Anche se la VPN è un concetto utente, esistono alcune considerazioni importanti che un proprietario e un operatore della soluzione devono conoscere.

Prima di poter inviare il traffico di rete tra la rete virtuale di Azure e il sito locale, è necessario creare un gateway di rete virtuale (VPN) per la rete virtuale.

Un gateway VPN è un tipo di gateway di rete virtuale che invia traffico crittografato tramite una connessione pubblica. È possibile usare i gateway VPN per inviare il traffico in modo sicuro tra una rete virtuale nell'hub di Azure Stack e una rete virtuale in Azure. È anche possibile inviare il traffico in modo sicuro tra una rete virtuale e un'altra rete connessa a un dispositivo VPN.

Quando si crea un gateway di rete virtuale, si specifica il tipo di gateway che si vuole creare. L'hub di Azure Stack robusto supporta un tipo di gateway di rete virtuale: il tipo vpn .

Ogni rete virtuale può avere due gateway di rete virtuale, ma solo uno per ogni tipo. A seconda delle impostazioni scelte, è possibile creare più connessioni a un singolo gateway VPN. Un esempio di questo tipo di configurazione è una configurazione di connessione multisito.

Prima di creare e configurare gateway VPN per l'hub di Azure Stack resistente, esaminare le considerazioni per la rete resistente dell'hub di Azure Stack. Si apprenderà come le configurazioni per l'hub di Azure Stack differiscono da Azure.

In Azure, la velocità effettiva della larghezza di banda per lo SKU del gateway VPN scelta deve essere divisa tra tutte le connessioni connesse al gateway. Nell'hub di Azure Stack, tuttavia, il valore della larghezza di banda per lo SKU del gateway VPN viene applicato a ogni risorsa di connessione connessa al gateway. Ad esempio:

• In Azure, lo SKU del gateway VPN di base può contenere circa 100 Mbps di velocità effettiva aggregata. Se si creano due connessioni al gateway VPN e una connessione usa 50 Mbps di larghezza di banda, 50 Mbps è disponibile per l'altra connessione.
• Nell'hub di Azure Stack resistente, ogni connessione allo SKU del gateway VPN di base viene allocata a 100 Mbps di velocità effettiva.

Tipi di VPN

Quando si crea il gateway di rete virtuale per una configurazione di gateway VPN, è necessario specificare un tipo di VPN. Il tipo di VPN scelto dipende dalla topologia di connessione che si desidera creare. Un tipo di VPN può anche dipendere dall'hardware in uso. Le configurazioni S2S richiedono un dispositivo VPN. Alcuni dispositivi VPN supportano solo un determinato tipo di VPN.

Importante

Attualmente, l'hub di Azure Stack è resistente solo supporta il tipo di VPN basato su route. Se il dispositivo supporta solo VPN basate su criteri, le connessioni a tali dispositivi dall'hub di Azure Stack non sono supportate. Inoltre, l'hub di Azure Stack non supporta l'uso di selettori di traffico basati su criteri per i gateway basati su route, perché le configurazioni dei criteri IPSec/IKE personalizzate non sono supportate.

• PolicyBased: le VPN basate su criteri crittografano e indirizzano i pacchetti tramite tunnel IPsec, in base ai criteri IPsec. I criteri vengono configurati con le combinazioni di prefissi di indirizzo tra la rete locale e la rete virtuale resistente dell'hub di Azure Stack. Il criterio, o selettore di traffico, è in genere un elenco di accesso nella configurazione del dispositivo VPN. PolicyBased è supportato in Azure, ma non nell'hub di Azure Stack resistente.
• RouteBased: le VPN basate su route usano route configurate nella tabella di inoltro IP o routing. Le route indirizzano i pacchetti alle interfacce del tunnel corrispondenti. Le interfacce tunnel consentono quindi di crittografare o decrittografare i pacchetti all'interno e all'esterno dei tunnel. Il criterio o il selettore di traffico per le VPN RouteBased sono configurati come any-to-any (o usare caratteri jolly). Per impostazione predefinita, non possono essere modificati. Il valore di un tipo VPN RouteBased è RouteBased.

Configurazione di un gateway VPN

Una connessione gateway VPN si basa su diverse risorse configurate con impostazioni specifiche. La maggior parte di queste risorse può essere configurata separatamente, ma in alcuni casi deve essere configurata in un ordine specifico.

Impostazioni

Le impostazioni scelte per ogni risorsa sono fondamentali per la creazione di una connessione riuscita.

Questo articolo consente di comprendere quanto segue:

• Tipi di gateway, tipi di VPN e tipi di connessione.
• Subnet del gateway, gateway di rete locali e altre impostazioni delle risorse che è possibile prendere in considerazione.

Diagrammi delle topologie di connessione

Sono disponibili configurazioni diverse per le connessioni gateway VPN. Determinare la configurazione più adatta alle proprie esigenze. Nelle sezioni seguenti è possibile visualizzare informazioni e diagrammi di topologia sulle connessioni gateway VPN seguenti:

• Modello di distribuzione disponibile
• Strumenti di configurazione disponibili
• Collegamenti che visualizzano direttamente un articolo, se disponibile

I diagrammi e le descrizioni delle sezioni seguenti consentono di selezionare una topologia di connessione in base alle esigenze. I diagrammi mostrano le topologie di base principali, ma è possibile creare configurazioni più complesse usando i diagrammi come guida.

Da sito a sito e multisito (tunnel VPN IPsec/IKE)

Da sito a sito

Una connessione gateway VPN da sito a sito (S2S) è una connessione tramite tunnel VPN IPsec/IKE (IKEv2). Questo tipo di connessione richiede un dispositivo VPN che si trova in locale e a cui viene assegnato un indirizzo IP pubblico. Questo dispositivo non può trovarsi dietro un NAT. Le connessioni S2S possono essere usate per le configurazioni cross-premise e ibride.

multisito

Una connessione multisito è una variante della connessione da sito a sito. È possibile creare più di una connessione VPN dal gateway di rete virtuale, che in genere connette a più siti locali. Quando si usano più connessioni, è necessario usare un tipo VPN basato su route (noto come gateway dinamico quando si usano reti virtuali classiche). Poiché ogni rete virtuale può avere un solo gateway VPN, tutte le connessioni che usano il gateway condividono la larghezza di banda disponibile.

SKU del gateway

Quando si crea un gateway di rete virtuale per l'hub di Azure Stack robusto, si specifica lo SKU del gateway che si vuole usare. Sono supportati gli SKU del gateway VPN seguenti:

• Basic
• Standard
• Prestazioni elevate

Se si seleziona uno SKU del gateway superiore, vengono allocate più CPU e larghezza di banda di rete al gateway. Di conseguenza, il gateway può supportare una velocità effettiva di rete superiore alla rete virtuale.

L'hub di Azure Stack robusto non supporta lo SKU del gateway Ultra Performance, che viene usato esclusivamente con ExpressRoute.

Quando si seleziona lo SKU, tenere presente quanto segue:

• L'hub di Azure Stack resistente non supporta i gateway basati su criteri.
• BGP non è supportato nello SKU Basic.
• Le configurazioni coesistenti del gateway ExpressRoute-VPN non sono supportate nell'hub di Azure Stack resistente.

Disponibilità del gateway

Gli scenari a disponibilità elevata possono essere configurati solo nello SKU di connessione gateway ad alte prestazioni . A differenza di Azure, che offre disponibilità tramite configurazioni attive/attive e attive/passive, l'hub di Azure Stack è resistente solo supporta la configurazione attiva/passiva.

Failover

Nell'hub di Azure Stack sono presenti tre macchine virtuali dell'infrastruttura del gateway multi-tenant. Due di queste macchine virtuali sono in modalità attiva e la terza è in modalità ridondante. Le macchine virtuali attive consentono la creazione di connessioni VPN e la macchina virtuale ridondante accetta solo connessioni VPN se si verifica un failover. Se una macchina virtuale gateway attiva non è più disponibile, la connessione VPN esegue il failover alla macchina virtuale ridondante dopo un breve periodo (pochi secondi) di perdita di connessione.

Velocità effettiva aggregata stimata per SKU

La tabella seguente illustra i tipi di gateway e la velocità effettiva aggregata stimata per SKU del gateway:

	Velocità effettiva del gateway VPN (1)	Tunnel IPsec massimi del gateway VPN (2)
SKU Basic(3)	100 Mbps	20
SKU Standard	100 Mbps	20
SKU ad alte prestazioni	200 Mbps	10

Note sulla tabella

(1) - La velocità effettiva VPN non è una velocità effettiva garantita per le connessioni cross-premise in Internet. È la misura massima possibile della velocità effettiva.
(2) - Il numero massimo di tunnel è il totale per la distribuzione dell'hub di Azure Stack per tutte le sottoscrizioni.
(3) - Il routing BGP non è supportato per lo SKU di base.

Importante

È possibile creare una sola connessione VPN da sito a sito tra due distribuzioni robuste dell'hub di Azure Stack. Ciò è dovuto a una limitazione nella piattaforma che consente solo una singola connessione VPN allo stesso indirizzo IP. Poiché l'hub di Azure Stack è robusto sfrutta il gateway multi-tenant, che usa un singolo INDIRIZZO IP pubblico per tutti i gateway VPN nel sistema robusto dell'hub di Azure Stack, può essere presente una sola connessione VPN tra due sistemi robusti dell'hub di Azure Stack.

Questa limitazione si applica anche alla connessione di più di una connessione VPN da sito a sito a qualsiasi gateway VPN che usa un singolo indirizzo IP. L'hub di Azure Stack non consente la creazione di più risorse del gateway di rete locale usando lo stesso indirizzo IP.**

Parametri IPsec/IKE

Quando si configura una connessione VPN nell'hub di Azure Stack, è necessario configurare la connessione a entrambe le estremità. Se si configura una connessione VPN tra l'hub di Azure Stack e un dispositivo hardware, tale dispositivo potrebbe richiedere impostazioni aggiuntive. Ad esempio, un commutatore o un router che agisce come gateway VPN.

A differenza di Azure, che supporta più offerte sia come iniziatore che come risponditore, l'hub di Azure Stack supporta solo un'offerta per impostazione predefinita. Se è necessario usare impostazioni IPSec/IKE diverse per usare il dispositivo VPN, sono disponibili altre impostazioni per configurare manualmente la connessione.

Parametri della Fase 1 di IKE (Modalità principale)

Proprietà	Valore
Versione IKE	IKEv2
Diffie-Hellman Group	ECP384
Metodo di autenticazione	Chiave precondivisa
Algoritmi di crittografia e di hash	AES256, SHA384
Durata dell'associazione di sicurezza (tempo)	28.800 secondi

Parametri della Fase 2 di IKE (Modalità rapida)

Proprietà	Valore
Versione IKE	IKEv2
Algoritmi di crittografia & hashing (crittografia)	GCMAES256
Algoritmi di crittografia & hashing (autenticazione)	GCMAES256
Durata dell'associazione di sicurezza (tempo)	27.000 secondi
Durata SA (Kilobyte)	33,553,408
Perfect Forward Secrecy (PFS)	ECP384
Rilevamento peer inattivo	Supportato

Configurare criteri di connessione IPSec/IKE personalizzati

Lo standard di protocollo IPsec e IKE supporta un'ampia gamma di algoritmi di crittografia in varie combinazioni. Per vedere quali parametri sono supportati nell'hub di Azure Stack per soddisfare i requisiti di conformità o di sicurezza, vedere Parametri IPsec/IKE.

Questo articolo fornisce istruzioni su come creare e configurare un criterio IPsec/IKE e applicare a una connessione nuova o esistente.

Considerazioni

Si notino le importanti considerazioni seguenti quando si usano questi criteri:

• I criteri IPsec/IKE funzionano solo negli SKU del gateway Standard e HighPerformance (basato su route).
• Per una determinata connessione è possibile specificare una sola combinazione di criteri.
• È necessario specificare tutti gli algoritmi e i parametri sia per IKE (modalità principale) che per IPsec (modalità rapida). Le specifiche dei criteri parziali non sono consentite.
• Consultare le specifiche del fornitore del dispositivo VPN per verificare che i criteri siano supportati dai dispositivi VPN locali. Le connessioni da sito a sito non possono essere stabilite se i criteri non sono compatibili.

Flusso di lavoro per creare e impostare criteri IPsec/IKE

Questa sezione descrive il flusso di lavoro necessario per creare e aggiornare i criteri IPsec/IKE in una connessione VPN da sito a sito:

1. Creare una rete virtuale e un gateway VPN.
2. Creare un gateway di rete locale per la connessione cross-premise.
3. Creare un criterio IPsec/IKE con algoritmi e parametri selezionati.
4. Creare una connessione IPSec con i criteri IPsec/IKE.
5. Aggiungere/aggiornare/rimuovere un criterio IPsec/IKE per una connessione esistente.

Algoritmi di crittografia supportati e punti di forza delle chiavi

Nella tabella seguente sono elencati gli algoritmi di crittografia supportati e i punti di forza chiave configurabili dai clienti dell'hub di Azure Stack:

IPsec/IKEv2	Opzioni
Crittografia IKEv2	AES256, AES192, AES128, DES3, DES
Integrità IKEv2	SHA384, SHA256, SHA1, MD5
Gruppo DH	ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, Nessuno
Crittografia IPsec	GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, None
Integrità IPsec	GCMASE256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
Gruppo PFS	PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, None
Durata associazione di sicurezza in modalità rapida	(Facoltativo: se non diversamente specificato, vengono usati i valori predefiniti)
	Secondi (integer; min. 300/default 27.000 secondi)
	KBytes (integer; min. 1024/default 102.400.000 KBytes)
Selettore di traffico	I selettore del traffico basato su criteri non sono supportati nell'hub di Azure Stack.

La configurazione del dispositivo VPN locale deve contenere o corrispondere agli algoritmi e ai parametri seguenti specificati nei criteri IPsec/IKE di Azure:

• Algoritmo di crittografia IKE (modalità principale/fase 1).
• Algoritmo di integrità IKE (modalità principale/fase 1).
• Gruppo DH (modalità principale/fase 1).
• Algoritmo di crittografia IPsec (modalità rapida/fase 2).
• Algoritmo di integrità IPsec (modalità rapida/fase 2).
• Gruppo PFS (modalità rapida/fase 2).
• Le durate sa sono solo specifiche locali, che non devono corrispondere.

Se GCMAES viene usato come per l'algoritmo di crittografia IPsec, è necessario selezionare lo stesso algoritmo GCMAES e la stessa lunghezza della chiave per l'integrità IPsec. Ad esempio, l'uso di GCMAES128 per entrambi.

Nella tabella precedente:

• IKEv2 corrisponde alla modalità principale o alla fase 1.
• IPsec corrisponde alla modalità rapida o alla fase 2.
• Il gruppo DH specifica il gruppo di Diffie-Hellmen utilizzato nella modalità principale o nella fase 1.
• Il gruppo PFS specifica il gruppo di Diffie-Hellmen utilizzato in modalità rapida o fase 2.
• La durata dell'sa della modalità principale IKEv2 è fissa a 28.800 secondi nei gateway VPN robusti dell'hub di Azure Stack.

La tabella seguente elenca i gruppi di Diffie-Hellman corrispondenti supportati dal criterio personalizzato:

Gruppo Diffie-Hellman	DHGroup	PFSGroup	Lunghezza chiave
1	DHGroup1	PFS1	MODP a 768 bit
2	DHGroup2	PFS2	MODP a 1024 bit
14	DHGroup14	PFS2048	MODP a 2048 bit
	DHGroup2048
19	ECP256	ECP256	ECP a 256 bit
20	ECP384	ECP384	ECP a 384 bit
24	DHGroup24	PFS24	MODP a 2048 bit

Connettere l'hub di Azure Stack resistente ad Azure usando Azure ExpressRoute

Panoramica, presupposti e prerequisiti

Azure ExpressRoute permette di estendere le reti locali al cloud Microsoft. Si usa una connessione privata fornita da un provider di connettività. ExpressRoute non è una connessione VPN tramite Internet pubblico.

Per altre informazioni su Azure ExpressRoute, vedere Panoramica di ExpressRoute.

Presupposti

Questo articolo presuppone quanto segue:

• Si ha una conoscenza funzionante di Azure.
• Si ha una conoscenza di base dell'hub di Azure Stack resistente.
• Si ha una conoscenza di base della rete.

Prerequisiti

Per connettere l'hub di Azure Stack robusto e Azure usando ExpressRoute, è necessario soddisfare i requisiti seguenti:

• Circuito ExpressRoute di cui è stato effettuato il provisioning tramite un provider di connettività.
• Una sottoscrizione di Azure per creare un circuito ExpressRoute e reti virtuali in Azure.
• Router che supporta:
  • Connessioni VPN da sito a sito tra l'interfaccia LAN e il gateway multi-tenant resistente dell'hub di Azure Stack.
  • creazione di più VDF (routing virtuale e inoltro) se sono presenti più tenant nella distribuzione resistente dell'hub di Azure Stack.
• Router con:
  • Una porta WAN connessa al circuito ExpressRoute.
  • Una porta LAN connessa al gateway multi-tenant dell'hub di Azure Stack.

Architettura di rete ExpressRoute

La figura seguente illustra gli ambienti robusti dell'hub di Azure Stack e Azure dopo aver completato la configurazione di ExpressRoute usando gli esempi in questo articolo:

La figura seguente illustra come più tenant si connettono dall'infrastruttura resistente dell'hub di Azure Stack tramite il router ExpressRoute ad Azure: