Integrazione di rete

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

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 BGP

L'uso di un protocollo di routing dinamico come BGP garantisce che il sistema sia sempre consapevole delle modifiche di rete e facilita 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 per cambiare infrastruttura e reti di gestione dei commutatori è facoltativa.

I dispositivi TOR sono configurati con una route predefinita statica che invia tutto il traffico ai dispositivi di bordo. 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 BGP viene usato all'interno del rack perché è uno strumento essenziale per il bilanciamento del carico di carico e 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 forwarder 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.

  1. Aprire una sessione di Windows PowerShell con privilegi elevati (eseguita come amministratore). Connessione 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 
    
  2. Dopo la connessione all'endpoint con privilegi, eseguire il comando powerShell seguente. Sostituire i valori di esempio forniti con il nome di dominio e gli indirizzi IP dei server DNS che si desidera 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>

Usando i valori di esempio, i FQDN per i server DNS sono:

  • 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 mostra i diversi livelli di rete e ACL.

Architectural diagram shows the different network layers and ACLs.

Porte e URL

Per rendere disponibili servizi di Azure Stack come portali, Azure Resource Manager e DNS 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 ricollega 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 esegue la distribuzione in modalità connessa.

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.

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
INDIRIZZO VIP pubblico - /27
Rete dell'infrastruttura pubblica
Diffusione del Marketplace dell'hub di Azure Stack 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 INDIRIZZO VIP pubblico - /27
Applicazione di patch e aggiornamenti https://*.azureedge.net
https://aka.ms/azurestackautomaticupdate
HTTPS 443 INDIRIZZO 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 INDIRIZZO VIP pubblico - /27
Utilizzo Azure
https://*.trafficmanager.net
Azure per enti pubblici
https://*.usgovtrafficmanager.net
Azure Cina (21Vianet)
https://*.trafficmanager.cn
HTTPS 443 INDIRIZZO 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
INDIRIZZO VIP pubblico - /27
Rete dell'infrastruttura pubblica
NTP IP del server NTP fornito per la distribuzione UDP 123 INDIRIZZO VIP pubblico - /27
DNS IP del server DNS fornito per la distribuzione TCP
UDP
53 INDIRIZZO VIP pubblico - /27
CRL URL in Punti di distribuzione CRL nel certificato HTTP 80 INDIRIZZO VIP pubblico - /27
LDAP Foresta Di 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
LDAP GC Foresta Active Directory fornita per l'integrazione di Graph TCP 3268 INDIRIZZO VIP pubblico - /27
LDAP GC SSL 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.

Nota

VPN IKEv2 è una soluzione VPN IPsec basata su standard che usa la porta UDP 500 e 4500 e la porta TCP 50. I firewall non aprono sempre queste porte, quindi una VPN IKEv2 potrebbe non essere in grado di attraversare proxy e firewall.

Endpoint (VIP) Record A dell'host DNS Protocollo Porte
AD FS Adfs. <area> geografica.< Fqdn> HTTPS 443
portale di Azure (amministratore) Amministratore. <area> geografica.< Fqdn> HTTPS 443
Adminhosting *.adminhosting.< area> geografica.< Fqdn> HTTPS 443
Azure Resource Manager (amministratore) Adminmanagement. <area> geografica.< Fqdn> HTTPS 443
portale di Azure (utente) Portale. <area> geografica.< Fqdn> HTTPS 443
Azure Resource Manager (utente) Gestione. <area> geografica.< Fqdn> HTTPS 443
Azure Graph Graph. <area> geografica.< Fqdn> HTTPS 443
Elenco di revoche di certificati Crl.region<.<> Fqdn> HTTP 80
DNS *. <area> geografica.< Fqdn> TCP & UDP 53
Hosting *.hosting.< area> geografica.< Fqdn> HTTPS 443
Azure Key Vault (utente) *.vault. <area> geografica.< Fqdn> HTTPS 443
Azure Key Vault (amministratore) *.adminvault. <area> geografica.< Fqdn> HTTPS 443
Archiviazione code di Azure *.queue. <area> geografica.< Fqdn> HTTP
HTTPS
80
443
Archiviazione tabelle di Azure *.table. <area> geografica.< Fqdn> HTTP
HTTPS
80
443
Archiviazione BLOB di Azure *.BLOB. <area>.< Fqdn> HTTP
HTTPS
80
443
SQL provider di risorse sqladapter.dbadapter. <area>.< Fqdn> HTTPS 44300-44304
Provider di risorse MySQL mysqladapter.dbadapter. <area>.< Fqdn> HTTPS 44300-44304
Servizio app di Azure *.appservice. <area>.< Fqdn> TCP 80 (HTTP)
443 (HTTPS)
8172 (MSDeploy)
*.scm.appservice. <area>.< Fqdn> TCP 443 (HTTPS)
api.appservice. <area>.< Fqdn> TCP 443 (HTTPS)
44300 (Azure Resource Manager)
ftp.appservice. <area>.< Fqdn> TCP, UDP 21, 1021, 10001-10100 (FTP)
990 (FTPS)
Gateway VPN di Azure Vedere le domande frequenti Gateway VPN