Introduktion till robust nätverk i Azure Stack Hub

Översikt över nätverksdesign

Design för fysiskt nätverk

Den robusta Azure Stack Hub-lösningen kräver en motståndskraftig och högtillgänglig fysisk infrastruktur som stöder drift och tjänster. Överlänkar från ToR till kantväxlar är begränsade till SFP+ eller SFP28-media och 1 GB, 10 GB eller 25 GB hastigheter. Kontakta oem-maskinvaruleverantören (Original Equipment Manufacturer) för tillgänglighet.

Följande diagram visar vår rekommenderade design för Azure Stack Hub robust.

Design av logiskt nätverk

En logisk nätverksdesign representerar en abstraktion av en fysisk nätverksinfrastruktur. De används för att organisera och förenkla nätverkstilldelningar för värdar, virtuella datorer och tjänster. Som en del av skapandet av logiska nätverk skapas nätverksplatser för att definiera:

• virtuella lokala nätverk (VLAN)
• IP-undernät
• IP-undernät/VLAN-par

Alla är associerade med det logiska nätverket på varje fysisk plats.

Följande tabell visar de logiska nätverk och associerade IPv4-undernätsintervall som du måste planera för:

Logiskt nätverk	Beskrivning	Storlek
Offentlig virtuell IP-adress (VIP)	Azure Stack Hub ruggedized använder totalt 31 adresser från det här nätverket. Åtta offentliga IP-adresser används för en liten uppsättning robusta Azure Stack Hub-tjänster och resten används av virtuella klientdatorer. Om du planerar att använda App Service och SQL resursprovidrar används ytterligare 7 adresser. De återstående 15 IP-adresserna är reserverade för framtida Azure-tjänster.	/26 (62 värdar)- /22 (1 022 värdar) Rekommenderas = /24 (254 värdar)
Växla infrastruktur	Punkt-till-punkt-IP-adresser för routningsändamål, dedikerade switchhanteringsgränssnitt och loopback-adresser som tilldelats växeln.	/26
Infrastruktur	Används för att kommunicera med robusta interna komponenter i Azure Stack Hub.	/24
Privat	Används för lagringsnätverket, privata VIP:er, infrastrukturcontainrar och andra interna funktioner.	/20
Styrenhet för huvudkortshantering (BMC)	Används för att kommunicera med baseboard-hanteringskontrollanterna på de fysiska värdarna.	/26

Nätverksinfrastruktur

Nätverksinfrastrukturen för Azure Stack Hub robust består av flera logiska nätverk som är konfigurerade på växlarna. Följande diagram visar dessa logiska nätverk och hur de integreras med tor-växlar (top-of-rack), baseboard management controller och gränsväxlar (kundnätverk).

Robust diagram över logiskt nätverk i Azure Stack Hub:

BMC-nätverk

Det här nätverket är dedikerat för att ansluta alla baseboard-hanteringsstyrenheter (kallas även BMC eller tjänstprocessorer) till hanteringsnätverket. Exempel är: iDRAC, iLO, iBMC och så vidare. Endast ett BMC-konto används för att kommunicera med någon BMC-nod. Om det finns finns maskinvarulivscykelvärden (HLH) i det här nätverket och kan tillhandahålla OEM-specifik programvara för maskinvaruunderhåll eller övervakning.

HLH är också värd för den virtuella distributionsdatorn (DVM). DVM används under en robust distribution i Azure Stack Hub och tas bort när distributionen är klar. DVM kräver Internetåtkomst i anslutna distributionsscenarier för att testa, validera och komma åt flera komponenter. Dessa komponenter kan finnas i och utanför företagets nätverk (till exempel NTP, DNS och Azure). Mer information om anslutningskrav finns i NAT-avsnittet i Azure Stack Hub ruggedized firewall integration(Nat-avsnitt) i Azure Stack Hub ruggedized firewall integration (Robust brandväggsintegrering).

Privat nätverk

Nätverket /20 (4 096 värd-IP-adresser) är privat för den robusta Azure Stack Hub-regionen. Den expanderar inte utanför gränsväxlingsenheterna i den robusta Azure Stack Hub-regionen. Det här nätverket är indelat i flera undernät, till exempel:

• Storage nätverk: Ett /25-nätverk (128 IP-adresser) som används för användning av SMB-lagringstrafik (Spaces Direct och Server Message Block) och virtuell dators direktmigrering.
• Internt virtuellt IP-nätverk: Ett /25-nätverk som är dedikerat till interna VIP:er för programvarans lastbalanserare.
• Containernätverk: Ett /23-nätverk (512 IP-adresser) som är dedikerat till intern trafik mellan containrar som kör infrastrukturtjänster

Storleken för det privata nätverket är /20 (4 096 IP-adresser) för privat IP-utrymme. Det här nätverket är privat för det robusta Azure Stack Hub-systemet. Den dirigeras inte bortom gränsväxlingsenheterna i det robusta Azure Stack Hub-systemet och kan återanvändas på flera robusta Azure Stack Hub-system. Även om nätverket är privat för Azure Stack Hub får det inte överlappa andra nätverk i datacentret. För vägledning om privat IP-utrymme rekommenderar vi att du följer RFC 1918.

Det privata IP-utrymmet /20 är indelat i flera nätverk, vilket gör att den robusta systeminfrastrukturen i Azure Stack Hub kan köras på containrar i framtida versioner. Mer information finns i viktig information från 1910. Det här nya privata IP-utrymmet gör det möjligt att kontinuerligt minska det dirigerbara IP-utrymmet före distributionen.

Azure Stack Hub robust infrastrukturnätverk

/24-nätverket är dedikerat till interna Azure Stack Hub-robusta komponenter för att kommunicera och utbyta data sinsemellan. Det här undernätet kan dirigeras externt från den robusta Azure Stack Hub-lösningen till ditt datacenter. Vi rekommenderar inte att du använder offentliga eller Internet-dirigerbara IP-adresser i det här undernätet. Det här nätverket annonseras till gränsen, men de flesta av dess IP-adresser skyddas av Access Control listor (ACL:er). Ip-adresserna som tillåts för åtkomst ligger inom ett litet intervall, vilket motsvarar ett /27-nätverk. IP-adresserna är värd för tjänster som den privilegierade slutpunkten (PEP) och robust säkerhetskopiering i Azure Stack Hub.

Offentligt VIP-nätverk

Det offentliga VIP-nätverket tilldelas nätverksstyrenheten i Azure Stack Hub robust. Det är inte ett logiskt nätverk på växeln. SLB använder poolen med adresser och tilldelar /32-nätverk för klientarbetsbelastningar. I växelroutningstabellen annonseras dessa /32 IP-adresser som en tillgänglig väg via Border Gateway Protocol (BGP). Det här nätverket innehåller offentliga adresser som är externt tillgängliga. Den robusta Infrastrukturen i Azure Stack Hub reserverar de första 31 adresserna från det offentliga VIP-nätverket, medan resten används av virtuella klientdatorer. Nätverksstorleken i det här undernätet kan variera från minst /26 (64 värdar) till högst /22 (1 022 värdar). Vi rekommenderar att du planerar för ett /24-nätverk.

Växla infrastrukturnätverk

/26-nätverket är det undernät som innehåller de dirigerbara punkt-till-punkt-IP-undernäten /30 (två värd-IP-adresser) och loopbacks. Dessa är dedikerade /32-undernät för hantering av in-band-växel och BGP-router-ID. Det här ip-adressintervallet måste vara dirigerbart utanför azure Stack Hub-robust lösning till ditt datacenter. IP-adresserna kan vara privata eller offentliga.

Växla hanteringsnätverk

Nätverket /29 (sex värd-IP-adresser) är dedikerat för att ansluta hanteringsportarna för växlarna. Det här nätverket tillåter out-of-band-åtkomst för distribution, hantering och felsökning. Den beräknas från switchinfrastrukturnätverket som nämns ovan.

Översikt över DNS-design

För att få åtkomst till robust slutpunkter i Azure Stack Hub (portal, administrationsportal, hantering, administration) utanför Azure Stack Hub, måste du integrera Azure Stack Hub-robust DNS-tjänsterna med DE DNS-servrar som är värdar för de DNS-zoner som du vill använda i Azure Stack Hub.

Azure Stack Hub robust DNS-namnområde

Du måste ange viktig information om DNS när du distribuerar Azure Stack Hub ruggedized.

Fält	Beskrivning	Exempel
Region	Den geografiska platsen för din robusta Azure Stack Hub-distribution.	östra
Externt domännamn	Namnet på den zon som du vill använda för din robusta Azure Stack Hub-distribution.	cloud.fabrikam.com
Internt domännamn	Namnet på den interna zonen som används för infrastrukturtjänster i Azure Stack Hub ruggedized. Det är Katalogtjänstintegrerad och privat (kan inte nås utanför azure Stack Hub-robust distribution).	azurestack.local
DNS-vidarebefordrare	DNS-servrar som används för att vidarebefordra DNS-frågor, DNS-zoner och poster som finns utanför Azure Stack Hub ruggedized, antingen på företagets intranät eller offentligt Internet. Du kan redigera dns-vidarebefordrarens värde med cmdleten Set-AzSDnsForwarder efter distributionen.
Namngivningsprefix (valfritt)	Det namngivningsprefix som du vill att datornamnen för din Azure Stack Hub-robusta infrastrukturrollinstans ska ha. Om det inte anges är standardvärdet "azs".	azs

Det fullständigt kvalificerade domännamnet (FQDN) för din robusta distribution och slutpunkter i Azure Stack Hub är kombinationen av parametern Region och parametern Externt domännamn. Med hjälp av värdena från exemplen i föregående tabell skulle FQDN för den här robusta Azure Stack Hub-distributionen vara: east.cloud.fabrikam.com

Därför skulle exempel på några av slutpunkterna för den här distributionen se ut som följande URL:er:

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

Om du vill använda det här dns-exempelnamnområdet för en robust distribution i Azure Stack Hub krävs följande villkor:

• Zonen fabrikam.com är registrerad hos en domänregistrator, en intern DNS-server för företaget eller båda. Registreringen beror på namnmatchningskraven.
• Den underordnade domänen cloud.fabrikam.com finns under zonen fabrikam.com.
• De DNS-servrar som är värdar för zonerna fabrikam.com och cloud.fabrikam.com kan nås från den robusta Azure Stack Hub-distributionen.

För att matcha DNS-namn för Azure Stack Hub-robusta slutpunkter och instanser utanför Azure Stack Hub ruggedized måste du integrera DNS-servrarna. Inklusive servrar som är värdar för den externa DNS-zonen för Azure Stack Hub ruggedized, med DE DNS-servrar som är värdar för den överordnade zonen som du vill använda.

DNS-namnetiketter

Azure Stack Hub ruggedized har stöd för att lägga till en DNS-namnetikett till en offentlig IP-adress för att tillåta namnmatchning för offentliga IP-adresser. DNS-etiketter är ett bekvämt sätt för användare att nå appar och tjänster som hanteras i Azure Stack Hub ruggedized efter namn. DNS-namnetiketten använder ett något annorlunda namnområde än infrastrukturslutpunkterna. Efter föregående exempelnamnområde skulle namnområdet för DNS-namnetiketter vara: *.east.cloudapp.cloud.fabrikam.com.

Om en klientorganisation anger Myapp i FÄLTET DNS-namn för en offentlig IP-adressresurs skapas en A-post för myapp i zonen east.cloudapp.cloud.fabrikam.com på den robusta externa DNS-servern i Azure Stack Hub. Det resulterande fullständigt kvalificerade domännamnet skulle vara: myapp.east.cloudapp.cloud.fabrikam.com.

Om du vill använda den här funktionen och använda det här namnområdet måste du integrera DNS-servrarna. Inklusive servrar som är värdar för den externa DNS-zonen för Azure Stack Hub ruggedized och DE DNS-servrar som är värdar för den överordnade zonen som du också vill använda. Det här namnområdet skiljer sig från det som används för azure stack hub ruggedized-tjänstslutpunkter, så du måste skapa ytterligare en delegerings- eller villkorlig vidarebefordran-regel.

Mer information om hur DNS-namnetiketten fungerar finns i "Använda DNS" i Azure Stack Hub ruggedized.

Matchning och delegering

Det finns två typer av DNS-servrar:

• En auktoritativ DNS-server är värd för DNS-zoner. Den svarar på DNS-frågor om poster i just dessa zoner.
• En rekursiv DNS-server är inte värd för DNS-zoner. Den svarar på alla DNS-frågor genom att anropa auktoritativa DNS-servrar för att samla in de data som den behöver.

Azure Stack Hub ruggedized innehåller både auktoritativa och rekursiva DNS-servrar. De rekursiva servrarna används för att matcha namn på allt utom den interna privata zonen och den externa offentliga DNS-zonen för den robusta Azure Stack Hub-distributionen.

Lösa externa DNS-namn från Azure Stack Hub ruggedized

För att matcha DNS-namn för slutpunkter utanför Azure Stack Hub ruggedized (till exempel : www.bing.com) måste du ange DNS-servrar för Azure Stack Hub ruggedized för att vidarebefordra DNS-begäranden, för vilka Azure Stack Hub ruggedized inte är auktoritativt. DNS-servrar som Azure Stack Hub robust vidarebefordrar begäranden till krävs i kalkylbladet Distribution (i fältet DNS-vidarebefordrare). Ange minst två servrar i det här fältet för feltolerans. Utan dessa värden misslyckas azure stack hub ruggedized-distributionen. Du kan redigera DNS-vidarebefordrarens värden med cmdleten Set-AzSDnsForwarder efter distributionen.

Översikt över brandväggsdesign

Vi rekommenderar att du använder en brandväggsenhet för att skydda Azure Stack Hub ruggedized. Brandväggar kan hjälpa till att skydda mot sådant som DDOS-attacker (distribuerade överbelastningsattacker), intrångsidentifiering och innehållsgranskning. De kan dock också bli en flaskhals i dataflödet för Azure-lagringstjänster som blobar, tabeller och köer.

Om ett frånkopplat distributionsläge används måste du publicera AD FS-slutpunkten. Mer information finns i artikeln om datacenterintegreringsidentitet.

Slutpunkter för Azure Resource Manager (administratör), administratörsportal och Key Vault (administratör) kräver inte nödvändigtvis extern publicering. Som tjänstleverantör kan du till exempel begränsa attackytan genom att endast administrera Azure Stack Hub ruggedized inifrån nätverket och inte från Internet.

För företagsorganisationer kan det externa nätverket vara det befintliga företagsnätverket. I det här scenariot måste du publicera slutpunkter för att köra Azure Stack Hub ruggedized från företagsnätverket.

Översättning av nätverksadress

NAT (Network Address Translation) är den rekommenderade metoden för att ge den virtuella distributionsdatorn (DVM) åtkomst till externa resurser under distributionen. Även för nödåterställningskonsolen (ERCS) virtuella datorer eller privilegierad slutpunkt (PEP) under registrering och felsökning.

NAT kan också vara ett alternativ till offentliga IP-adresser i det externa nätverket eller offentliga VIP-adresser. Det rekommenderas dock inte att göra det eftersom det begränsar klientorganisationens användarupplevelse och ökar komplexiteten. Ett alternativ skulle vara en till en NAT som fortfarande kräver en offentlig IP-adress per användares IP-adress i poolen. Ett annat alternativ är många-till-en-NAT som kräver en NAT-regel per användar-VIP för alla portar som en användare kan använda.

Några av nackdelarna med att använda NAT för offentlig VIP är:

• Omkostnader vid hantering av brandväggsregler, eftersom användare styr sina egna slutpunkter och publiceringsregler i den programvarudefinierade nätverksstacken (SDN). Användarna måste kontakta operatorn Azure Stack Hub ruggedized för att få sina VIP-adresser publicerade och för att uppdatera portlistan.
• Även om NAT-användningen begränsar användarupplevelsen ger den fullständig kontroll till operatören över publiceringsbegäranden.
• För hybridmolnscenarier med Azure bör du tänka på att Azure inte stöder konfiguration av en VPN-tunnel till en slutpunkt med NAT.

SSL-avlyssning

Vi rekommenderar för närvarande att inaktivera all SSL-avlyssning (till exempel dekrypteringsavlastning) på all Azure Stack Hub-robust trafik. Om det stöds i framtida uppdateringar ges vägledning om hur du aktiverar SSL-avlyssning för Azure Stack Hub ruggedized.

Scenario för Edge-distributionens brandvägg

I en edge-distribution distribueras Azure Stack Hub ruggedized direkt bakom gränsroutern eller brandväggen. I dessa scenarier stöds det att brandväggen är ovanför kantlinjen (scenario 1) där den stöder både aktiv-aktiv och aktiv-passiv brandväggskonfiguration. Den kan också fungera som kantlinjeenhet (scenario 2), där den endast stöder brandväggskonfiguration med aktiv-aktiv. Scenario 2 är beroende av ecmp (equal-cost multi-path) med antingen BGP eller statisk routning för redundans.

Offentliga dirigerbara IP-adresser anges för den offentliga VIP-poolen från det externa nätverket vid distributionstillfället. Av säkerhetsskäl rekommenderas inte offentliga routningsbara IP-adresser i något annat nätverk i ett gränsscenario. Det här scenariot gör det möjligt för en användare att uppleva den fullständiga självkontrollerade molnupplevelsen som i ett offentligt moln som Azure.

Scenario för företagsintranät eller perimeternätverksbrandvägg

I en företagsintranäts- eller perimeterdistribution distribueras Azure Stack Hub ruggedized i en brandvägg med flera zoner eller mellan gränsbrandväggen och den interna brandväggen för företagsnätverket. Trafiken distribueras sedan mellan det säkra perimeternätverket (eller DMZ) och oskyddade zoner enligt beskrivningen nedan:

• Säker zon: Det interna nätverk som använder interna eller företagsrouterbara IP-adresser. Det säkra nätverket kan delas upp. Den kan ha utgående internetåtkomst via brandväggens NAT. Den är normalt tillgänglig inifrån ditt datacenter via det interna nätverket. Alla Robustiserade Azure Stack Hub-nätverk bör finnas i den säkra zonen, förutom det externa nätverkets offentliga VIP-pool.
• Perimeterzon. Perimeternätverket är där externa eller Internetuppkopplade appar som webbservrar vanligtvis distribueras. Den övervakas normalt av en brandvägg för att undvika attacker som DDoS och intrång (hackning) samtidigt som angiven inkommande trafik från Internet tillåts. Endast det externa nätverkets offentliga VIP-pool för Azure Stack Hub ruggedized ska finnas i DMZ-zonen.
• Oskyddad zon. Det externa nätverket, Internet. Distribution av Azure Stack Hub ruggedized i den osäkra zonen rekommenderas inte .

Översikt över VPN-design

Även om VPN är ett användarkoncept finns det några viktiga överväganden som en lösningsägare och operatör behöver känna till.

Innan du kan skicka nätverkstrafik mellan ditt virtuella Azure-nätverk och din lokala plats måste du skapa en virtuell nätverksgateway (VPN) för ditt virtuella nätverk.

En VPN-gateway är en typ av virtuell nätverksgateway som skickar krypterad trafik över en offentlig anslutning. Du kan använda VPN-gatewayer för att skicka trafik säkert mellan ett virtuellt nätverk i Azure Stack Hub ruggedized och ett virtuellt nätverk i Azure. Du kan också skicka trafik på ett säkert sätt mellan ett virtuellt nätverk och ett annat nätverk som är anslutet till en VPN-enhet.

När du skapar en virtuell nätverksgateway anger du vilken typ av gateway som du vill skapa. Azure Stack Hub ruggedized stöder en typ av virtuell nätverksgateway: vpn-typen .

Varje virtuellt nätverk kan ha två virtuella nätverksgatewayer, men bara en av varje typ. Du kan skapa flera anslutningar till en enda VPN-gateway beroende på de inställningar som du väljer. Ett exempel på den här typen av konfiguration är en anslutningskonfiguration för flera platser.

Innan du skapar och konfigurerar VPN-gatewayer för Azure Stack Hub ruggedized granskar du övervägandena för robust nätverk i Azure Stack Hub. Du lär dig hur konfigurationer för Azure Stack Hub ruggedized skiljer sig från Azure.

I Azure måste bandbreddsdataflödet för den VPN-gateway-SKU som du väljer delas upp mellan alla anslutningar som är anslutna till gatewayen. I Azure Stack Hub är dock bandbreddsvärdet för VPN-gateway-SKU:n tillämpat på varje anslutningsresurs som är ansluten till gatewayen. Ett exempel:

• I Azure kan den grundläggande VPN-gateway-SKU:n hantera cirka 100 Mbit/s aggregerat dataflöde. Om du skapar två anslutningar till vpn-gatewayen och en anslutning använder 50 Mbit/s bandbredd är 50 Mbit/s tillgängligt för den andra anslutningen.
• I Azure Stack Hub ruggedized allokeras varje anslutning till den grundläggande VPN-gateway-SKU:n 100 Mbit/s dataflöde.

VPN-typer

När du skapar den virtuella nätverksgatewayen för en VPN-gatewaykonfiguration måste du ange en VPN-typ. Vilken VPN-typ du väljer beror på vilken anslutningstopologi du vill skapa. En VPN-typ kan också bero på vilken maskinvara du använder. S2S-konfigurationer kräver en VPN-enhet. Vissa VPN-enheter stöder bara en viss VPN-typ.

Viktigt

För närvarande stöder Azure Stack Hub ruggedized endast den routningsbaserade VPN-typen. Om enheten bara stöder principbaserade VPN:er stöds inte anslutningar till dessa enheter från Azure Stack Hub ruggedized. Dessutom har Azure Stack Hub ruggedized inte stöd för att använda principbaserade trafikväljare för routningsbaserade gatewayer just nu, eftersom anpassade IPSec-/IKE-principkonfigurationer inte stöds.

• PolicyBased: Principbaserade VPN krypterar och dirigerar paket via IPsec-tunnlar, baserat på IPsec-principer. Principer konfigureras med kombinationerna av adressprefix mellan ditt lokala nätverk och det robusta virtuella nätverket i Azure Stack Hub. Principen, eller trafikväljaren, är vanligtvis en åtkomstlista i VPN-enhetskonfigurationen. PolicyBased stöds i Azure, men inte i Azure Stack Hub ruggedized.
• RouteBased: Routningsbaserade VPN:er använder vägar som har konfigurerats i IP-vidarebefordrings- eller routningstabellen. Dirigerar paket till motsvarande tunnelgränssnitt. Tunnelgränssnitten krypterar eller dekrypterar sedan paketen in och ut från tunnlarna. Principen, eller trafikväljaren, för Routningsbaserade VPN:er konfigureras som alla-till-alla (eller använder jokertecken). Som standard kan de inte ändras. Värdet för en RouteBased VPN-typ är RouteBased.

Konfigurera en VPN-gateway

En VPN-gatewayanslutning förlitar sig på flera resurser som har konfigurerats med specifika inställningar. De flesta av dessa resurser kan konfigureras separat, men i vissa fall måste de konfigureras i en viss ordning.

Inställningar

De inställningar som du väljer för varje resurs är viktiga för att skapa en lyckad anslutning.

Den här artikeln hjälper dig att förstå:

• Gatewaytyper, VPN-typer och anslutningstyper.
• Gateway-undernät, lokala nätverksgatewayer och andra resursinställningar som du kanske vill överväga.

Diagram för anslutningstopologi

Det finns olika konfigurationer för VPN-gatewayanslutningar. Fastställ vilken konfiguration som bäst passar dina behov. I följande avsnitt kan du visa information och topologidiagram om följande VPN-gatewayanslutningar:

• tillgänglig distributionsmodell
• tillgängliga konfigurationsverktyg
• länkar som tar dig direkt till en artikel om en sådan finns

Diagrammen och beskrivningarna i följande avsnitt kan hjälpa dig att välja en anslutningstopologi som matchar dina krav. Diagrammen visar de viktigaste baslinjetopologierna, men det går att skapa mer komplexa konfigurationer med hjälp av diagrammen som en guide.

Plats-till-plats och flera platser (IPsec/IKE VPN-tunnel)

Plats-till-plats

En VPN-gatewayanslutning från plats till plats (S2S) är en anslutning via IPsec/IKE(IKEv2) VPN-tunnel. Den här typen av anslutning kräver en VPN-enhet som finns lokalt och tilldelas en offentlig IP-adress. Den här enheten kan inte finnas bakom en NAT. S2S-anslutningar kan användas för konfigurationer mellan platser och för hybridkonfigurationer.

Flera platser

En anslutning med flera platser är en variant av plats-till-plats-anslutningen. Du skapar fler än en VPN-anslutning från din virtuella nätverksgateway, vanligtvis sker anslutningen till flera lokala platser. När du arbetar med flera anslutningar måste du använda en routningsbaserad VPN-typ (kallas dynamisk gateway när du arbetar med klassiska virtuella nätverk). Eftersom varje virtuellt nätverk bara kan ha en VPN-gateway delar alla anslutningar via gatewayen på den tillgängliga bandbredden.

Gateway-SKU:er

När du skapar en virtuell nätverksgateway för Azure Stack Hub ruggedized anger du den gateway-SKU som du vill använda. Följande SKU:er för VPN-gateway stöds:

• Basic
• Standard
• Höga prestanda

Om du väljer en högre gateway-SKU allokeras fler processorer och nätverksbandbredd till gatewayen. Därför kan gatewayen ha stöd för högre nätverksdataflöde till det virtuella nätverket.

Azure Stack Hub ruggedized har inte stöd för Ultra Performance-gateway-SKU:n, som används uteslutande med Express Route.

Tänk på följande när du väljer SKU:n:

• Azure Stack Hub ruggedized stöder inte principbaserade gatewayer.
• BGP stöds inte på Basic-SKU:n.
• ExpressRoute-VPN-gatewayens samexisterande konfigurationer stöds inte i Azure Stack Hub ruggedized.

Gateway-tillgänglighet

Scenarier med hög tillgänglighet kan bara konfigureras på SKU:n för gatewayanslutningar med höga prestanda . Till skillnad från Azure, som ger tillgänglighet via både aktiva/aktiva och aktiva/passiva konfigurationer, stöder Azure Stack Hub ruggedized endast den aktiva/passiva konfigurationen.

Redundans

Det finns tre virtuella datorer för gatewayinfrastruktur för flera klientorganisationer i Azure Stack Hub ruggedized. Två av dessa virtuella datorer är i aktivt läge och den tredje är i redundant läge. Aktiva virtuella datorer gör det möjligt att skapa VPN-anslutningar på dem, och den redundanta virtuella datorn accepterar bara VPN-anslutningar om en redundansväxling sker. Om en aktiv virtuell gateway-dator blir otillgänglig redundansväxlar VPN-anslutningen till den redundanta virtuella datorn efter en kort period (några sekunder) av anslutningsförlust.

Beräknat aggregerat dataflöde av SKU

I följande tabell visas gatewaytyperna och det beräknade aggregerade dataflödet per gateway-SKU:

	VPN Gateway-genomflöde (1)	VPN Gateway, max. IPsec-tunnlar (2)
Basic SKU(3)	100 Mbit/s	20
Standard-SKU	100 Mbit/s	20
Högpresterande SKU	200 Mbit/s	10

Tabellanteckningar

(1) – VPN-dataflöde är inte ett garanterat dataflöde för anslutningar mellan platser över Internet. Det är det högsta möjliga dataflödesmåttet.
(2) – Maximalt antal tunnlar är summan per robust distribution i Azure Stack Hub för alla prenumerationer.
(3) – BGP-routning stöds inte för Basic SKU.

Viktigt

Endast en PLATS-till-plats-VPN-anslutning kan skapas mellan två robust distributioner i Azure Stack Hub. Detta beror på en begränsning i plattformen som endast tillåter en enda VPN-anslutning till samma IP-adress. Eftersom Robust Azure Stack Hub utnyttjar gatewayen för flera innehavare, som använder en enda offentlig IP-adress för alla VPN-gatewayer i det robusta Azure Stack Hub-systemet, kan det bara finnas en VPN-anslutning mellan två robust Azure Stack Hub-system.

Den här begränsningen gäller även för att ansluta mer än en plats-till-plats-VPN-anslutning till alla VPN-gatewayer som använder en enda IP-adress. Azure Stack Hub ruggedized tillåter inte att fler än en lokal nätverksgatewayresurs skapas med samma IP-adress.**

IPsec-/IKE-parametrar

När du konfigurerar en VPN-anslutning i Azure Stack Hub robust måste du konfigurera anslutningen i båda ändar. Om du konfigurerar en VPN-anslutning mellan En robust Azure Stack Hub och en maskinvaruenhet kan den enheten be dig om ytterligare inställningar. Till exempel en växel eller router som fungerar som en VPN-gateway.

Till skillnad från Azure, som stöder flera erbjudanden som både initierare och svarare, stöder Azure Stack Hub robust endast ett erbjudande som standard. Om du behöver använda olika IPSec/IKE-inställningar för att arbeta med VPN-enheten finns det fler inställningar för att konfigurera anslutningen manuellt.

Parametrar för IKE fas 1 (huvudläge)

Egenskap	Värde
IKE-version	IKEv2
Diffie-Hellman Group	ECP384
Autentiseringsmetod	I förväg delad nyckel
Krypteringshashalgoritmer &	AES256, SHA384
SA-livstid (tid)	28 800 sekunder

Parametrar för IKE fas 2 (snabbläge)

Egenskap	Värde
IKE-version	IKEv2
Krypteringshashalgoritmer & (kryptering)	GCMAES256
Krypteringshashalgoritmer & (autentisering)	GCMAES256
SA-livstid (tid)	27 000 sekunder
SA-livslängd (kilobyte)	33,553,408
PFS (Perfect Forward Secrecy)	ECP384
Utebliven peer-identifiering	Stöds

Konfigurera anpassade IPSec/IKE-anslutningsprinciper

IPsec- och IKE-protokollstandarden stöder en mängd olika kryptografiska algoritmer i olika kombinationer. Information om vilka parametrar som stöds i Azure Stack Hub för att uppfylla efterlevnads- eller säkerhetskrav finns i IPsec/IKE-parametrar.

Den här artikeln innehåller instruktioner om hur du skapar och konfigurerar en IPsec/IKE-princip och tillämpar på en ny eller befintlig anslutning.

Överväganden

Observera följande viktiga överväganden när du använder dessa principer:

• IPsec/IKE-principen fungerar bara på SKU :er för Standard- och HighPerformance-gatewayen (routningsbaserad).
• Du kan bara ange en principkombination för en viss anslutning.
• Du måste ange alla algoritmer och parametrar för både IKE (huvudläge) och IPsec (snabbläge). Partiell principspecifikation tillåts inte.
• Kontakta vpn-enhetens leverantörsspecifikationer för att säkerställa att principen stöds på dina lokala VPN-enheter. Plats-till-plats-anslutningar kan inte upprättas om principerna är inkompatibla.

Arbetsflöde för att skapa och ange IPsec/IKE-princip

Det här avsnittet beskriver arbetsflödet som krävs för att skapa och uppdatera IPsec/IKE-principen för en VPN-anslutning från plats till plats:

1. Skapa ett virtuellt nätverk och en VPN-gateway.
2. Skapa en lokal nätverksgateway för anslutning mellan platser.
3. Skapa en IPsec/IKE-princip med valda algoritmer och parametrar.
4. Skapa en IPSec-anslutning med IPsec/IKE-principen.
5. Lägg till/uppdatera/ta bort en IPsec/IKE-princip för en befintlig anslutning.

Kryptografiska algoritmer och viktiga styrkor som stöds

I följande tabell visas de kryptografiska algoritmer som stöds och viktiga styrkor som kan konfigureras av Azure Stack Hub-robusta kunder:

IPsec/IKEv2	Alternativ
IKEv2-kryptering	AES256, AES192, AES128, DES3, DES
IKEv2 Integrity	SHA384, SHA256, SHA1, MD5
DH-grupp	ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, None
IPsec-kryptering	GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, None
IPsec Integrity	GCMASE256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
PFS-grupp	PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, None
QM SA-livstid	(Valfritt: standardvärden används om de inte anges)
	Sekunder (heltal; min. 300/standard 27 000 sekunder)
	KByte (heltal; min. 1024/standard 102 400 000 KByte)
Trafikväljare	Principbaserade trafikväljare stöds inte i Azure Stack Hub robust.

Din lokala konfiguration för VPN-enheten måste stämma överens med eller innehålla följande algoritmer och parametrar som du anger på Azure IPsec/IKE-principen:

• IKE-krypteringsalgoritm (huvudläge/fas 1).
• IKE-integritetsalgoritm (huvudläge/fas 1).
• DH-grupp (huvudläge/fas 1).
• IPsec-krypteringsalgoritm (snabbläge/fas 2).
• IPsec-integritetsalgoritm (snabbläge/fas 2).
• PFS-grupp (snabbläge/fas 2).
• SA-livslängden är endast lokala specifikationer, de behöver inte matcha.

Om GCMAES används som för IPsec Encryption-algoritmen måste du välja samma GCMAES-algoritm och nyckellängd för IPsec-integritet. Till exempel: använda GCMAES128 för båda.

I föregående tabell:

• IKEv2 motsvarar huvudläget eller fas 1.
• IPsec motsvarar snabbläge eller fas 2.
• DH-gruppen anger den Diffie-Hellmen grupp som används i huvudläge eller fas 1.
• PFS-gruppen anger den Diffie-Hellmen grupp som används i snabbläge eller fas 2.
• Sa-livslängden för IKEv2-huvudläget är fast i 28 800 sekunder på Azure Stack Hub-robusta VPN-gatewayer.

I följande tabell visas motsvarande Diffie-Hellman grupper som stöds av den anpassade principen:

Diffie-Hellman-grupp	DHGroup	PFSGroup	Nyckellängd
1	DHGroup1	PFS1	768-bitars MODP
2	DHGroup2	PFS2	1024-bitars MODP
14	DHGroup14	PFS2048	2048-bitars MODP
	DHGroup2048
19	ECP256	ECP256	256-bitars ECP
20	ECP384	ECP384	384-bitars ECP
24	DHGroup24	PFS24	2048-bitars MODP

Anslut Azure Stack Hub robust till Azure med Hjälp av Azure ExpressRoute

Översikt, antaganden och förutsättningar

Med Azure ExpressRoute kan du utöka dina lokala nätverk till Microsoft-molnet. Du använder en privat anslutning som tillhandahålls av en anslutningsleverantör. ExpressRoute är inte en VPN-anslutning via det offentliga Internet.

Mer information om Azure ExpressRoute finns i Översikt över ExpressRoute.

Antaganden

Den här artikeln förutsätter att:

• Du har arbetskunskaper om Azure.
• Du har grundläggande kunskaper om Azure Stack Hub ruggedized.
• Du har grundläggande kunskaper om nätverk.

Förutsättningar

Om du vill ansluta Azure Stack Hub ruggedized och Azure med ExpressRoute måste du uppfylla följande krav:

• En etablerad ExpressRoute-krets via en anslutningsprovider.
• En Azure-prenumeration för att skapa en ExpressRoute-krets och virtuella nätverk i Azure.
• En router som stöder:
  • PLATS-till-plats-VPN-anslutningar mellan lan-gränssnittet och Azure Stack Hub ruggedized multi-tenant gateway.
  • skapa flera VRF:er (virtuell routning och vidarebefordran) om det finns fler än en klientorganisation i din robusta Azure Stack Hub-distribution.
• En router som har:
  • En WAN-port som är ansluten till ExpressRoute-kretsen.
  • En LAN-port som är ansluten till den robusta gatewayen för flera klientorganisationer i Azure Stack Hub.

ExpressRoute-nätverksarkitektur

Följande bild visar Azure Stack Hub-robusta miljöer och Azure-miljöer när du har konfigurerat ExpressRoute med hjälp av exemplen i den här artikeln:

Följande bild visar hur flera klienter ansluter från den robusta Infrastrukturen i Azure Stack Hub via ExpressRoute-routern till Azure: