Inleiding tot robuust netwerk in Azure Stack Hub

Overzicht van netwerkontwerp

Ontwerp van fysiek netwerk

De robuuste Azure Stack Hub-oplossing vereist een tolerante en maximaal beschikbare fysieke infrastructuur ter ondersteuning van de werking en services. Uplinks van ToR naar randswitches zijn beperkt tot SFP+- of SFP28-media en snelheden van 1 GB, 10 GB of 25 GB. Neem contact op met de hardwareleverancier van de OEM (Original Equipment Manufacturer) voor beschikbaarheid.

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

Ontwerp van logisch netwerk

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

• virtual local area networks (VLAN's)
• IP-subnetten
• IP-subnet/VLAN-paren

Deze zijn allemaal 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:

Logisch netwerk	Beschrijving	Grootte
Openbaar virtueel IP-adres (VIP)	Azure Stack Hub ruggedized gebruikt in totaal 31 adressen van dit netwerk. Acht openbare IP-adressen worden gebruikt voor een kleine set robuuste Azure Stack Hub-services en de rest wordt gebruikt door tenant-VM's. Als u van plan bent om App Service en de SQL-resourceproviders te gebruiken, worden er nog 7 adressen gebruikt. De resterende 15 IP-adressen zijn gereserveerd voor toekomstige Azure-services.	/26 (62 hosts)- /22 (1022 hosts) Aanbevolen = /24 (254 hosts)
Schakelen tussen infrastructuur	Punt-naar-punt-IP-adressen voor routeringsdoeleinden, toegewezen switchbeheerinterfaces en loopback-adressen die aan de switch zijn toegewezen.	/26
Infrastructuur	Wordt gebruikt voor communicatie met robuuste interne onderdelen van Azure Stack Hub.	/24
Privé	Wordt gebruikt voor het opslagnetwerk, privé VIP's, infrastructuurcontainers en andere interne functies.	/20
Baseboard Management Controller (BMC)	Wordt gebruikt om te communiceren met de baseboard-beheercontrollers op de fysieke hosts.	/26

Netwerkinfrastructuur

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

Diagram van robuust logisch netwerk in Azure Stack Hub:

BMC-netwerk

Dit netwerk is bedoeld voor het verbinden van alle baseboard-beheercontrollers (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 een BMC-knooppunt. Indien aanwezig, bevindt de HLH (Hardware Lifecycle Host) zich op dit netwerk en kan deze OEM-specifieke software bieden voor hardwareonderhoud of -bewaking.

De HLH fungeert ook als host voor 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, te valideren en te openen. Deze onderdelen kunnen zich binnen en buiten uw bedrijfsnetwerk bevinden (bijvoorbeeld: NTP, DNS en Azure). Zie de sectie NAT in Azure Stack Hub robuuste firewallintegratie voor meer informatie over connectiviteitsvereisten.

Particulier netwerk

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

• Opslagnetwerk: een /25 -netwerk (128 IP's) dat wordt gebruikt ter ondersteuning van het gebruik van Opslagverkeer van Spaces Direct en Server Message Block (SMB) 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 -netwerk (512 IP's) dat is toegewezen aan intern verkeer tussen containers die infrastructuurservices uitvoeren

De grootte voor het privénetwerk is /20 (4096 IP-adressen) privé-IP-ruimte. Dit netwerk is privé voor het robuuste Azure Stack Hub-systeem. Het wordt niet gerouteerd tot voorbij de randswitchapparaten van het robuuste Azure Stack Hub-systeem en kan opnieuw worden gebruikt op meerdere robuuste Azure Stack Hub-systemen. Hoewel het netwerk privé is voor Azure Stack Hub ruggedized, 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, waardoor de robuuste systeeminfrastructuur van Azure Stack Hub in toekomstige releases kan worden uitgevoerd op containers. Raadpleeg de releaseopmerkingen van 1910 voor meer informatie. Deze nieuwe privé-IP-ruimte maakt het mogelijk om de vereiste routeerbare IP-ruimte vóór de implementatie te verminderen.

Robuust infrastructuurnetwerk van Azure Stack Hub

Het /24-netwerk is toegewezen aan interne robuuste onderdelen van Azure Stack Hub, om onderling te communiceren en gegevens uit te wisselen. Dit subnet kan extern van de robuuste Azure Stack Hub-oplossing naar uw datacenter worden routeerbaar. Het is niet raadzaam om openbare of routeerbare IP-adressen op internet te gebruiken in dit subnet. Dit netwerk wordt geadverteerd naar de rand, maar de meeste IP-adressen worden beveiligd door Access Control Lists (ACL's). De IP-adressen die zijn toegestaan voor toegang, bevinden zich binnen een klein bereik, even groot als een /27-netwerk. De IP-adressen hosten services zoals privileged end point (PEP) en Azure Stack Hub ruggedized Backup.

Openbaar VIP-netwerk

Het openbare VIP-netwerk is toegewezen aan de netwerkcontroller in Azure Stack Hub ruggedized. Het is geen logisch netwerk op de switch. De SLB gebruikt de pool met adressen 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 een maximum van /22 (1022 hosts). We raden u aan een /24-netwerk te plannen.

Schakelen tussen infrastructuurnetwerk

Het /26-netwerk is het subnet dat de routeerbare punt-naar-punt-IP/30 (twee host-IP's) subnetten 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 naar uw datacenter. De IP-adressen kunnen privé of openbaar zijn.

Schakelen tussen beheernetwerk

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

Overzicht van DNS-ontwerp

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

Robuuste DNS-naamruimte in Azure Stack Hub

U moet belangrijke informatie met betrekking tot DNS opgeven wanneer u Azure Stack Hub ruggedized implementeert.

Veld	Beschrijving	Voorbeeld
Region	De geografische locatie van uw robuuste implementatie van Azure Stack Hub.	oosten
Externe domeinnaam	De naam van de zone die u wilt gebruiken voor uw robuuste implementatie van Azure Stack Hub.	cloud.fabrikam.com
Interne domeinnaam	De naam van de interne zone die wordt gebruikt voor infrastructuurservices in Azure Stack Hub ruggedized. Het is geïntegreerd met Directory Service en privé (niet bereikbaar van buiten de robuuste implementatie van Azure Stack Hub).	azurestack.local
DNS-doorstuurservers	DNS-servers die worden gebruikt voor het doorsturen van DNS-query's, DNS-zones en records die worden gehost buiten Azure Stack Hub ruggedized, op het intranet van het bedrijf of op het openbare internet. U kunt de dns-doorstuurserverwaarde bewerken met de cmdlet Set-AzSDnsForwarder na de implementatie.
Naamgevingsvoorvoegsel (optioneel)	Het naamgevingsvoorvoegsel dat u wilt gebruiken voor de machinenamen van de rolinstantie van de robuuste infrastructuur van Azure Stack Hub. Als deze niet is opgegeven, is de standaardwaarde 'azs'.	azs

De FQDN (Fully Qualified Domain Name) van uw robuuste implementatie en eindpunten van Azure Stack Hub is de combinatie van de parameter Region en de parameter External Domain Name. Met behulp van de waarden uit de voorbeelden in de vorige tabel zou de FQDN voor deze robuuste implementatie van Azure Stack Hub zijn: east.cloud.fabrikam.com

Als zodanig zien voorbeelden van sommige 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, interne zakelijke DNS-server 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 die als host fungeren voor de zones fabrikam.com en cloud.fabrikam.com zijn bereikbaar via de robuuste implementatie van Azure Stack Hub.

Als u DNS-namen voor robuuste eindpunten en exemplaren van Azure Stack Hub ruggedized wilt omzetten, moet u de DNS-servers integreren. Inclusief servers die als host fungeren voor de externe DNS-zone voor Azure Stack Hub ruggedized, 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 worden gehost in Azure Stack Hub ruggedized op naam. Het DNS-naamlabel gebruikt 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 voor myapp gemaakt in de zone east.cloudapp.cloud.fabrikam.com op de robuuste externe DNS-server van Azure Stack Hub. De resulterende Fully Qualified Domain Name 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 ruggedized en de DNS-servers die als host fungeren voor de bovenliggende zone die u wilt gebruiken. Deze naamruimte is anders dan de naamruimte die wordt gebruikt voor de robuuste service-eindpunten van Azure Stack Hub. Daarom moet u een extra regel voor delegering of voorwaardelijk doorsturen maken.

Zie 'Dns gebruiken' in Azure Stack Hub ruggedized voor meer informatie over de werking van het label DNS-naam.

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 bevat 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 ruggedized omzetten

Als u DNS-namen wilt omzetten voor eindpunten buiten Azure Stack Hub ruggedized (bijvoorbeeld : www.bing.com), moet u DNS-servers opgeven voor Azure Stack Hub ruggedized om DNS-aanvragen door te sturen, waarvoor Azure Stack Hub ruggedized niet gezaghebbend is. DNS-servers waarnaar Azure Stack Hub ruggedized aanvragen doorstuurt, 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 dns-doorstuurserverwaarden bewerken met de cmdlet Set-AzSDnsForwarder na de implementatie.

Overzicht van firewallontwerp

Het is raadzaam om een firewallapparaat te gebruiken om Azure Stack Hub ruggedized te beveiligen. Firewalls kunnen helpen beschermen tegen zaken als 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 een niet-verbonden implementatiemodus wordt gebruikt, moet u het AD FS-eindpunt publiceren. Zie het artikel over identiteiten voor datacentrumintegratie voor meer informatie.

Voor de eindpunten azure Resource Manager (beheerder), beheerdersportal en Key Vault (beheerder) is niet noodzakelijkerwijs externe publicatie vereist. Als serviceprovider kunt u bijvoorbeeld de kwetsbaarheid voor aanvallen beperken door Azure Stack Hub ruggedized alleen te beheren vanuit uw netwerk en niet vanaf internet.

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

Netwerkadresomzetting

Nat (Network Address Translation) 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 privileged endpoint (PEP) tijdens registratie en probleemoplossing.

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

Enkele van de nadelen van het gebruik van NAT voor openbaar 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 publiceren en de poortlijst bij te werken.
• Hoewel NAT-gebruik de gebruikerservaring beperkt, geeft het de operator volledige controle over publicatieaanvragen.
• Voor hybride cloudscenario's met Azure biedt Azure geen ondersteuning voor het instellen van een VPN-tunnel naar een eindpunt met behulp van NAT.

SSL-interceptie

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

Firewallscenario voor edge-implementatie

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

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

Bedrijfsintranet- of perimeternetwerkfirewallscenario

In een bedrijfsintranet of perimeterimplementatie wordt Azure Stack Hub ruggedized 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 internettoegang 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-groep van het externe netwerk.
• Perimeterzone. Het perimeternetwerk is waar meestal externe of internetgerichte apps, zoals webservers, worden geïmplementeerd. Het wordt normaal gesproken bewaakt door een firewall om aanvallen zoals DDoS en inbraak (hacking) te voorkomen, terwijl opgegeven binnenkomend verkeer van internet nog steeds wordt toegestaan. Alleen de openbare VIP-pool van het externe netwerk van Azure Stack Hub ruggedized mag zich in de DMZ-zone bevinden.
• Onbeveiligde zone. Het externe netwerk, internet. Het implementeren van Azure Stack Hub Ruggedized in de onbeveiligde zone wordt niet aanbevolen.

Overzicht van VPN-ontwerp

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

Voordat u netwerkverkeer kunt verzenden tussen uw virtuele Azure-netwerk en uw on-premises site, 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 ruggedized en een virtueel netwerk in Azure. U kunt ook verkeer veilig 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, raadpleegt u de overwegingen voor robuuste netwerken in Azure Stack Hub. U leert hoe configuraties voor Azure Stack Hub ruggedized 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 ruggedized wordt de bandbreedtewaarde voor de VPN-gateway-SKU echter toegepast op elke verbindingsresource die is verbonden met de gateway. Bijvoorbeeld:

• In Azure kan de eenvoudige VPN-gateway-SKU ongeveer 100 Mbps aan geaggregeerde doorvoer aan. 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 ruggedized krijgt elke verbinding met de eenvoudige 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.

Belangrijk

Momenteel ondersteunt Azure Stack Hub ruggedized alleen het op route gebaseerde VPN-type. Als uw apparaat alleen op beleid gebaseerde VPN's ondersteunt, worden verbindingen met deze apparaten vanuit Azure Stack Hub ruggedized niet ondersteund. Bovendien biedt Azure Stack Hub ruggedized op dit moment geen ondersteuning voor het gebruik van op beleid gebaseerde verkeersselectors voor op route gebaseerde gateways, omdat aangepaste IPSec-/IKE-beleidsconfiguraties niet worden ondersteund.

• BeleidGebaseerd: op beleid gebaseerde VPN's versleutelen en sturen 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 verkeersselector, is meestal een toegangslijst in de configuratie van het VPN-apparaat. PolicyBased wordt ondersteund in Azure, maar niet in Azure Stack Hub Ruggedized.
• RouteBased: op route gebaseerde VPN's maken gebruik van routes die zijn geconfigureerd in de doorsturen of routeringstabel via IP. De stuurt pakketten door naar de bijbehorende tunnelinterfaces. De tunnelinterfaces versleutelen of ontsleutelen de pakketten vervolgens naar en vanuit de tunnels. Het beleid, of de verkeersselector, voor RouteBased VPN's wordt geconfigureerd als any-to-any (of gebruikt jokertekens). Standaard kunnen ze niet worden gewijzigd. De waarde voor een vpn-type op basis van Route 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 tot stand brengen van een 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 bij uw behoeften past. In de volgende secties kunt u informatie en topologiediagrammen weergeven over de volgende VPN-gatewayverbindingen:

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

De diagrammen en beschrijvingen in de volgende secties kunnen u helpen bij het selecteren van een verbindingstopologie die aan uw vereisten voldoet. De diagrammen tonen de belangrijkste basislijntopologieën, 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 IPsec/IKE (IKEv2) VPN-tunnel. 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 maakt voor Azure Stack Hub ruggedized, geeft u de gateway-SKU op die u wilt gebruiken. De volgende VPN-gateway-SKU's worden ondersteund:

• Basic
• Standard
• Hoge prestaties

Als u een hogere gateway-SKU selecteert, worden er meer CPU's en netwerkbandbreedte aan de gateway toegewezen. Als gevolg hiervan 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 op de Basic-SKU.
• Naast elkaar bestaande expressRoute-VPN-gatewayconfiguraties worden niet ondersteund in Azure Stack Hub ruggedized.

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 actief/passieve configuraties, ondersteunt Azure Stack Hub ruggedized alleen de actieve/passieve configuratie.

Failover

Azure Stack Hub ruggedized bevat drie VM's voor gatewayinfrastructuur met meerdere tenants. 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, wordt er na een korte periode (enkele seconden) een failover van de VPN-verbinding naar de redundante VM uitgevoerd.

Geschatte geaggregeerde doorvoer per SKU

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

	Doorvoer VPN-gateway (1)	Max. IPsec-tunnels VPN-gateway (2)
Basic-SKU(3)	100 Mbps	20
Standaard SKU	100 Mbps	20
SKU met hoge prestaties	200 Mbps	10

Tabelnotities

(1) - VPN-doorvoer is geen gegarandeerde doorvoer voor cross-premises verbindingen via internet. Dit is de maximaal mogelijke 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.

Belangrijk

Er kan slechts één site-naar-site-VPN-verbinding worden gemaakt tussen twee robuuste implementaties van Azure Stack Hub. Dit wordt veroorzaakt door een beperking in het platform waardoor slechts één VPN-verbinding met hetzelfde IP-adres is toegestaan. Omdat Azure Stack Hub ruggedized gebruikmaakt van de multitenant-gateway, die gebruikmaakt van één openbaar IP-adres voor alle VPN-gateways in het robuuste Azure Stack Hub-systeem, kan er slechts één VPN-verbinding zijn tussen twee robuuste Azure Stack Hub-systemen.

Deze beperking geldt ook voor het verbinden van meer dan één site-naar-site-VPN-verbinding met een VPN-gateway die gebruikmaakt van één IP-adres. Met Azure Stack Hub ruggedized kan niet meer dan één lokale netwerkgatewayresource worden gemaakt met hetzelfde IP-adres.**

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 als VPN-gateway fungeert.

In tegenstelling tot Azure, dat ondersteuning biedt voor meerdere aanbiedingen als initiator en responder, ondersteunt Azure Stack Hub ruggedized 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)

Eigenschap	Waarde
IKE-versie	IKEv2
Diffie-Hellman-groep	ECP384
Verificatiemethode	Vooraf gedeelde sleutel
Versleutelings- en hash-algoritmen	AES256, SHA384
SA-levensduur (tijd)	28.800 seconden

Parameters voor IKE Phase 2 (Quick Mode)

Eigenschap	Waarde
IKE-versie	IKEv2
Versleuteling & Hashing-algoritmen (versleuteling)	GCMAES256
Versleutelings-& Hashing-algoritmen (verificatie)	GCMAES256
SA-levensduur (tijd)	27.000 seconden
SA-levensduur (kilobytes)	33,553,408
Perfect Forward Secrecy (PFS)	ECP384
Dead Peer Detection	Ondersteund

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 Ruggedized om te voldoen aan 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 gebaseerd).
• U kunt maar één beleidscombinatie opgeven voor een bepaalde verbinding.
• U moet alle algoritmen en parameters opgeven voor zowel IKE (hoofdmodus) 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 wordt de werkstroom beschreven die nodig is voor het maken en bijwerken van het IPsec-/IKE-beleid voor een site-naar-site-VPN-verbinding:

1. Maak een virtueel netwerk en een VPN-gateway.
2. Maak een lokale netwerkgateway voor cross-premises verbinding.
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 de belangrijkste sterke punten die kunnen worden geconfigureerd door klanten van Azure Stack Hub ruggedized:

IPsec/IKEv2	Opties
IKEv2-versleuteling	AES256, AES192, AES128, DES3, DES
IKEv2-integriteit	SHA384, SHA256, SHA1, MD5
DH-groep	ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, Geen
IPsec-versleuteling	GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, geen
IPsec-integriteit	GCMASE256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
PFS-groep	PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, geen
QM SA-levensduur	(Optioneel: standaardwaarden worden gebruikt als deze niet zijn opgegeven)
	Seconden (geheel getal; min. 300/standaard 27.000 seconden)
	KBytes (geheel getal; min. 1024/standaard 102.400.000 kBytes)
Verkeersselector	Op beleid gebaseerde verkeersselectors worden niet ondersteund in Azure Stack Hub Ruggedized.

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 is alleen lokale specificaties, ze hoeven niet overeen te komen.

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

In de voorgaande tabel:

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

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

Diffie-Hellman-groep	DHGroup	PFSGroup	Sleutellengte
1	DHGroup1	PFS1	768-bits MODP
2	DHGroup2	PFS2	1024-bits MODP
14	DHGroup14	PFS2048	2048-bits MODP
	DHGroup2048
19	ECP256	ECP256	256-bits ECP
20	ECP384	ECP384	384-bits ECP
24	DHGroup24	PFS24	2048-bits MODP

Azure Stack Hub ruggedized 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 praktische kennis van Azure.
• U hebt een basiskennis van Azure Stack Hub ruggedized.
• U hebt een basiskennis van netwerken.

Vereisten

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

• 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.
  • het maken van meerdere VRF's (Virtual Routing and Forwarding) als uw robuuste implementatie van Azure Stack Hub meer dan één tenant bevat.
• 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 klaar bent met het instellen van ExpressRoute aan de hand 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: