Robuuste netwerkintegratie van Azure Stack Hub

Artikel
07/12/2023

In dit onderwerp wordt de netwerkintegratie van Azure Stack behandeld.

Randconnectiviteit (uplink)

Planning van netwerkintegratie is een belangrijke vereiste voor een geslaagde implementatie, bewerking en beheer van geïntegreerde Azure Stack-systemen. Planning van randconnectiviteit begint met het kiezen of u dynamische routering met Border Gateway Protocol (BGP) wilt gebruiken. Dit vereist het toewijzen van een 16-bits BGP autonoom systeemnummer (openbaar of privé) of het gebruik van statische routering, waarbij een statische standaardroute wordt toegewezen aan de randapparaten.

De tor-switches (top of rack) vereisen laag 3-uplinks met punt-naar-punt-IP-adressen (/30-netwerken) die zijn geconfigureerd op de fysieke interfaces. Laag 2-uplinks met TOR-switches die Azure Stack-bewerkingen ondersteunen, worden niet ondersteund.

BGP-routering

Het gebruik van een dynamisch routeringsprotocol zoals BGP garandeert dat uw systeem altijd op de hoogte is van netwerkwijzigingen en het beheer vergemakkelijkt. Voor verbeterde beveiliging kan een wachtwoord worden ingesteld voor de BGP-peering tussen de TOR en de rand.

Zoals weergegeven in het volgende diagram, wordt reclame voor de privé-IP-ruimte op de TOR-switch geblokkeerd met behulp van een voorvoegsellijst. De lijst met voorvoegsels weigert de aankondiging van het particuliere netwerk en wordt toegepast als een routekaart op de verbinding tussen de TOR en de rand.

De Software Load Balancer (SLB) die in de Azure Stack-oplossing wordt uitgevoerd, koppelt aan de TOR-apparaten, zodat de VIP-adressen dynamisch kunnen worden geadverteerd.

Om ervoor te zorgen dat gebruikersverkeer onmiddellijk en transparant herstelt van storingen, staat de VPC of MLAG die is geconfigureerd tussen de TOR-apparaten het gebruik van multichassiskoppelingsaggregatie toe voor de hosts en HSRP of VRRP die netwerkredundantie voor de IP-netwerken biedt.

Statische routering

Statische routering vereist aanvullende configuratie voor de randapparaten. Het vereist meer handmatige interventie en beheer, evenals een grondige analyse vóór elke wijziging. Problemen die worden veroorzaakt door een configuratiefout, kunnen meer tijd in beslag nemen om terug te draaien, afhankelijk van de aangebrachte wijzigingen. Deze routeringsmethode wordt niet aanbevolen, maar wordt wel ondersteund.

Als u Azure Stack wilt integreren in uw netwerkomgeving met behulp van statische routering, moeten alle vier de fysieke koppelingen tussen de rand en het TOR-apparaat zijn verbonden. Hoge beschikbaarheid kan niet worden gegarandeerd vanwege de werking van statische routering.

Het randapparaat moet worden geconfigureerd met statische routes die verwijzen naar elk van de vier P2P-IP-adressen die zijn ingesteld tussen de TOR en de rand voor verkeer dat is bestemd voor een netwerk binnen Azure Stack, maar alleen het externe of openbare VIP-netwerk is vereist voor gebruik. Statische routes naar de BMC en de externe netwerken zijn vereist voor de eerste implementatie. Operators kunnen ervoor kiezen om statische routes aan de rand te laten voor toegang tot beheerresources die zich op de BMC en het infrastructuurnetwerk bevinden. Het toevoegen van statische routes om te schakelen tussen infrastructuur en beheernetwerken is optioneel.

De TOR-apparaten zijn geconfigureerd met een statische standaardroute die al het verkeer naar de grensapparaten verzendt. De enige verkeersuitzondering op de standaardregel is voor de privéruimte, die wordt geblokkeerd met behulp van een Access Control List die is toegepast op de TOR-randverbinding.

Statische routering is alleen van toepassing op de uplinks tussen de TOR- en randswitches. Dynamische BGP-routering wordt in het rek gebruikt omdat het een essentieel hulpmiddel is voor de SLB en andere onderdelen en niet kan worden uitgeschakeld of verwijderd.

* Het BMC-netwerk is optioneel na de implementatie.

** Het netwerk Switch Infrastructure is optioneel, omdat het hele netwerk kan worden opgenomen in het switchbeheernetwerk.

Het switchbeheernetwerk is vereist en kan afzonderlijk van het netwerk Switch Infrastructure worden toegevoegd.

Transparante proxy

Als uw datacenter vereist dat al het verkeer een proxy gebruikt, moet u een transparante proxy configureren om al het verkeer van het rek te verwerken volgens beleid, waarbij verkeer wordt gescheiden tussen de zones in uw netwerk.

De Azure Stack-oplossing biedt geen ondersteuning voor normale webproxy's

Een transparante proxy (ook wel een onderscheppingsproxy, inline of geforceerde proxy genoemd) onderschept normale communicatie op de netwerklaag zonder dat hiervoor een speciale clientconfiguratie is vereist. Clients hoeven niet op de hoogte te zijn van het bestaan van de proxy.

Het onderscheppen van SSL-verkeer wordt niet ondersteund en kan leiden tot servicefouten bij het openen van eindpunten. De maximaal ondersteunde time-out voor communicatie met eindpunten die vereist is voor identiteit is 60s met 3 nieuwe pogingen.

DNS

In deze sectie wordt de dns-configuratie (Domain Name System) behandeld.

Voorwaardelijke DNS-doorstuurfunctie configureren

Dit geldt alleen voor een AD FS-implementatie.

Als u naamomzetting wilt inschakelen met uw bestaande DNS-infrastructuur, configureert u voorwaardelijk doorsturen.

Als u een voorwaardelijke doorstuurserver wilt toevoegen, moet u het bevoegde eindpunt gebruiken.

Gebruik voor deze procedure een computer in uw datacenternetwerk die kan communiceren met het bevoegde eindpunt in Azure Stack.

Open een sessie met verhoogde Windows PowerShell (als administrator uitvoeren) en maak verbinding met het IP-adres van het bevoegde eindpunt. Gebruik de referenties voor CloudAdmin-verificatie.
```
\$cred=Get-Credential Enter-PSSession -ComputerName \<IP Address of ERCS\> -ConfigurationName PrivilegedEndpoint -Credential \$cred 
```
Nadat u verbinding hebt gemaakt met het bevoegde eindpunt, voert u de volgende PowerShell-opdracht uit. Vervang de voorbeeldwaarden door uw domeinnaam en IP-adressen van de DNS-servers die u wilt gebruiken.
```
Register-CustomDnsServer -CustomDomainName "contoso.com" -CustomDnsIPAddresses "192.168.1.1","192.168.1.2" 
```

Dns-namen van Azure Stack van buiten Azure Stack omzetten

De gezaghebbende servers zijn de servers die de informatie over de externe DNS-zone bevatten en alle door de gebruiker gemaakte zones. Integreer met deze servers om zonedelegering of voorwaardelijk doorsturen in te schakelen om Azure Stack DNS-namen van buiten Azure Stack om te lossen.

Externe eindpuntgegevens van DNS-server ophalen

Als u uw Azure Stack-implementatie wilt integreren met uw DNS-infrastructuur, hebt u de volgende informatie nodig:

FQDN's van DNS-server
IP-adressen van DNS-server

De FQDN's voor de Azure Stack DNS-servers hebben de volgende indeling:

<NAMINGPREFIX-ns01>.<REGIO>.<EXTERNALDOMAINNAME>

<NAMINGPREFIX-ns02>.<REGIO>.<EXTERNALDOMAINNAME>

Met behulp van de voorbeeldwaarden zijn de FQDN's voor de DNS-servers:

azs-ns01.east.cloud.fabrikam.com

azs-ns02.east.cloud.fabrikam.com

Deze informatie is beschikbaar in de beheerportal, maar is ook gemaakt aan het einde van alle Azure Stack-implementaties in een bestand met de naam AzureStackStampInformation.json. Dit bestand bevindt zich in de map C:\CloudDeployment\logs van de virtuele machine Deployment. Als u niet zeker weet welke waarden zijn gebruikt voor uw Azure Stack-implementatie, kunt u de waarden hier ophalen.

Als de virtuele machine implementatie niet meer beschikbaar is of niet toegankelijk is, kunt u de waarden verkrijgen door verbinding te maken met het bevoegde eindpunt en de powershell-cmdlet Get-AzureStackStampInformation uit te voeren. Zie privileged endpoint (Bevoegd eindpunt) voor meer informatie.

Instellen van voorwaardelijk doorsturen naar Azure Stack

De eenvoudigste en veiligste manier om Azure Stack te integreren met uw DNS-infrastructuur is door de zone voorwaardelijk door te sturen vanaf de server die als host fungeert voor de bovenliggende zone. Deze aanpak wordt aanbevolen als u directe controle hebt over de DNS-servers die als host fungeren voor de bovenliggende zone voor uw externe DNS-naamruimte in Azure Stack.

Als u niet bekend bent met het uitvoeren van voorwaardelijk doorsturen met DNS, raadpleegt u het volgende TechNet-artikel: Een voorwaardelijke doorstuurfunctie toewijzen voor een domeinnaam of de documentatie die specifiek is voor uw DNS-oplossing.

In scenario's waarin u uw externe Azure Stack DNS-zone hebt opgegeven om eruit te zien als een onderliggend domein van uw bedrijfsdomeinnaam, kan voorwaardelijk doorsturen niet worden gebruikt. DNS-delegering moet worden geconfigureerd.

Voorbeeld:

Bedrijfs-DNS-domeinnaam: contoso.com
Externe DNS-domeinnaam van Azure Stack: azurestack.contoso.com

IP-adressen voor DNS-doorstuurserver bewerken

IP-adressen van DNS-doorstuurservers worden ingesteld tijdens de implementatie van Azure Stack. Als de DOORstuurserver-IP-adressen echter om welke reden dan ook moeten worden bijgewerkt, kunt u de waarden bewerken door verbinding te maken met het bevoegde eindpunt en de PowerShell-cmdlets voor Get-AzSDnsForwarder en Set-AzSDnsForwarder [[-IPAddress] <IPAddress[]>] uit te voeren. Zie privileged endpoint (Bevoegd eindpunt) voor meer informatie.

De externe DNS-zone naar Azure Stack delegeren

Dns-namen kunnen alleen worden omgezet van buiten een Azure Stack-implementatie als u DNS-delegatie instelt.

Elke registrar heeft zijn eigen hulpprogramma's voor DNS-beheer om de naamserverrecords voor een domein te wijzigen. Bewerk op de dns-beheerpagina van de registrar de NS-records en vervang de NS-records voor de zone door de records in Azure Stack.

Voor de meeste DNS-registrars moet u minimaal twee DNS-servers opgeven om de overdracht te voltooien.

Firewall

Azure Stack stelt virtuele IP-adressen (VIP's) in voor de bijbehorende infrastructuurrollen. Deze VIP's worden toegewezen vanuit de openbare IP-adresgroep. Elk VIP wordt beveiligd met een toegangsbeheerlijst (ACL) in de software-gedefinieerde netwerklaag. ACL's worden ook gebruikt voor de fysieke switches (TORs en BMC) om de oplossing verder te beveiligen. Er wordt een DNS-vermelding gemaakt voor elk eindpunt in de externe DNS-zone die is opgegeven tijdens de implementatie. De gebruikersportal krijgt bijvoorbeeld de DNS-hostvermelding van de portal toegewezen. <regio>.<fqdn>.

In het volgende architectuurdiagram ziet u de verschillende netwerklagen en ACL's:

architectuurdiagram met de verschillende netwerklagen en ACL's

Poorten en URL's

Als u Azure Stack-services (zoals de portals, Azure Resource Manager, DNS, enzovoort) beschikbaar wilt maken voor externe netwerken, moet u inkomend verkeer naar deze eindpunten toestaan voor specifieke URL's, poorten en protocollen.

In een implementatie waarbij een transparante proxy uplinkt naar een traditionele proxyserver of een firewall de oplossing beveiligt, moet u specifieke poorten en URL's toestaan voor zowel binnenkomende als uitgaande communicatie. Deze omvatten poorten en URL's voor identiteit, marketplace, patch en update, registratie en gebruiksgegevens.

Uitgaande communicatie

Azure Stack ondersteunt alleen transparante proxyservers. In een implementatie met een transparante proxy-uplink naar een traditionele proxyserver moet u de poorten en URL's in de volgende tabel toestaan voor uitgaande communicatie bij het implementeren in de verbonden modus.

Notitie

Azure Stack biedt geen ondersteuning voor het gebruik van ExpressRoute om de Azure-services te bereiken die in de volgende tabel worden vermeld, omdat ExpressRoute mogelijk niet in staat is verkeer naar alle eindpunten te routeren.

Doel	Doel-URL	Protocol	Poorten	Bronnetwerk
Identiteit	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 Government* https://login.microsoftonline.us/ https://graph.windows.net/ Azure China 21Vianet https://login.chinacloudapi.cn/ https://graph.chinacloudapi.cn/ Azure Duitsland https://login.microsoftonline.de/ https://graph.cloudapi.de/	HTTP HTTPS	80 443	Openbare VIP - /27 Openbare infrastructuur Netwerk
Marketplace-syndicatie	Azure https://management.azure.com https://.blob.core.windows.net https://.azureedge.net Azure Government https://management.usgovcloudapi.net/ https://.blob.core.usgovcloudapi.net/ Azure China 21Vianet* https://management.chinacloudapi.cn/ http://*.blob.core.chinacloudapi.cn	HTTPS	443	Openbare VIP - /27
Patch & Update	https://*.azureedge.net https://aka.ms/azurestackautomaticupdate	HTTPS	443	Openbare VIP - /27
Registratie	Azure https://management.azure.com Azure Government https://management.usgovcloudapi.net/ Azure China 21Vianet https://management.chinacloudapi.cn	HTTPS	443	Openbare VIP - /27
Gebruik	Azure https://.trafficmanager.net Azure Government* https://.usgovtrafficmanager.net Azure China 21Vianet* https://*.trafficmanager.cn	HTTPS	443	Openbare VIP - /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	Openbare VIP - /27 Openbare infrastructuur Netwerk
NTP	(IP van NTP-server opgegeven voor implementatie)	UDP	123	Openbare VIP - /27
DNS	(IP van DNS-server opgegeven voor implementatie)	TCP UDP	53	Openbare VIP - /27
CRL	(URL onder CRL-distributiepunten op uw certificaat)	HTTP	80	Openbare VIP - /27
LDAP	Active Directory-forest beschikbaar voor Graph-integratie	TCP UDP	389	Openbare VIP - /27
LDAP SSL	Active Directory-forest voor Graph-integratie	TCP	636	Openbaar VIP - /27
LDAP GC	Active Directory-forest voor Graph-integratie	TCP	3268	Openbaar VIP - /27
LDAP GC SSL	Active Directory-forest voor Graph-integratie	TCP	3269	Openbaar VIP - /27
AD FS	AD FS-metagegevenseindpunt dat is opgegeven voor AD FS-integratie	TCP	443	Openbaar VIP - /27
Service voor het verzamelen van diagnostische logboeken	Door Azure Storage verstrekte BLOB SAS-URL	HTTPS	443	Openbaar VIP - /27

Binnenkomende communicatie

Een set infrastructuur-VIP's is vereist voor het publiceren van Azure Stack-eindpunten naar externe netwerken. In de tabel Eindpunt (VIP) ziet u elk eindpunt, de vereiste poort en het protocol. Raadpleeg de documentatie voor de implementatie van specifieke resourceproviders voor eindpunten waarvoor extra resourceproviders zijn vereist, zoals de SQL-resourceprovider.

VIP's voor interne infrastructuur worden niet weergegeven omdat ze niet vereist zijn voor het publiceren van Azure Stack. Gebruikers-VIP's zijn dynamisch en gedefinieerd door de gebruikers zelf, zonder controle door de Azure Stack-operator