Inleiding tot robuuste netwerken in Azure Stack Hub

Overzicht van netwerkontwerp

Ontwerp van fysiek netwerk

Voor de robuuste oplossing van Azure Stack Hub is een robuuste en maximaal beschikbare fysieke infrastructuur vereist om de werking en services te ondersteunen. Uplinks van ToR naar Randswitches zijn beperkt tot SFP+ of SFP28-media en 1 GB, 10 GB of 25 GB snelheden. Neem contact op met de leverancier van de oem-hardware (Original Equipment Manufacturer) voor beschikbaarheid.

In het volgende diagram ziet u ons aanbevolen ontwerp voor Robuuste Azure Stack Hub.

Logisch netwerkontwerp

Een logisch netwerkontwerp vertegenwoordigt een abstractie van een fysieke netwerkinfrastructuur. Ze worden gebruikt om netwerktoewijzingen voor hosts, virtuele machines (VM's) en services te organiseren en te vereenvoudigen. Als onderdeel van het maken van een logisch netwerk worden netwerksites gemaakt om het volgende te definiëren:

• virtual Local Area Networks (VLAN's)
• IP-subnetten
• IP-subnet/VLAN-paren

Alle zijn gekoppeld aan het logische netwerk op elke fysieke locatie.

In de volgende tabel ziet u de logische netwerken en de bijbehorende IPv4-subnetbereiken waarvoor u moet plannen:

Netwerkinfrastructuur

De netwerkinfrastructuur voor Azure Stack Hub ruggedized bestaat uit verschillende logische netwerken die op de switches zijn geconfigureerd. In het volgende diagram ziet u deze logische netwerken en hoe ze kunnen worden geïntegreerd met de TOR-switches (top-of-rack), baseboard-beheercontroller en randswitches (klantnetwerk).

Een robuust logisch netwerkdiagram in Azure Stack Hub:

BMC-netwerk

Dit netwerk is gewijd aan het verbinden van alle beheercontrollers voor basisboards (ook wel BMC- of serviceprocessors genoemd) met het beheernetwerk. Voorbeelden zijn: iDRAC, iLO, iBMC, enzovoort. Er wordt slechts één BMC-account gebruikt om te communiceren met elk BMC-knooppunt. Indien aanwezig, bevindt de HLH (Hardware Lifecycle Host) zich in dit netwerk en kan OEM-specifieke software bieden voor hardwareonderhoud of bewaking.

De HLH host ook de Implementatie-VM (DVM). De DVM wordt gebruikt tijdens de robuuste implementatie van Azure Stack Hub en wordt verwijderd wanneer de implementatie is voltooid. De DVM vereist internettoegang in verbonden implementatiescenario's om meerdere onderdelen te testen, valideren en openen. Deze onderdelen kunnen zich binnen en buiten uw bedrijfsnetwerk bevinden (bijvoorbeeld: NTP, DNS en Azure). Zie de sectie NAT in de robuuste firewallintegratie van Azure Stack Hub voor meer informatie over connectiviteitsvereisten.

Particulier netwerk

Het netwerk /20 (4096 host-IP's) is privé voor de robuuste azure Stack Hub-regio. Het wordt niet verder uitgebreid dan de randswitchapparaten van de robuuste Azure Stack Hub-regio. Dit netwerk is onderverdeeld in meerdere subnetten, bijvoorbeeld:

• Opslagnetwerk: een /25 (128 IP-netwerk) dat wordt gebruikt ter ondersteuning van het gebruik van SMB-opslagverkeer (Spaces Direct and Server Message Block) en livemigratie van vm's.
• Intern virtueel IP-netwerk: een /25-netwerk dat is toegewezen aan interne VIP's voor de software load balancer.
• Containernetwerk: een /23 (512 IP-netwerk) dat is toegewezen aan intern verkeer tussen containers met infrastructuurservices

De grootte voor het privénetwerk is /20 (4096 IP-adressen) van privé-IP-ruimte. Dit netwerk is privé voor het robuuste Azure Stack Hub-systeem. Het wordt niet buiten de randswitchapparaten van het robuuste Azure Stack Hub-systeem gerouteerd en kan worden hergebruikt op meerdere robuuste Azure Stack Hub-systemen. Hoewel het netwerk privé is voor Azure Stack Hub, mag het niet overlappen met andere netwerken in het datacenter. Voor hulp bij privé-IP-ruimte raden we u aan de RFC 1918 te volgen.

De privé-IP-ruimte /20 is onderverdeeld in meerdere netwerken, waarmee de robuuste systeeminfrastructuur van Azure Stack Hub kan worden uitgevoerd op containers in toekomstige releases. Raadpleeg de releaseopmerkingen van 1910 voor meer informatie. Met deze nieuwe privé-IP-ruimte kunnen doorlopende inspanningen worden geleverd om de vereiste routeerbare IP-ruimte vóór de implementatie te verminderen.

Robuuste infrastructuurnetwerk van Azure Stack Hub

Het /24-netwerk is toegewezen aan interne azure Stack Hub-robuuste onderdelen om onderling gegevens te communiceren en uit te wisselen. Dit subnet kan extern worden gerouteerde Azure Stack Hub-oplossing voor uw datacenter. We raden u niet aan openbare of routeerbare IP-adressen op internet in dit subnet te gebruiken. Dit netwerk wordt geadverteerd naar de rand, maar de meeste IP-adressen worden beveiligd door ACL's (Access Control Lists). De IP-adressen die zijn toegestaan voor toegang, liggen binnen een klein bereik, vergelijkbaar met een /27-netwerk. De IP-adressen hosten services zoals het bevoegde eindpunt (PEP) en Azure Stack Hub ruggedized Backup.

Openbaar VIP-netwerk

Het openbare VIP-netwerk wordt toegewezen aan de netwerkcontroller in Azure Stack Hub robuust. Het is geen logisch netwerk op de switch. De SLB maakt gebruik van de adresgroep en wijst /32-netwerken toe voor tenantworkloads. In de routeringstabel van de switch worden deze /32 IP-adressen geadverteerd als een beschikbare route via Border Gateway Protocol (BGP). Dit netwerk bevat openbare adressen die extern toegankelijk zijn. De robuuste infrastructuur van Azure Stack Hub reserveert de eerste 31 adressen van dit openbare VIP-netwerk, terwijl de rest wordt gebruikt door tenant-VM's. De netwerkgrootte op dit subnet kan variëren van minimaal /26 (64 hosts) tot maximaal /22 (1022 hosts). U wordt aangeraden een /24-netwerk te plannen.

Schakel infrastructuurnetwerk

Het /26-netwerk is het subnet dat de routeerbare punt-naar-punt-IP/30 -subnetten (twee host-IP's) en de loopbacks bevat. Dit zijn toegewezen /32 subnetten voor in-band switchbeheer en BGP-router-id. Dit bereik van IP-adressen moet routeerbaar zijn buiten de robuuste Azure Stack Hub-oplossing voor uw datacenter. De IP-adressen kunnen privé of openbaar zijn.

Schakel beheernetwerk

Het netwerk /29 (zes host-IP's) is toegewezen aan het verbinden van de beheerpoorten van de switches. Dit netwerk maakt out-of-band-toegang mogelijk voor implementatie, beheer en probleemoplossing. Dit wordt berekend op basis van het hierboven genoemde switchinfrastructuurnetwerk.

Overzicht van DNS-ontwerp

Voor toegang tot robuuste Azure Stack Hub-eindpunten (portal, beheerportal, beheer, beheer) van buiten Azure Stack Hub robuuste, moet u de robuuste DNS-services van Azure Stack Hub integreren met de DNS-servers die de DNS-zones hosten die u in Azure Stack Hub wilt gebruiken.

Robuuste DNS-naamruimte van Azure Stack Hub

U moet belangrijke informatie over DNS opgeven wanneer u Azure Stack Hub robuust implementeert.

De fully qualified domain name (FQDN) van uw Azure Stack Hub robuuste implementatie en eindpunten is de combinatie van de regioparameter en de parameter Externe domeinnaam. Met behulp van de waarden uit de voorbeelden in de vorige tabel is de FQDN voor deze robuuste Implementatie van Azure Stack Hub: east.cloud.fabrikam.com

Als zodanig zien voorbeelden van enkele eindpunten voor deze implementatie eruit als de volgende URL's:

• https://portal.east.cloud.fabrikam.com
• https://adminportal.east.cloud.fabrikam.com

Als u deze voorbeeld-DNS-naamruimte wilt gebruiken voor een robuuste implementatie van Azure Stack Hub, zijn de volgende voorwaarden vereist:

• De zone fabrikam.com is geregistreerd bij een domeinregistrar, een interne DNS-server voor het bedrijf of beide. Registratie is afhankelijk van uw vereisten voor naamomzetting.
• Het onderliggende domein cloud.fabrikam.com bestaat onder de zone fabrikam.com.
• De DNS-servers waarop de zones fabrikam.com en cloud.fabrikam.com worden gehost, kunnen worden bereikt vanuit de robuuste implementatie van Azure Stack Hub.

Als u DNS-namen wilt omzetten voor robuuste Azure Stack Hub-eindpunten en -exemplaren van buiten Azure Stack Hub, moet u de DNS-servers integreren. Inclusief servers die als host fungeren voor de externe DNS-zone voor Azure Stack Hub robuust, met de DNS-servers die als host fungeren voor de bovenliggende zone die u wilt gebruiken.

DNS-naamlabels

Azure Stack Hub ruggedized ondersteunt het toevoegen van een DNS-naamlabel aan een openbaar IP-adres om naamomzetting voor openbare IP-adressen toe te staan. DNS-labels zijn een handige manier voor gebruikers om apps en services te bereiken die in Azure Stack Hub worden gehost op naam. Het DNS-naamlabel maakt gebruik van een iets andere naamruimte dan de infrastructuureindpunten. Na de vorige voorbeeldnaamruimte is de naamruimte voor DNS-naamlabels: *.east.cloudapp.cloud.fabrikam.com.

Als een tenant Myapp opgeeft in het veld DNS-naam van een openbare IP-adresresource, wordt er een A-record gemaakt voor myapp in de zone east.cloudapp.cloud.fabrikam.com op de robuuste externe DNS-server van Azure Stack Hub. De resulterende volledig gekwalificeerde domeinnaam is: myapp.east.cloudapp.cloud.fabrikam.com.

Als u deze functionaliteit wilt gebruiken en deze naamruimte wilt gebruiken, moet u de DNS-servers integreren. Inclusief servers die als host fungeren voor de externe DNS-zone voor Azure Stack Hub robuust en de DNS-servers die de bovenliggende zone hosten die u ook wilt gebruiken. Deze naamruimte verschilt van de naamruimte die wordt gebruikt voor de robuuste service-eindpunten van Azure Stack Hub, dus u moet een extra overdrachts- of voorwaardelijke doorstuurregel maken.

Zie Dns gebruiken in Azure Stack Hub robuust voor meer informatie over de werking van het DNS-naamlabel.

Omzetting en delegering

Er zijn twee typen DNS-servers:

• Een gezaghebbende DNS-server host DNS-zones. Deze beantwoordt DNS-query's voor records in deze zones.
• Een recursieve DNS-server host geen DNS-zones. De server beantwoordt alle DNS-query's door gezaghebbende DNS-servers aan te roepen om de benodigde gegevens te verzamelen.

Azure Stack Hub ruggedized omvat zowel gezaghebbende als recursieve DNS-servers. De recursieve servers worden gebruikt voor het omzetten van namen van alles behalve de interne privézone en de externe openbare DNS-zone voor de robuuste implementatie van Azure Stack Hub.

Externe DNS-namen van Azure Stack Hub robuust omzetten

Als u DNS-namen wilt omzetten voor eindpunten buiten Azure Stack Hub robuust (bijvoorbeeld: www.bing.com), moet u DNS-servers opgeven voor Azure Stack Hub robuust om DNS-aanvragen door te sturen, waarvoor Azure Stack Hub robuust is niet gezaghebbend. DNS-servers waarnaar aanvragen van Azure Stack Hub worden doorgestuurd, zijn vereist in het implementatiewerkblad (in het veld DNS-doorstuurserver). Geef ten minste twee servers in dit veld op voor fouttolerantie. Zonder deze waarden mislukt de robuuste implementatie van Azure Stack Hub. U kunt de waarden van de DNS-doorstuurserver bewerken met de cmdlet Set-AzSDnsForwarder na de implementatie.

Overzicht van firewallontwerp

Het is raadzaam om een firewallapparaat te gebruiken om Azure Stack Hub robuust te beveiligen. Firewalls kunnen helpen beschermen tegen zaken zoals DDOS-aanvallen (Distributed Denial-of-Service), inbraakdetectie en inhoudsinspectie. Ze kunnen echter ook een knelpunt voor doorvoer worden voor Azure-opslagservices, zoals blobs, tabellen en wachtrijen.

Als er een niet-verbonden implementatiemodus wordt gebruikt, moet u het AD FS-eindpunt publiceren. Zie het artikel over de integratie van datacenters voor meer informatie.

De Eindpunten van Azure Resource Manager (beheerder), beheerdersportal en Key Vault (administrator) vereisen niet noodzakelijkerwijs externe publicatie. Als serviceprovider kunt u bijvoorbeeld het kwetsbaarheid voor aanvallen beperken door alleen Azure Stack Hub te beheren die vanuit uw netwerk en niet via internet wordt beheerd.

Voor ondernemingen kan het externe netwerk het bestaande bedrijfsnetwerk zijn. In dit scenario moet u eindpunten publiceren om Azure Stack Hub robuust te kunnen gebruiken vanuit het bedrijfsnetwerk.

Netwerkadresvertaling

Network Address Translation (NAT) is de aanbevolen methode om de virtuele implementatiemachine (DVM) toegang te geven tot externe resources tijdens de implementatie. Ook voor de ERCS-VM's (Emergency Recovery Console) of het bevoegde eindpunt (PEP) tijdens de registratie en probleemoplossing.

NAT kan ook een alternatief zijn voor openbare IP-adressen in het externe netwerk of openbare VIP's. Het wordt echter niet aanbevolen om dit te doen omdat de gebruikerservaring van de tenant wordt beperkt en de complexiteit toeneemt. Eén optie is een op één NAT waarvoor nog steeds één openbaar IP-adres per gebruikers-IP voor de groep is vereist. Een andere optie is een veel-op-een NAT waarvoor een NAT-regel per gebruikers-VIP is vereist voor alle poorten die een gebruiker kan gebruiken.

Enkele van de voordelen van het gebruik van NAT voor openbare VIP zijn:

• Overhead bij het beheren van firewallregels, omdat gebruikers hun eigen eindpunten en publicatieregels beheren in de SDN-stack (Software Defined Networking). Gebruikers moeten contact opnemen met de robuuste operator van Azure Stack Hub om hun VIP's te kunnen publiceren en de poortlijst bij te werken.
• Hoewel nat-gebruik de gebruikerservaring beperkt, krijgt de operator volledige controle over publicatieaanvragen.
• Houd er bij hybride cloudscenario's met Azure rekening mee dat Azure geen ondersteuning biedt voor het instellen van een VPN-tunnel naar een eindpunt met behulp van NAT.

SSL-onderschepping

Het wordt momenteel aanbevolen om ssl-interceptie (bijvoorbeeld offloading van ontsleuteling) uit te schakelen voor al het robuuste verkeer van Azure Stack Hub. Als dit wordt ondersteund in toekomstige updates, worden richtlijnen gegeven over het inschakelen van SSL-interceptie voor Azure Stack Hub robuust.

Firewallscenario voor Edge-implementatie

In een edge-implementatie wordt Azure Stack Hub robuust geïmplementeerd direct achter de randrouter of de firewall. In deze scenario's wordt het ondersteund voor de firewall boven de rand (scenario 1) waar zowel actief-actief- als actief-passieve firewallconfiguraties worden ondersteund. Het kan ook fungeren als het randapparaat (scenario 2), waarbij alleen actief-actieve firewallconfiguratie wordt ondersteund. Scenario 2 is afhankelijk van ECMP (equal-cost multi-path) met BGP of statische routering voor failover.

Openbare routeerbare IP-adressen worden opgegeven voor de openbare VIP-groep van het externe netwerk, tijdens de implementatie. Voor beveiligingsdoeleinden worden openbare routeerbare IP-adressen niet aanbevolen op een ander netwerk in een edge-scenario. Met dit scenario kan een gebruiker de volledige zelfbeheerde cloudervaring ervaren, zoals in een openbare cloud zoals Azure.

Bedrijfsintranet- of perimeternetwerkfirewallscenario

In een bedrijfsintranet of perimeterimplementatie wordt Azure Stack Hub robuust geïmplementeerd op een firewall met meerdere zones of tussen de randfirewall en de firewall van het interne bedrijfsnetwerk. Het verkeer wordt vervolgens gedistribueerd tussen het beveiligde, perimeternetwerk (of DMZ) en onbeveiligde zones, zoals hieronder wordt beschreven:

• Beveiligde zone: het interne netwerk dat gebruikmaakt van interne of zakelijke routeerbare IP-adressen. Het beveiligde netwerk kan worden verdeeld. Het kan uitgaande toegang via internet hebben via de firewall-NAT. Het is normaal gesproken toegankelijk vanuit uw datacenter via het interne netwerk. Alle robuuste Netwerken van Azure Stack Hub moeten zich in de beveiligde zone bevinden, met uitzondering van de openbare VIP-pool van het externe netwerk.
• Perimeterzone. Het perimeternetwerk is waar externe of internetgerichte apps, zoals webservers, doorgaans worden geïmplementeerd. Het wordt normaal gesproken bewaakt door een firewall om aanvallen zoals DDoS en inbraak (hacking) te voorkomen terwijl opgegeven inkomend verkeer van internet nog steeds is toegestaan. Alleen de openbare VIP-pool van het externe netwerk van Azure Stack Hub ruggedized moet zich in de DMZ-zone bevinden.
• Onbeveiligde zone. Het externe netwerk, internet. Het wordt niet aanbevolen om Azure Stack Hub robuust te implementeren in de onbeveiligde zone.

Overzicht van VPN-ontwerp

Hoewel VPN een gebruikersconcept is, zijn er enkele belangrijke overwegingen die een eigenaar en operator van een oplossing moeten weten.

Voordat u netwerkverkeer tussen uw virtuele Azure-netwerk en uw on-premises site kunt verzenden, moet u een VPN-gateway (virtueel netwerk) voor uw virtuele netwerk maken.

Een VPN-gateway is een soort gateway voor virtuele netwerken die versleuteld verkeer verzendt via een openbare verbinding. U kunt VPN-gateways gebruiken om verkeer veilig te verzenden tussen een virtueel netwerk in Azure Stack Hub robuust en een virtueel netwerk in Azure. U kunt ook veilig verkeer verzenden tussen een virtueel netwerk en een ander netwerk dat is verbonden met een VPN-apparaat.

Wanneer u een virtuele netwerkgateway maakt, geeft u het gatewaytype aan dat u wilt maken. Azure Stack Hub ruggedized ondersteunt één type virtuele netwerkgateway: het Vpn-type .

Elk virtueel netwerk kan twee virtuele netwerkgateways hebben, maar slechts één van elk type. Afhankelijk van de instellingen die u kiest, kunt u meerdere verbindingen maken voor één VPN-gateway. Een voorbeeld van dit type installatie is een configuratie van een verbinding met meerdere sites.

Voordat u VPN-gateways voor Azure Stack Hub ruggedized maakt en configureert, bekijkt u de overwegingen voor robuuste netwerken van Azure Stack Hub. U leert hoe configuraties voor Azure Stack Hub robuust verschillen van Azure.

In Azure moet de bandbreedtedoorvoer voor de VPN-gateway-SKU die u kiest, worden verdeeld over alle verbindingen die zijn verbonden met de gateway. In Azure Stack Hub wordt de bandbreedtewaarde voor de VPN-gateway-SKU echter toegepast op elke verbindingsresource die is verbonden met de gateway. Voorbeeld:

• In Azure kan de eenvoudige VPN-gateway-SKU ongeveer 100 Mbps aan geaggregeerde doorvoer bevatten. Als u twee verbindingen met die VPN-gateway maakt en één verbinding 50 Mbps bandbreedte gebruikt, is 50 Mbps beschikbaar voor de andere verbinding.
• In Azure Stack Hub wordt elke verbinding met de basis-VPN-gateway-SKU 100 Mbps aan doorvoer toegewezen.

VPN-typen

Wanneer u de virtuele netwerkgateway voor een VPN-gatewayconfiguratie maakt, moet u een VPN-type opgeven. Het VPN-type dat u kiest, is afhankelijk van de verbindingstopologie die u wilt maken. Een VPN-type kan ook afhankelijk zijn van de hardware die u gebruikt. Voor S2S-configuraties is een VPN-apparaat vereist. Sommige VPN-apparaten ondersteunen alleen een bepaald VPN-type.

• PolicyBased: op beleid gebaseerde VPN's versleutelen en directe pakketten via IPsec-tunnels, op basis van IPsec-beleid. Beleidsregels worden geconfigureerd met de combinaties van adresvoorvoegsels tussen uw on-premises netwerk en het robuuste VNet van Azure Stack Hub. Het beleid of de verkeerskiezer is meestal een toegangslijst in de configuratie van het VPN-apparaat. PolicyBased wordt ondersteund in Azure, maar niet in Azure Stack Hub robuust.
• RouteBased: op route gebaseerde VPN's maken gebruik van routes die zijn geconfigureerd in de doorsturen- of routeringstabel van IP. De routes sturen pakketten naar hun bijbehorende tunnelinterfaces. De tunnelinterfaces versleutelen of ontsleutelen de pakketten vervolgens naar en vanuit de tunnels. Het beleid of de verkeersselector voor routegebaseerde VPN's worden geconfigureerd als any-to-any (of gebruik jokertekens). Ze kunnen standaard niet worden gewijzigd. De waarde voor een RouteBased VPN-type is RouteBased.

Een VPN-gateway configureren

Een VPN-gatewayverbinding is afhankelijk van verschillende resources die zijn geconfigureerd met specifieke instellingen. De meeste van deze resources kunnen afzonderlijk worden geconfigureerd, maar in sommige gevallen moeten ze in een specifieke volgorde worden geconfigureerd.

Instellingen

De instellingen die u voor elke resource kiest, zijn essentieel voor het maken van een geslaagde verbinding.

Dit artikel helpt u het volgende te begrijpen:

• Gatewaytypen, VPN-typen en verbindingstypen.
• Gatewaysubnetten, lokale netwerkgateways en andere resource-instellingen die u mogelijk wilt overwegen.

Diagrammen over de verbindingstopologie

Er zijn verschillende configuraties beschikbaar voor VPN-gatewayverbindingen. Bepaal welke configuratie het beste past bij uw behoeften. In de volgende secties kunt u informatie en topologiediagrammen over de volgende VPN-gatewayverbindingen bekijken:

• Beschikbaar implementatiemodel
• Beschikbare configuratiehulpprogramma's
• Rechtstreekse koppelingen naar een artikel, indien beschikbaar

Met de diagrammen en beschrijvingen in de volgende secties kunt u een verbindingstopologie selecteren die aan uw vereisten voldoet. In de diagrammen worden de belangrijkste basislijntopologieën weergegeven, maar het is mogelijk om complexere configuraties te maken met behulp van de diagrammen als richtlijn.

Site-naar-site en multi-site (IPsec/IKE VPN-tunnel)

Site-naar-site

Een site-naar-site-VPN-gatewayverbinding (S2S) is een verbinding via DE VPN-tunnel IPsec/IKE (IKEv2). Voor dit type verbinding is een VPN-apparaat vereist dat zich on-premises bevindt en waaraan een openbaar IP-adres is toegewezen. Dit apparaat kan zich niet achter een NAT bevinden. S2S-verbindingen kunnen worden gebruikt voor cross-premises en hybride configuraties.

Meerdere locaties

Een verbinding met meerdere sites is een variant van de site-naar-site-verbinding. U maakt meer dan één VPN-verbinding vanaf uw virtuele netwerkgateway, meestal met verschillende on-premises sites. Wanneer u met meerdere verbindingen werkt, moet u een op route gebaseerd VPN-type gebruiken (ook wel een dynamische gateway genoemd bij het werken met klassieke VNets). Omdat elk virtueel netwerk maar één VPN-gateway kan hebben, delen alle verbindingen via de gateway de beschikbare bandbreedte.

Gateway-SKU's

Wanneer u een virtuele netwerkgateway voor Azure Stack Hub ruggedized maakt, geeft u de gateway-SKU op die u wilt gebruiken. De volgende VPN Gateway-SKU's worden ondersteund:

• Eenvoudig
• Standaard
• Hoge prestaties

Als u een hogere gateway-SKU selecteert, worden meer CPU's en netwerkbandbreedte aan de gateway toegewezen. Hierdoor kan de gateway een hogere netwerkdoorvoer naar het virtuele netwerk ondersteunen.

Azure Stack Hub ruggedized biedt geen ondersteuning voor de Ultra Performance Gateway-SKU, die uitsluitend wordt gebruikt met Express Route.

Houd rekening met het volgende wanneer u de SKU selecteert:

• Azure Stack Hub ruggedized biedt geen ondersteuning voor op beleid gebaseerde gateways.
• BGP wordt niet ondersteund in de Basic-SKU.
• Gelijktijdige configuraties van ExpressRoute-VPN-gateways worden niet ondersteund in Azure Stack Hub robuust.

Beschikbaarheid van gateway

Scenario's met hoge beschikbaarheid kunnen alleen worden geconfigureerd op de high-performance gatewayverbindings-SKU . In tegenstelling tot Azure, dat beschikbaarheid biedt via zowel actieve/actieve als actieve/passieve configuraties, ondersteunt Azure Stack Hub robuust alleen de actieve/passieve configuratie.

Overgang bij uitval

Er zijn drie vm's voor multitenant-gatewayinfrastructuur in Azure Stack Hub robuust. Twee van deze VM's bevinden zich in de actieve modus en de derde bevindt zich in de redundante modus. Actieve VM's maken het maken van VPN-verbindingen mogelijk en de redundante VM accepteert alleen VPN-verbindingen als er een failover plaatsvindt. Als een actieve gateway-VM niet meer beschikbaar is, voert de VPN-verbinding na een korte periode (een paar seconden) een failover uit naar de redundante VM.

Geschatte geaggregeerde doorvoer per SKU

In de volgende tabel ziet u de gatewaytypen en de geschatte geaggregeerde doorvoer per gateway-SKU:

Tabelnotities

(1) - VPN-doorvoer is geen gegarandeerde doorvoer voor cross-premises verbindingen via internet. Dit is de maximale doorvoermeting.
(2) - Maximum aantal tunnels is het totaal per robuuste implementatie van Azure Stack Hub voor alle abonnementen.
(3) - BGP-routering wordt niet ondersteund voor de Basic-SKU.

IPSec-/IKE-parameters

Wanneer u een VPN-verbinding instelt in Azure Stack Hub ruggedized, moet u de verbinding aan beide uiteinden configureren. Als u een VPN-verbinding configureert tussen Azure Stack Hub ruggedized en een hardwareapparaat, vraagt dat apparaat u mogelijk om aanvullende instellingen. Bijvoorbeeld een switch of router die fungeert als een VPN-gateway.

In tegenstelling tot Azure, dat meerdere aanbiedingen ondersteunt als zowel een initiator als een responder, ondersteunt Azure Stack Hub robuuste standaard slechts één aanbieding. Als u verschillende IPSec-/IKE-instellingen moet gebruiken om met uw VPN-apparaat te werken, zijn er meer instellingen beschikbaar om uw verbinding handmatig te configureren.

Parameters voor IKE Phase 1 (Main Mode)

Parameters voor IKE Phase 2 (Quick Mode)

Aangepast IPSec-/IKE-verbindingsbeleid configureren

De IPsec- en IKE-protocolstandaard ondersteunt een breed scala aan cryptografische algoritmen in verschillende combinaties. Zie IPsec-/IKE-parameters om te zien welke parameters worden ondersteund in Azure Stack Hub robuust om te voldoen aan de nalevings- of beveiligingsvereisten.

Dit artikel bevat instructies voor het maken en configureren van een IPsec-/IKE-beleid en het toepassen op een nieuwe of bestaande verbinding.

Overwegingen

Houd rekening met de volgende belangrijke overwegingen bij het gebruik van dit beleid:

• Het IPsec-/IKE-beleid werkt alleen op de gateway-SKU's Standard en HighPerformance (op route gebaseerde).
• U kunt maar één beleidscombinatie opgeven voor een bepaalde verbinding.
• U moet alle algoritmen en parameters opgeven voor zowel IKE (main mode) als IPsec (snelle modus). Gedeeltelijke beleidsspecificatie is niet toegestaan.
• Raadpleeg de specificaties van de leverancier van uw VPN-apparaat om ervoor te zorgen dat het beleid wordt ondersteund op uw on-premises VPN-apparaten. Site-naar-site-verbindingen kunnen niet tot stand worden gebracht als het beleid niet compatibel is.

Werkstroom voor het maken en instellen van IPsec-/IKE-beleid

In deze sectie vindt u een overzicht van de werkstroom die is vereist voor het maken en bijwerken van het IPsec-/IKE-beleid op een site-naar-site-VPN-verbinding:

1. Maak een virtueel netwerk en een VPN-gateway.
2. Maak een lokale netwerkgateway voor cross-premises verbindingen.
3. Maak een IPsec-/IKE-beleid met geselecteerde algoritmen en parameters.
4. Maak een IPSec-verbinding met het IPsec-/IKE-beleid.
5. Een IPsec-/IKE-beleid voor een bestaande verbinding toevoegen/bijwerken/verwijderen.

Ondersteunde cryptografische algoritmen en belangrijke sterke punten

De volgende tabel bevat de ondersteunde cryptografische algoritmen en belangrijke sterke punten die kunnen worden geconfigureerd door robuuste klanten van Azure Stack Hub:

De configuratie van uw on-premises VPN-apparaat moet overeenkomen met of de volgende algoritmen en parameters bevatten die u in het Azure IPsec/IKE-beleid opgeeft:

• IKE-versleutelingsalgoritmen (hoofdmodus/fase 1).
• IKE-integriteitsalgoritmen (hoofdmodus/fase 1).
• DH-groep (hoofdmodus / fase 1).
• IPsec-versleutelingsalgoritmen (snelle modus/fase 2).
• IPsec-integriteitsalgoritmen (snelle modus/fase 2).
• PFS-groep (snelle modus/ fase 2).
• De SA-levensduur zijn alleen lokale specificaties, ze hoeven niet overeen te komen.

Als GCMAES wordt gebruikt als voor IPsec-versleutelingsalgoritmen, moet u dezelfde GCMAES-algoritme en sleutellengte voor IPsec-integriteit selecteren. Bijvoorbeeld: het gebruik van GCMAES128 voor beide.

In de voorgaande tabel:

• IKEv2 komt overeen met de hoofdmodus of fase 1.
• IPsec komt overeen met de snelle modus of fase 2.
• DH Group specificeert de Diffie-Hellmen Group gebruikt in de hoofdmodus of fase 1.
• PFS-groep specificeert de Diffie-Hellmen-groep die wordt gebruikt in de snelle modus of fase 2.
• De SA-levensduur van DE IKEv2-hoofdmodus wordt vastgesteld op 28.800 seconden op de robuuste VPN-gateways van Azure Stack Hub.

De volgende tabel bevat de bijbehorende Diffie-Hellman Groups die worden ondersteund door het aangepaste beleid:

Azure Stack Hub robuust verbinden met Azure met behulp van Azure ExpressRoute

Overzicht, veronderstellingen en vereisten

Met Azure ExpressRoute kunt u uw on-premises netwerken uitbreiden naar de Microsoft-cloud. U gebruikt een privéverbinding die wordt geleverd door een connectiviteitsprovider. ExpressRoute is geen VPN-verbinding via het openbare internet.

Zie het Overzicht van ExpressRoute voor meer informatie over Azure ExpressRoute.

Aannames

In dit artikel wordt ervan uitgegaan dat:

• U hebt een werkende kennis van Azure.
• U hebt een basiskennis van Azure Stack Hub robuust.
• U hebt een basiskennis van netwerken.

Vereisten

Als u azure Stack Hub ruggedized en Azure wilt verbinden met behulp van ExpressRoute, moet u voldoen aan de volgende vereisten:

• Een ingericht ExpressRoute-circuit via een connectiviteitsprovider.
• Een Azure-abonnement voor het maken van een ExpressRoute-circuit en VNets in Azure.
• Een router die ondersteuning biedt voor:
  • site-naar-site VPN-verbindingen tussen de LAN-interface en de robuuste multitenant-gateway van Azure Stack Hub.
  • meerdere VRF's (Virtuele routering en doorsturen) maken als er meer dan één tenant aanwezig is in uw robuuste Implementatie van Azure Stack Hub.
• Een router met:
  • Een WAN-poort die is verbonden met het ExpressRoute-circuit.
  • Een LAN-poort die is verbonden met de robuuste multitenant-gateway van Azure Stack Hub.

ExpressRoute-netwerkarchitectuur

In de volgende afbeelding ziet u de robuuste Azure Stack Hub- en Azure-omgevingen nadat u ExpressRoute hebt ingesteld met behulp van de voorbeelden in dit artikel:

In de volgende afbeelding ziet u hoe meerdere tenants verbinding maken vanuit de robuuste Infrastructuur van Azure Stack Hub via de ExpressRoute-router naar Azure: