Robuuste netwerkintegratie van Azure Stack Hub

2024-11-23

In dit onderwerp wordt de integratie van Azure Stack-netwerken behandeld.

Randconnectiviteit (uplink)

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

Voor tor-switches (top of rack) zijn uplinks van laag 3 vereist met punt-naar-punt-IP-adressen (/30-netwerken) die zijn geconfigureerd op de fysieke interfaces. Uplinks van laag 2 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 op de BGP-peering tussen de TOR en de rand.

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

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

Om ervoor te zorgen dat gebruikersverkeer onmiddellijk en transparant herstelt van fouten, maakt de VPC of MLAG die is geconfigureerd tussen de TOR-apparaten het gebruik van aggregatie met meerdere chassiskoppelingen mogelijk voor de hosts en HSRP of VRRP die netwerkredundantie biedt voor de IP-netwerken.

Statische routering

Voor statische routering is extra configuratie vereist 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 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's die zijn ingesteld tussen de TOR en de rand voor verkeer dat is bestemd voor een netwerk in 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 staan voor toegang tot beheerbronnen die zich in de BMC en het infrastructuurnetwerk bevinden. Het toevoegen van statische routes om van infrastructuur te wisselen en switchbeheernetwerken is optioneel.

De TOR-apparaten worden geconfigureerd met een statische standaardroute die al het verkeer naar de randapparaten verzendt. De ene verkeersonderzondering voor de standaardregel is voor de privéruimte, die wordt geblokkeerd met behulp van een toegangsbeheerlijst die op de TOR is toegepast op de 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 switchinfrastructuurnetwerk is optioneel, omdat het hele netwerk kan worden opgenomen in het switchbeheernetwerk.

Het Switch Management-netwerk is vereist en kan afzonderlijk van het switchinfrastructuurnetwerk worden toegevoegd.

Transparante proxy

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

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

Een transparante proxy (ook wel een snijpunt, inline of geforceerde proxy genoemd) onderschept normale communicatie op de netwerklaag zonder speciale clientconfiguratie. Clients hoeven zich niet bewust 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 zijn voor identiteit is 60 met drie nieuwe pogingen.

DNS (Domeinnaamsysteem)

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

Voorwaardelijke DNS-doorsturen 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 Windows PowerShell-sessie met verhoogde bevoegdheid (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 die zijn opgegeven met 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 oplossen van buiten Azure Stack

De gezaghebbende servers zijn de servers die de informatie over de externe DNS-zone en alle door de gebruiker gemaakte zones bevatten. Integreer met deze servers om zonedelegering of voorwaardelijk doorsturen in te schakelen om DNS-namen van Azure Stack van buiten Azure Stack op 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 voor 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 Implementatie. Als u niet zeker weet welke waarden zijn gebruikt voor uw Azure Stack-implementatie, kunt u de waarden hier ophalen.

Als de virtuele implementatiemachine 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 het bevoegde 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 middel van voorwaardelijk doorsturen van de zone 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 van Azure Stack.

Als u niet bekend bent met het uitvoeren van voorwaardelijk doorsturen met DNS, raadpleegt u het volgende TechNet-artikel: Een voorwaardelijke doorstuurserver 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 bedrijfsdomein, 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 van DNS-doorstuurservers bewerken

IP-adressen van DNS-doorstuurservers worden ingesteld tijdens de implementatie van Azure Stack. Als de doorstuurserver-IP-adressen 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 Get-AzSDnsForwarder en Set-AzSDnsForwarder [[-IPAddress] <IPAddress[]>] uit te voeren. Zie het bevoegde eindpunt voor meer informatie.

De externe DNS-zone naar Azure Stack delegeren

Als u dns-namen wilt omzetten van buiten een Azure Stack-implementatie, moet u DNS-delegering instellen.

Elke registrar heeft zijn eigen hulpprogramma's voor DNS-beheer om de naamserverrecords voor een domein te wijzigen. Bewerk de NS-records op de pagina DNS-beheer van de registrar 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.

Brandmuur

Azure Stack stelt virtuele IP-adressen (VIP's) in voor de 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 tijdens de implementatie is opgegeven. Aan de gebruikersportal wordt 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 binnenkomend verkeer naar deze eindpunten toestaan voor specifieke URL's, poorten en protocollen.

In een implementatie waarbij een transparante proxy uplinks naar een traditionele proxyserver of een firewall de oplossing beveiligt, moet u specifieke poorten en URL's toestaan voor zowel binnenkomende als uitgaande communicatie. Dit zijn 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 worden vermeld in de volgende tabel, omdat ExpressRoute mogelijk geen verkeer naar alle eindpunten kan routeren.

Doel	Doel-URL	protocol	Poorten	Bronnetwerk
Identiteit	Azuur 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 Netwerk van openbare infrastructuur
Marketplace-syndicatie	Azuur 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 en update	https://*.azureedge.net https://aka.ms/azurestackautomaticupdate	HTTPS	443	Openbare VIP - /27
Registratie	Azuur https://management.azure.com Azure Government https://management.usgovcloudapi.net/ Azure China 21Vianet https://management.chinacloudapi.cn	HTTPS	443	Openbare VIP - /27
Gebruik	Azuur 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 Netwerk van openbare infrastructuur
NTP	(IP van NTP-server die is opgegeven voor implementatie)	UDP (User Datagram Protocol)	123	Openbare VIP - /27
DNS (Domeinnaamsysteem)	(IP van de DNS-server die is opgegeven voor implementatie)	TCP UDP (User Datagram Protocol)	53	Openbare VIP - /27
CRL	(URL onder CRL-distributiepunten op uw certificaat)	HTTP	80	Openbare VIP - /27
LDAP	Active Directory-forest dat is opgegeven voor Graph-integratie	TCP UDP (User Datagram Protocol)	389	Openbare VIP - /27
LDAP SSL	Active Directory-forest dat is opgegeven voor Graph-integratie	TCP	636	Openbare VIP - /27
LDAP-GC	Active Directory-forest dat is opgegeven voor Graph-integratie	TCP	3268	Openbare VIP - /27
LDAP GC SSL	Active Directory-forest dat is opgegeven voor Graph-integratie	TCP	3269	Openbare VIP - /27
AD FS	AD FS-metagegevenseindpunt opgegeven voor AD FS-integratie	TCP	443	Openbare VIP - /27
Service voor het verzamelen van diagnostische logboeken	Opgegeven BLOB SAS-URL voor Azure Storage	HTTPS	443	Openbare VIP - /27

Binnenkomende communicatie

Er is een set infrastructuur-VIP's 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 vereiste 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 vermeld omdat ze niet vereist zijn voor het publiceren van Azure Stack. VIP's van gebruikers zijn dynamisch en gedefinieerd door de gebruikers zelf, zonder controle door de Azure Stack-operator