Introduzione alla rete Modular Datacenter (MDC)

Contenuto dei pacchetti

La soluzione Azure Modular Datacenter (MDC) viene fornita con le apparecchiature di rete aggiuntive a cui si fa riferimento in questo articolo. Questa attrezzatura viene usata per connettere il contenitore alla rete.

Verificare che l'ottica del commutatore corrisponda all'ambiente in uso.

Quantità	TIPO	Modello
12	12x QSFP-40G	"SR"
12	12x SFP+ 10 GB	"SR"
12	12x SFP 1G	"SR"
12	12x QSFP-40G	LR
12	12x SFP+ 10 GB	LR
12	12x SFP 1G	LR

Panoramica della progettazione di rete

Progettazione di rete fisica

La soluzione MDC richiede un'infrastruttura fisica resiliente e a disponibilità elevata per supportare il funzionamento e i servizi. I collegamenti da top-of-rack (TOR) ai commutatori di bordo sono limitati ai supporti SFP+ o SFP28 e a velocità di 1 GB, 10 GB o 40 GB.

Il diagramma seguente presenta la progettazione consigliata per MDC.

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 di aree locali virtuali (VLAN).
• Subnet IP.
• Coppie subnet IP/VLAN.

Tutte queste VLAN e subnet sono associate 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	Dimensione
IP virtuale pubblico (VIP)	MDC usa un totale di 31 indirizzi da questa rete. Otto indirizzi IP pubblici vengono usati per un piccolo set di servizi MDC e gli altri vengono usati dalle macchine virtuali tenant. Se si prevede di usare app Azure Service e i provider di risorse SQL, vengono usati altri sette 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 a scopo di routing, interfacce di gestione del commutatore dedicate e indirizzi di loopback assegnati al commutatore.	/26
Infrastruttura	Usato per comunicare i componenti interni di MDC.	/24
Privata	Usato per la rete di archiviazione, indirizzi VIP privati, contenitori dell'infrastruttura e altre funzioni interne.	/20
Baseboard Management Controller (BMC)	Usato per comunicare con i bare metal negli host fisici.	/26
Isilon	Usato per comunicare con lo spazio di archiviazione Isilon.	1x /25 TOR 1x /25 BMC (gestione)

Infrastruttura di rete

L'infrastruttura di rete per MDC è 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), BMC e border (customer network).

Rete BMC

Questa rete è dedicata alla connessione di tutti i bare metal (noti anche come processori di servizi) alla rete di gestione. Gli esempi includono iDRAC, iLO e iBMC. Viene usato un solo account BMC per comunicare con qualsiasi nodo BMC. Se presente, l'host del ciclo di vita hardware (HLH) si trova in questa rete e potrebbe fornire software specifico dell'OEM per la manutenzione o il monitoraggio dell'hardware.

HLH ospita anche la macchina virtuale di distribuzione (DVM). La DVM viene usata durante la distribuzione MDC e viene rimossa al termine della distribuzione. La DVM richiede l'accesso a Internet negli scenari di distribuzione connessi per testare, convalidare e accedere a più componenti. Questi componenti possono trovarsi all'interno e all'esterno della rete aziendale. Gli esempi includono NTP, Domain Name System (DNS) e Azure. Per altre informazioni sui requisiti di connettività, vedere la sezione NAT (Network Address Translation) in Integrazione del firewall MDC.

Rete privata

La rete /20 (4096 host IP) è privata per l'area MDC. Non si espande oltre i dispositivi del commutatore di bordo dell'area MDC. Questa rete è suddivisa in più subnet, ad esempio:

• Rete di archiviazione: rete di archiviazione /25 (128 IP) usata per supportare l'uso del traffico di archiviazione di Spazi di archiviazione diretta e SMB (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: una rete /23 (512 IP) dedicata al traffico solo interno tra contenitori che eseguono servizi di infrastruttura.

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

Lo spazio IP privato /20 è suddiviso in più reti che consentono l'esecuzione dell'infrastruttura di sistema MDC nei contenitori nelle versioni future. Questo spazio IP privato consente di ridurre lo spazio IP instradabile necessario prima della distribuzione.

Rete dell'infrastruttura MDC

La rete /24 è dedicata ai componenti MDC interni in modo che possano comunicare e scambiare dati tra loro. Questa subnet può essere instradabile esternamente alla soluzione MDC nel data center. Non è consigliabile usare indirizzi IP instradabili pubblici o Internet in questa subnet. Questa rete viene pubblicizzata al confine, ma la maggior parte dei relativi INDIRIZZI IP è protetta dagli elenchi di controllo di accesso. 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 l'endpoint con privilegi (PEP) e il backup MDC.

Rete VIP pubblica

La rete VIP pubblica viene assegnata al controller di rete in MDC. 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 il protocollo BGP (Border Gateway Protocol). Questa rete contiene indirizzi pubblici accessibili esternamente. L'infrastruttura MDC riserva i primi 31 indirizzi da questa rete VIP pubblica, mentre le altre vengono usate 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 (1.022 host). È consigliabile pianificare una rete /24.

Rete dell'infrastruttura switch

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

Rete di gestione 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 nella sezione precedente.

Rete Isilon

Esistono due reti /25. Uno si trova sull'interruttore TOR e uno /25 viene usato sul commutatore BMC per la gestione.

Panoramica della progettazione DNS

Per accedere agli endpoint MDC (portale, amministratore, gestione e amministrazione) dall'esterno di MDC, è necessario integrare i servizi DNS MDC con i server DNS che ospitano le zone DNS da usare in MDC.

Spazio dei nomi DNS MDC

Quando si distribuisce la soluzione MDC, è necessario fornire alcune informazioni importanti relative al DNS.

Campo	Descrizione	Esempio
Paese	Posizione geografica della distribuzione MDC.	A est
Nome di dominio esterno	Nome della zona da usare per la distribuzione MDC.	cloud.fabrikam.com
Nome di dominio interno	Nome della zona interna usata per i servizi di infrastruttura nel cluster MDC. È integrato nel servizio directory e privato (non raggiungibile dall'esterno della distribuzione MDC).	azurestack.local
Server d'inoltro DNS	Server DNS usati per inoltrare query DNS, zone DNS e record ospitati all'esterno di MDC, 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 dell'istanza del ruolo dell'infrastruttura MDC abbiano. Se non specificato, il valore predefinito è azs.	azs

Il nome di dominio completo (FQDN) della distribuzione e degli endpoint MDC è la combinazione del parametro region e del parametro del nome di dominio esterno. Usando i valori degli esempi nella tabella precedente, il nome di dominio completo per questa distribuzione MDC sarà east.cloud.fabrikam.com.

Alcuni degli endpoint per questa distribuzione sono 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 MDC, sono necessarie le condizioni seguenti:

• La zona fabrikam.com è 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 MDC.

Per risolvere i nomi DNS per endpoint e istanze MDC dall'esterno di MDC, è necessario integrare i server DNS. Includere server che ospitano la zona DNS esterna per MDC con i server DNS che ospitano la zona padre da usare.

Etichette dei nomi DNS

MDC supporta l'aggiunta di un'etichetta del 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 in MDC 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 etichetta del 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 MDC. L'FQDN 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. Includere server che ospitano la zona DNS esterna per MDC e i server DNS che ospitano anche la zona padre da usare. Questo spazio dei nomi è diverso da quello usato per gli endpoint del servizio MDC, 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" nella documentazione di MDC.

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.

MDC include server DNS autorevoli e ricorsivi. I server ricorsivi vengono usati per risolvere i nomi di tutti gli elementi, ad eccezione della zona privata interna e della zona DNS pubblica esterna per la distribuzione MDC.

Risolvere i nomi DNS esterni da MDC

Per risolvere i nomi DNS per gli endpoint esterni a MDC (ad esempio, www.bing.com), è necessario fornire i server DNS per MDC per inoltrare le richieste DNS, per cui MDC non è autorevole. I server DNS a cui MDC inoltra le richieste sono necessari nel foglio di lavoro della 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 MDC ha esito negativo. È possibile modificare i valori del server d'inoltro DNS con il cmdlet Set-AzSDnsForwarder dopo la distribuzione.

Panoramica della progettazione del firewall

È consigliabile usare un dispositivo firewall per proteggere MDC. I firewall possono aiutare a difendersi da elementi come attacchi DDoS (Distributed Denial of Service), rilevamento delle intrusioni e ispezione del contenuto. Possono anche diventare 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 di Active Directory Federation Services. Per altre informazioni, vedere l'articolo identità di integrazione del data center.

Gli endpoint di Azure Resource Manager (amministratore), del portale di amministrazione e di Azure Key Vault (amministratore) non richiedono necessariamente la pubblicazione esterna. Ad esempio, come provider di servizi, è possibile limitare la superficie di attacco amministrando solo MDC 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 il funzionamento di MDC dalla rete aziendale.

Network Address Translation

È consigliabile usare il metodo NAT per consentire alla DVM di accedere alle risorse esterne durante la distribuzione. È anche consigliabile usare NAT per le macchine virtuali ERCS (Emergency Recovery Console) o PEP durante la registrazione e la risoluzione dei problemi.

NAT può anche essere un'alternativa agli indirizzi IP pubblici nella rete esterna o indirizzi VIP pubblici. Questa opzione non è consigliata perché limita l'esperienza utente del tenant e aumenta la complessità. Un'opzione è un NAT uno-a-uno che richiede ancora un indirizzo IP pubblico per utente nel pool. Un'altra opzione è un NAT molti-a-uno che richiede una regola NAT per ogni indirizzo VIP utente per tutte le porte che un utente potrebbe usare.

Alcuni aspetti negativi dell'uso di NAT per l'indirizzo VIP pubblico sono:

• Sovraccarico durante la gestione delle regole del firewall, perché gli utenti controllano gli endpoint e le regole di pubblicazione nello stack di rete software-defined. Gli utenti devono contattare l'operatore MDC 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) su tutto il traffico MDC. Se è supportato negli aggiornamenti futuri, verranno fornite indicazioni su come abilitare l'intercettazione SSL per MDC.

Scenario del firewall di distribuzione Edge

In una distribuzione perimetrale, MDC viene distribuito direttamente dietro il router perimetrale o il firewall. In questi scenari, è supportato che il firewall si trova al di sopra del bordo (scenario 1) in cui supporta le configurazioni del firewall attivo-attivo e 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 percorsi multipli di uguale costo con BGP o routing statico per il failover.

Gli indirizzi IP instradabili pubblici vengono specificati per il pool di indirizzi VIP pubblici dalla rete esterna in fase di distribuzione. Per motivi di 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, MDC viene distribuito in un firewall multizonato o tra il firewall perimetrale e il firewall di rete aziendale interno. Il traffico viene quindi distribuito tra la rete sicura, perimetrale (o rete perimetrale) e le zone non sicure, come descritto:

• 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 MDC 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 come i 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 di MDC deve trovarsi nella zona della rete perimetrale.
• Area non protetta: la rete esterna, Internet. Non è consigliabile distribuire MDC nella zona non protetta.

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 in MDC 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. MDC supporta un tipo di gateway di rete virtuale: il tipo di 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 i gateway VPN per MDC, esaminare le considerazioni relative alla rete MDC. Si apprenderà come le configurazioni per MDC 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. In MDC, 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.
• In MDC 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ò dipendere anche dall'hardware in uso. Le configurazioni da sito a sito richiedono un dispositivo VPN. Alcuni dispositivi VPN supportano solo un determinato tipo di VPN.

Importante

Attualmente, MDC supporta solo il tipo di VPN basato su route. Se il dispositivo supporta solo VPN basate su criteri, le connessioni a tali dispositivi da MDC non sono supportate. MDC non supporta anche l'uso di selettori di traffico basati su criteri per i gateway basati su route in questo momento 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 indirizzi tra la rete locale e la rete virtuale MDC. Il criterio, o selettore di traffico, è in genere un elenco di accesso nella configurazione del dispositivo VPN. PolicyBased è supportato in Azure, ma non in MDC.
• RouteBased: le VPN basate su route usano route configurate nella tabella di routing o inoltro IP. Instrada i pacchetti diretti 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 è configurato come any-to-any (o usare caratteri jolly). Per impostazione predefinita, non possono essere modificati. Il valore di un tipo VPN RouteBased è RouteBased.

Configurare 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 devono essere configurate in un ordine specifico.

Impostazione

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

Questo articolo consente di comprendere:

• Tipi di gateway, tipi 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 nelle 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 è una connessione tramite un tunnel VPN IPsec/IKE (IKEv2). Questo tipo di connessione richiede un dispositivo VPN che si trova in locale e viene assegnato un indirizzo IP pubblico. Questo dispositivo non può trovarsi dietro un NAT. Le connessioni da sito a sito 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ù connessioni VPN dal gateway di rete virtuale e in genere connettersi 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 tramite il gateway condividono la larghezza di banda disponibile.

SKU del gateway

Quando si crea un gateway di rete virtuale per MDC, si specifica lo SKU del gateway da usare. Sono supportati gli SKU del gateway VPN seguenti:

• Di base
• Normale
• Prestazioni elevate

La selezione di uno SKU del gateway superiore alloca 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.

MDC non supporta lo SKU del gateway Ultra Performance, usato esclusivamente con Azure ExpressRoute. Quando si seleziona lo SKU, tenere presenti i punti seguenti:

• MDC non supporta gateway basati su criteri.
• BGP non è supportato nello SKU di livello Basic.
• Le configurazioni coesistenti del gateway ExpressRoute-VPN non sono supportate in MDC.

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, MDC supporta solo la configurazione attiva/passiva.

Ripristino automatico

Esistono tre macchine virtuali dell'infrastruttura gateway multi-tenant in MDC. Due di queste macchine virtuali sono in modalità attiva. La terza macchina virtuale è in modalità ridondante. Le macchine virtuali attive consentono la creazione di connessioni VPN su di esse. La macchina virtuale ridondante accetta connessioni VPN solo 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 di gateway.

Tipo di gateway	Velocità effettiva del gateway VPN (1)	Numero massimo di tunnel IPsec del gateway VPN (2)
SKU Basic (3)	100 Mbps	20
SKU Standard	100 Mbps	20
SKU ad alte prestazioni	200 Mbps	10

Note della 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 ogni distribuzione MDC per tutte le sottoscrizioni.

(3) Il routing BGP non è supportato per lo SKU Basic.

Importante

È possibile creare una sola connessione VPN da sito a sito tra due distribuzioni MDC. Questa restrizione è dovuta al fatto che una limitazione nella piattaforma consente solo una singola connessione VPN allo stesso indirizzo IP. Poiché MDC usa il gateway multi-tenant, che usa un singolo indirizzo IP pubblico per tutti i gateway VPN nel sistema MDC, può essere presente una sola connessione VPN tra due sistemi MDC.

Questa limitazione si applica anche alla connessione di più connessioni VPN da sito a sito a qualsiasi gateway VPN che usa un singolo indirizzo IP. MDC 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 in MDC, è necessario configurare la connessione a entrambe le estremità. Se si configura una connessione VPN tra MDC e un dispositivo hardware, tale dispositivo potrebbe richiedere impostazioni aggiuntive. Ad esempio, il dispositivo potrebbe richiedere un commutatore o un router che funge da gateway VPN.

A differenza di Azure, che supporta più offerte sia come iniziatore che come risponditore, MDC supporta una sola offerta per impostazione predefinita. Se è necessario usare impostazioni IPsec/IKE diverse per usare il dispositivo VPN, sono disponibili altre impostazioni per configurare la connessione manualmente.

Parametri della Fase 1 di IKE (Modalità principale)

Proprietà	Valore
Versione IKE	IKEv2
Gruppo Diffie-Hellman	ECP384
Metodo di autenticazione	Chiave condivisa
Algoritmi di crittografia e hashing	AES256, SHA384
Durata sa (tempo)	28.800 secondi

Parametri della Fase 2 di IKE (Modalità rapida)

Proprietà	Valore
Versione IKE	IKEv2
Algoritmi di crittografia e hash (crittografia)	GCMAES256
Algoritmi di crittografia e hash (autenticazione)	GCMAES256
Durata sa (tempo)	27.000 secondi
Durata sa (kilobyte)	33,553,408
Segreto d'inoltro perfetto (PFS)	ECP384
Rilevamento di peer non recapitabili	Supportata

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 in MDC 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 applicarlo a una connessione nuova o esistente.

Considerazioni

Quando si usano questi criteri, tenere presenti le considerazioni importanti seguenti:

• I criteri IPsec/IKE funzionano solo negli SKU del gateway Standard e High Performance (route-based).
• 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). Non è consentito specificare criteri parziali.
• Consultare le specifiche del fornitore del dispositivo VPN per verificare che i criteri siano supportati dai dispositivi VPN locali. Non è possibile stabilire connessioni da sito a sito 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 gli algoritmi e i parametri selezionati.
4. Creare una connessione IPsec con i criteri IPsec/IKE.
5. Aggiungere, aggiornare o rimuovere un criterio IPsec/IKE per una connessione esistente.

Algoritmi di crittografia e punti di forza della chiave supportati

La tabella seguente elenca gli algoritmi di crittografia supportati e i punti di forza delle chiavi configurabili dai clienti MDC.

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, Nessuno
Integrità IPsec	GCMASE256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
Gruppo PFS	PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, Nessuno
Durata sa di QM	(Facoltativo: i valori predefiniti vengono usati se non specificati.
	Secondi (numero intero, min. 300/predefinito 27.000 secondi)
	KBytes (numero intero, min. 1024/valore predefinito 102.400.000 KBytes)
Selettore di traffico	I selettori di traffico basati su criteri non sono supportati in MDC.

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 dell'amministratore di sistema sono solo specifiche locali. Non è necessario che corrispondano.

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, usare GCMAES128 per entrambi.

Nella tabella precedente:

• IKEv2 corrisponde alla modalità principale o alla fase 1.
• IPsec corrisponde alla modalità rapida o fase 2.
• Gruppo DH specifica il gruppo Diffie-Hellman usato nella modalità principale o fase 1.
• Il gruppo PFS specifica il gruppo Diffie-Hellman usato in modalità rapida o fase 2.
• La durata dell'amministratore di sicurezza in modalità principale IKEv2 è fissa a 28.800 secondi nei gateway VPN MDC.

Nella tabella seguente sono elencati i gruppi Diffie-Hellman corrispondenti supportati dai criteri personalizzati.

Gruppo Diffie-Hellman	DHGroup	PFSGroup	Lunghezza della 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 MDC 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 la rete Internet pubblica.

Per altre informazioni su Azure ExpressRoute, vedere la panoramica di ExpressRoute.

Presupposti

Questo articolo presuppone che l'utente disponga di:

• Conoscenza operativa di Azure.
• Conoscenza di base di MDC.
• Conoscenza di base della rete.

Prerequisiti

Per connettere MDC e Azure tramite ExpressRoute, è necessario soddisfare i requisiti seguenti:

• Disporre di un circuito ExpressRoute di cui è stato effettuato il provisioning tramite un provider di connettività.
• Avere una sottoscrizione di Azure per creare un circuito ExpressRoute e reti virtuali in Azure.
• Avere un router che deve:
  • Supportare le connessioni VPN da sito a sito tra l'interfaccia LAN e il gateway multi-tenant di Azure Stack.
  • Supportare la creazione di più istanze di routing virtuale e inoltro se nella distribuzione MDC sono presenti più tenant.
• Avere un router con:
  • Una porta WAN connessa al circuito ExpressRoute.
  • Una porta LAN connessa al gateway multi-tenant MDC.

Architettura di rete ExpressRoute

Il diagramma seguente illustra gli ambienti MDC e Azure dopo aver completato la configurazione di ExpressRoute usando gli esempi in questo articolo.