Integrazione di rete

Articolo
01/10/2024

Questo articolo illustra l'integrazione della rete di Azure Stack per Azure Modular Datacenter.

Connettività del bordo (uplink)

La pianificazione dell'integrazione di rete è un prerequisito importante per la corretta distribuzione di sistemi integrati, operazioni e gestione di Azure Stack. La pianificazione della connettività del bordo inizia scegliendo se si vuole usare il routing dinamico con il protocollo BGP (Border Gateway Protocol) o il routing statico. Il routing dinamico richiede l'assegnazione di un numero di sistema autonomo BGP a 16 bit (pubblico o privato). Il routing statico usa una route predefinita statica assegnata ai dispositivi di bordo.

I commutatori perimetrali richiedono collegamenti uplink di livello 3 con indirizzi IP da punto a punto (/30 reti) configurati nelle interfacce fisiche. I collegamenti uplink di livello 2 con commutatori perimetrali 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 la sicurezza avanzata, è possibile impostare una password sul peering BGP tra il bordo e il bordo.

Come illustrato nel diagramma seguente, la pubblicità dello spazio IP privato nel commutatore TOR (TOP-of-rack) viene bloccata usando un elenco di prefisso. L'elenco di prefisso nega l'annuncio della rete privata e viene applicato come mappa di route sulla connessione tra toR e il bordo.

Il servizio di bilanciamento del carico software in esecuzione all'interno dei peer della soluzione Azure Stack ai dispositivi TOR in modo da poter annunciare dinamicamente gli indirizzi VIP.

Per garantire che il traffico utente venga immediatamente ripristinato e ripristinato in modo trasparente dall'errore, il cloud privato virtuale o l'aggregazione di collegamenti multi-chassis configurati tra i dispositivi TOR consente l'uso di MLAG 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 di bordo. Richiede un intervento e una gestione più manuali e un'analisi approfondita prima di qualsiasi modifica. I problemi causati da un errore di configurazione potrebbero richiedere più tempo per eseguire il rollback a seconda delle modifiche apportate. Non è consigliabile questo metodo di routing, 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 perimetrale devono essere connessi. La disponibilità elevata non può essere garantita a causa del funzionamento del routing statico.

Il dispositivo di bordo deve essere configurato con route statiche che puntano a ognuno dei quattro indirizzi IP da punto a punto impostati tra il bordo e il bordo per il traffico destinato a qualsiasi rete all'interno di Azure Stack. Tuttavia, solo la rete VIP esterna o pubblica è necessaria per l'operazione. Le route statiche alla BMC e alle reti esterne sono necessarie per la distribuzione iniziale. Gli operatori possono scegliere di lasciare le route statiche nel bordo per accedere alle risorse di gestione che risiedono nella rete BMC e nell'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'eccezione di traffico alla regola predefinita è per lo spazio privato, bloccato usando un elenco di controllo di accesso applicato alla connessione TOR-to-border.

Il routing statico si applica solo ai collegamenti di uplink tra i commutatori perimetrali e di bordo. 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 dell'infrastruttura switch è facoltativa perché l'intera rete può essere inclusa nella rete di gestione dei commutatori.

La rete di gestione dei commutatori è necessaria e può essere aggiunta separatamente dalla rete dell'infrastruttura switch.

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. È necessario separare il traffico tra le zone della rete.

La soluzione Azure Stack non supporta i normali proxy Web.

Un proxy trasparente (noto anche come proxy inline, inline o forzato) intercetta la normale comunicazione 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à è di 60 secondi con tre tentativi.

DNS

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

Configurare l'inoltro DNS condizionale

Questa guida si applica solo a una distribuzione di Active Directory Federation Services (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 che può comunicare con l'endpoint con privilegi in Azure Stack.

Aprire una sessione di Windows PowerShell con privilegi elevati (eseguita come amministratore). 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" 
```

Risolvere i 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. Integrare con questi server per abilitare l'inoltro condizionale o la delega della zona 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:

Nomi di dominio completi del server DNS (FQDN)
Indirizzi IP del server DNS

I FQDN per i server DNS di Azure Stack hanno il formato seguente:

<NAMINGPREFIX-ns01>.<AREA>.<EXTERNALDOMAINNAME>
<NAMINGPREFIX-ns02>.<AREA>.<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 create anche 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 Get-AzureStackStampInformation powerShell. Per altre informazioni, vedere endpoint con privilegi.

Configurare l'inoltro condizionale in Azure Stack

Il modo più semplice e più sicuro per integrare Azure Stack con l'infrastruttura DNS consiste nell'eseguire l'inoltro condizionale della zona dal server che ospita la zona padre. È consigliabile questo approccio 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 come eseguire l'inoltro condizionale con DNS, vedere l'articolo TechNet "Assegnare un forwarder 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 per essere simile a un dominio figlio del nome di dominio aziendale, l'inoltro condizionale non può essere usato. La delega DNS deve essere configurata.

Esempio:

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

Modificare gli indirizzi IP del server di inoltro DNS

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

Delegare la 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 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 tra i commutatori fisici (TOR e BMC) per rafforzare ulteriormente la soluzione. Viene creata una voce DNS per ogni endpoint nell'area DNS esterna specificata in fase di distribuzione. Ad esempio, il portale utente viene assegnato alla voce host DNS del portale. <area>.<fqdn>.

Il diagramma dell'architettura seguente illustra i diversi livelli di rete e gli elenchi di controllo di accesso.

Diagramma dell'architettura che mostra i diversi livelli di rete e gli elenchi di controllo di accesso.

Porte e URL

Per rendere disponibili servizi di Azure Stack come portali, Resource Manager di Azure e DNS alle 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. Gli esempi includono porte e URL per identità, Azure Stack Hub Marketplace, patch e aggiornamento, registrazione e dati di utilizzo.

Comunicazione in uscita

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

Nota

Azure Stack non supporta l'uso di Azure 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 di Azure Stack Hub 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
Applicazione di patch e aggiornamenti	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 Azure Graph	TCP UDP	389	INDIRIZZO 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 di raccolta dei log di diagnostica	URL della firma di accesso condiviso fornito da Archiviazione BLOB 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. Per gli endpoint che richiedono provider di risorse aggiuntivi, ad esempio il provider di risorse SQL, vedere la documentazione specifica sulla distribuzione del provider di risorse.

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.