Integrazione della rete resistente dell'hub di Azure Stack

Articolo
07/12/2023

Questo argomento illustra l'integrazione di rete di Azure Stack.

Connettività del bordo (uplink)

La pianificazione dell'integrazione di rete è un prerequisito importante per la corretta distribuzione, funzionamento e gestione dei sistemi integrati di Azure Stack. Per la pianificazione della connettività perimetrale è prima di tutto necessario scegliere se si vuole usare il routing dinamico con il protocollo BGP (Border Gateway Protocol). Ciò richiede l'assegnazione di un numero di sistema autonomo BGP a 16 bit (pubblico o privato) o l'uso del routing statico, in cui ai dispositivi di bordo viene assegnata una route predefinita statica.

I commutatori top of rack (TOR) richiedono l'uplink di livello 3 con indirizzi IP da punto a punto (/30 reti) configurati nelle interfacce fisiche. I collegamenti di livello 2 con commutatori TOR che supportano le operazioni di Azure Stack non sono supportati.

Routing con protocollo BGP

L'uso di un protocollo di routing dinamico come BGP consente di garantire che il sistema sia sempre consapevole delle modifiche alla rete e semplifica l'amministrazione. Per una sicurezza migliore, è possibile configurare una password nel peering BGP tra il dispositivo TOR e i dispositivi perimetrali.

Come illustrato nel diagramma seguente, l'annuncio dello spazio IP privato sul commutatore TOR è bloccato mediante un elenco di prefissi. L'elenco di prefissi nega l'annuncio della rete privata e viene applicato come mappa di route sulla connessione tra il dispositivo TOR e i dispositivi perimetrali.

Il software Load Balancer (SLB) in esecuzione all'interno dei peer della soluzione Azure Stack ai dispositivi TOR in modo che possa annunciare dinamicamente gli indirizzi VIP.

Per garantire che il traffico utente venga immediatamente ripristinato e ripristinato in modo trasparente da un errore, il VPC o MLAG configurato tra i dispositivi TOR consente l'uso dell'aggregazione di collegamenti tra più chassis agli host e HSRP o VRRP che fornisce ridondanza di rete per le reti IP.

Routing statico

Il routing statico richiede una configurazione aggiuntiva per i dispositivi border. Richiede un intervento e una gestione più manuali, nonché un'analisi approfondita prima di qualsiasi modifica. I problemi causati da un errore di configurazione possono richiedere più tempo per eseguire il rollback a seconda delle modifiche apportate. Questo metodo di routing non è consigliato ma è supportato.

Per integrare Azure Stack nell'ambiente di rete usando il routing statico, tutti e quattro i collegamenti fisici tra il bordo e il dispositivo TOR devono essere connessi. La disponibilità elevata non può essere garantita a causa del funzionamento del routing statico.

Il dispositivo border deve essere configurato con route statiche che puntano a ognuno dei quattro indirizzi IP P2P impostati tra tor e border per il traffico destinato a qualsiasi rete all'interno di Azure Stack, ma per l'operazione è necessaria solo la rete VIP esterna o pubblica. Le route statiche verso le reti BMC ed esterne sono necessarie per la distribuzione iniziale. Gli operatori possono scegliere di lasciare le route statiche nei dispositivi perimetrali per accedere alle risorse di gestione che si trovano nella rete BMC e nella rete dell'infrastruttura. L'aggiunta di route statiche alle reti dell'infrastruttura del commutatore e di gestione del commutatore è facoltativa.

I dispositivi TOR sono configurati con una route statica predefinita che invia tutto il traffico ai dispositivi perimetrali. L'unica eccezione di traffico rispetto alla regola predefinita è relativa allo spazio privato, che viene bloccato mediante un elenco di controllo di accesso applicato alla connessione tra TOR e i dispositivi perimetrali.

Il routing statico è applicabile solo agli uplink tra i commutatori TOR e perimetrali. Il routing dinamico con BGP viene usato all'interno del rack perché è uno strumento essenziale per SLB e gli altri componenti e non può essere disabilitato o rimosso.

* La rete BMC è facoltativa dopo la distribuzione.

** La rete switch infrastructure è facoltativa, perché l'intera rete può essere inclusa nella rete di gestione dei commutatori.

La rete switch management è necessaria e può essere aggiunta separatamente dalla rete switch infrastructure.

Proxy trasparente

Se il data center richiede che tutto il traffico usi un proxy, è necessario configurare un proxy trasparente per elaborare tutto il traffico dal rack per gestirlo in base ai criteri, separando il traffico tra le zone della rete.

La soluzione Azure Stack non supporta i normali proxy Web

Un proxy trasparente (noto anche come proxy di intercettazione, inline o forzato) intercetta le normali comunicazioni a livello di rete senza richiedere alcuna configurazione client speciale. I client non devono essere consapevoli dell'esistenza del proxy.

L'intercettazione del traffico SSL non è supportata e può causare errori del servizio durante l'accesso agli endpoint. Il timeout massimo supportato per comunicare con gli endpoint necessari per l'identità è 60s con 3 tentativi.

DNS

Questa sezione illustra la configurazione dns (Domain Name System).

Configurare l'inoltro DNS condizionale

Questo vale solo per una distribuzione di AD FS.

Per abilitare la risoluzione dei nomi con l'infrastruttura DNS esistente, configurare l'inoltro condizionale.

Per aggiungere un server d'inoltro condizionale, è necessario usare l'endpoint con privilegi.

Per questa procedura, usare un computer nella rete del data center in grado di comunicare con l'endpoint con privilegi in Azure Stack.

Aprire una sessione di Windows PowerShell con privilegi elevati (eseguita come amministratore) e connettersi all'indirizzo IP dell'endpoint con privilegi. Usare le credenziali per l'autenticazione CloudAdmin.
```
\$cred=Get-Credential Enter-PSSession -ComputerName \<IP Address of ERCS\> -ConfigurationName PrivilegedEndpoint -Credential \$cred 
```
Dopo aver eseguito la connessione all'endpoint con privilegi, eseguire il comando di PowerShell seguente. Sostituire i valori di esempio specificati con il nome di dominio e gli indirizzi IP dei server DNS da usare.
```
Register-CustomDnsServer -CustomDomainName "contoso.com" -CustomDnsIPAddresses "192.168.1.1","192.168.1.2" 
```

Risoluzione dei nomi DNS di Azure Stack dall'esterno di Azure Stack

I server autorevoli sono quelli che contengono le informazioni sulla zona DNS esterna e tutte le zone create dall'utente. Eseguire l'integrazione con questi server per abilitare la delega della zona o l'inoltro condizionale per risolvere i nomi DNS di Azure Stack dall'esterno di Azure Stack.

Ottenere informazioni sull'endpoint esterno del server DNS

Per integrare la distribuzione di Azure Stack con l'infrastruttura DNS, sono necessarie le informazioni seguenti:

FQDN del server DNS
Indirizzi IP del server DNS

I nomi di dominio completi per i server DNS di Azure Stack hanno il formato seguente:

<NAMINGPREFIX-ns01>.<AREA GEOGRAFICA>.<EXTERNALDOMAINNAME>

<NAMINGPREFIX-ns02>.<AREA GEOGRAFICA>.<EXTERNALDOMAINNAME>

Se si usano i valori di esempio, i nomi di dominio completi per i server DNS sono i seguenti:

azs-ns01.east.cloud.fabrikam.com

azs-ns02.east.cloud.fabrikam.com

Queste informazioni sono disponibili nel portale di amministrazione, ma anche create alla fine di tutte le distribuzioni di Azure Stack in un file denominato AzureStackStampInformation.json. Questo file si trova nella cartella C:\CloudDeployment\logs della macchina virtuale di distribuzione. Se non si è certi dei valori usati per la distribuzione di Azure Stack, è possibile ottenere i valori da qui.

Se la macchina virtuale di distribuzione non è più disponibile o non è accessibile, è possibile ottenere i valori connettendosi all'endpoint con privilegi ed eseguendo il cmdlet di PowerShell Get-AzureStackStampInformation. Per altre informazioni, vedere Endpoint con privilegi.

Configurazione dell'inoltro condizionale ad Azure Stack

Il modo più semplice e sicuro per integrare Azure Stack con l'infrastruttura DNS consiste nell'eseguire l'inoltro condizionale della zona dal server che ospita la zona padre. Questo approccio è consigliato se si ha il controllo diretto sui server DNS che ospitano la zona padre per lo spazio dei nomi DNS esterno di Azure Stack.

Se non si ha familiarità con l'inoltro condizionale con DNS, vedere l'articolo TechNet seguente: Assegnare un server d'inoltro condizionale per un nome di dominio o la documentazione specifica per la soluzione DNS.

Negli scenari in cui è stata specificata la zona DNS esterna di Azure Stack in modo che sia simile a un dominio figlio del nome di dominio aziendale, non è possibile usare l'inoltro condizionale. È necessario configurare la delega DNS.

Esempio:

Nome di dominio DNS aziendale: contoso.com
Nome di dominio DNS esterno di Azure Stack: azurestack.contoso.com

Modifica degli indirizzi IP del server di inoltro DNS

Gli indirizzi IP del server d'inoltro DNS vengono impostati durante la distribuzione di Azure Stack. Tuttavia, se gli indirizzi IP del server d'inoltro devono essere aggiornati per qualsiasi motivo, è possibile modificare i valori connettendosi all'endpoint con privilegi ed eseguire i cmdlet di PowerShell Get-AzSDnsForwarder e Set-AzSDnsForwarder [[-IPAddress] <IPAddress[]>]. Per altre informazioni, vedere Endpoint con privilegi.

Delega della zona DNS esterna ad Azure Stack

Per risolvere i nomi DNS dall'esterno di una distribuzione di Azure Stack, è necessario configurare la delega DNS.

Ogni registrar prevede i propri strumenti di gestione DNS per modificare i record del server dei nomi per un dominio. Nella pagina di gestione DNS del registrar modificare i record NS e sostituire i record NS per la zona con quelli in Azure Stack.

La maggior parte dei registrar DNS richiede di fornire almeno due server DNS per completare la delega.

Firewall

Azure Stack configura gli indirizzi IP virtuali (VIP) per i ruoli dell'infrastruttura. Questi indirizzi VIP vengono allocati dal pool di indirizzi IP pubblici. Ogni indirizzo VIP è protetto con un elenco di controllo di accesso (ACL) nel livello di rete definito dal software. Gli ACL vengono usati anche nei commutatori fisici (TOR e BMC) per rafforzare ulteriormente la soluzione. Viene creata una voce DNS per ogni endpoint nella zona DNS esterna specificata in fase di distribuzione. Ad esempio, al portale utenti viene assegnata la voce host DNS del portale. <area> geografica.<fqdn>.

Il diagramma dell'architettura seguente mostra i diversi livelli di rete e ACL:

Diagramma dell'architettura che mostra i diversi livelli di rete e ACL

Porte e URL

Per rendere disponibili i servizi di Azure Stack (ad esempio i portali, Azure Resource Manager, DNS e così via) per le reti esterne, è necessario consentire il traffico in ingresso a questi endpoint per URL, porte e protocolli specifici.

In una distribuzione in cui un proxy trasparente si collega a un server proxy tradizionale o a un firewall protegge la soluzione, è necessario consentire porte e URL specifici per la comunicazione in ingresso e in uscita. Queste includono porte e URL per identità, marketplace, patch e aggiornamento, registrazione e dati di utilizzo.

Comunicazione in uscita

Azure Stack supporta solo server proxy trasparenti. In una distribuzione con un collegamento uplink trasparente proxy a un server proxy tradizionale, è necessario consentire le porte e gli URL nella tabella seguente per la comunicazione in uscita durante la distribuzione in modalità connessa.

Nota

Azure Stack non supporta l'uso di ExpressRoute per raggiungere i servizi di Azure elencati nella tabella seguente perché ExpressRoute potrebbe non essere in grado di instradare il traffico a tutti gli endpoint.

Scopo	URL di destinazione	Protocollo	Porte	Rete di origine
Identità	Azure login.windows.net login.microsoftonline.com graph.windows.net https://secure.aadcdn.microsoftonline-p.com www.office.com ManagementServiceUri = https://management.core.windows.net ARMUri = https://management.azure.com https://.msftauth.net https://.msauth.net https://.msocdn.com Azure per enti pubblici* https://login.microsoftonline.us/ https://graph.windows.net/ Azure Cina (21Vianet) https://login.chinacloudapi.cn/ https://graph.chinacloudapi.cn/ Azure Germania https://login.microsoftonline.de/ https://graph.cloudapi.de/	HTTP HTTPS	80 443	VIP pubblico - /27 Rete infrastruttura pubblica
Diffusione del Marketplace	Azure https://management.azure.com https://.blob.core.windows.net https://.azureedge.net Azure per enti pubblici https://management.usgovcloudapi.net/ https://.blob.core.usgovcloudapi.net/ Azure Cina (21Vianet)* https://management.chinacloudapi.cn/ http://*.blob.core.chinacloudapi.cn	HTTPS	443	VIP pubblico - /27
Patch & Update	https://*.azureedge.net https://aka.ms/azurestackautomaticupdate	HTTPS	443	VIP pubblico - /27
Registrazione	Azure https://management.azure.com Azure per enti pubblici https://management.usgovcloudapi.net/ Azure Cina (21Vianet) https://management.chinacloudapi.cn	HTTPS	443	VIP pubblico - /27
Utilizzo	Azure https://.trafficmanager.net Azure per enti pubblici* https://.usgovtrafficmanager.net Azure Cina (21Vianet)* https://*.trafficmanager.cn	HTTPS	443	VIP pubblico - /27
Windows Defender	.wdcp.microsoft.com .wdcpalt.microsoft.com .wd.microsoft.com .update.microsoft.com *.download.microsoft.com https://www.microsoft.com/pkiops/crl https://www.microsoft.com/pkiops/certs https://crl.microsoft.com/pki/crl/products https://www.microsoft.com/pki/certs https://secure.aadcdn.microsoftonline-p.com	HTTPS	80 443	VIP pubblico - /27 Rete infrastruttura pubblica
NTP	(IP del server NTP fornito per la distribuzione)	UDP	123	VIP pubblico - /27
DNS	(IP del server DNS fornito per la distribuzione)	TCP UDP	53	VIP pubblico - /27
CRL	(URL in Punti di distribuzione CRL nel certificato)	HTTP	80	VIP pubblico - /27
LDAP	Foresta Active Directory fornita per l'integrazione di Graph	TCP UDP	389	VIP pubblico - /27
LDAP SSL	Foresta Active Directory fornita per l'integrazione di Graph	TCP	636	INDIRIZZO VIP pubblico - /27
GC LDAP	Foresta Active Directory fornita per l'integrazione di Graph	TCP	3268	INDIRIZZO VIP pubblico - /27
SSL per GC LDAP	Foresta Active Directory fornita per l'integrazione di Graph	TCP	3269	INDIRIZZO VIP pubblico - /27
AD FS	Endpoint dei metadati AD FS fornito per l'integrazione di AD FS	TCP	443	INDIRIZZO VIP pubblico - /27
Servizio raccolta log di diagnostica	URL di firma di accesso condiviso BLOB fornito da Archiviazione di Azure	HTTPS	443	INDIRIZZO VIP pubblico - /27

Comunicazione in ingresso

Per la pubblicazione di endpoint di Azure Stack in reti esterne è necessario un set di indirizzi VIP dell'infrastruttura. La tabella Endpoint (VIP) mostra ogni endpoint, la porta e il protocollo necessari. Vedere la documentazione specifica relativa alla distribuzione del provider di risorse per gli endpoint che richiedono provider di risorse aggiuntivi, ad esempio il provider di risorse SQL.

Gli indirizzi VIP dell'infrastruttura interna non sono elencati perché non sono necessari per la pubblicazione di Azure Stack. Gli indirizzi VIP utente sono dinamici e definiti dagli utenti stessi, senza alcun controllo da parte dell'operatore di Azure Stack