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 driften och tjänsterna. Ö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 (originalutrustningstillverkaren) för att få tillgång till den.

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 skapande av logiskt 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.

I följande tabell visas 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
BMC (Baseboard Management Controller)	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 kantlinjeväxlar (kundnätverk).

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

BMC-nätverk

Det här nätverket är avsett för att ansluta alla baskortshanteringsstyrenheter (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 en 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 avsnittet NAT i Azure Stack Hub-robust brandväggsintegrering.

Privat nätverk

/20-nätverket (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:

• Lagringsnä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 endast 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. Nätverket är privat till Azure Stack Hub robust, men det får 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 azure stackhubbens robusta lösning till ditt datacenter. Vi rekommenderar inte att du använder offentliga eller Internet-routbara IP-adresser i det här undernätet. Det här nätverket annonseras till kantlinjen, men de flesta av dess IP-adresser skyddas av åtkomstkontrollistor (ACL). 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 Azure Stack Hub ruggedized Backup.

Offentligt VIP-nätverk

Det offentliga VIP-nätverket tilldelas till 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 på 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 IP-undernäten för punkt-till-punkt /30 (två värd-IP-adresser) och loopbacks. Dessa är dedikerade /32-undernät för växelhantering i band 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 växelinfrastrukturnä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änster med DE DNS-servrar som är värdar för de DNS-zoner som du vill använda i Azure Stack Hub robust.

Azure Stack Hub robust DNS-namnområde

Du måste ange viktig information som rör DNS när du distribuerar Azure Stack Hub robust.

Fält	Beskrivning	Exempel
Region	Den geografiska platsen för din robusta Distribution av Azure Stack Hub.	Öst
Externt domännamn	Namnet på den zon som du vill använda för din robust distribution av Azure Stack Hub.	cloud.fabrikam.com
Internt domännamn	Namnet på den interna zonen som används för infrastrukturtjänster i Azure Stack Hub är robust. Det är Katalogtjänstintegrerad och privat (kan inte nås utanför den robusta Distributionen av Azure Stack Hub).	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 är robust, antingen på företagets intranät eller på offentligt Internet. Du kan redigera DNS-vidarebefordrarens värde med cmdleten Set-AzSDnsForwarder efter distributionen.
Namngivningsprefix (valfritt)	Namngivningsprefixet 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 Azure Stack Hub-robust distribution och slutpunkter ä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 det fullständiga domännamnet 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 exemplet dns-namnrymd 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öretag eller båda. Registreringen beror på kraven på namnmatchning.
• 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 Distributionen av Azure Stack Hub.

För att lösa DNS-namn för Azure Stack Hub-robust 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 robust, 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 finns i Azure Stack Hub med ett robust 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 utnyttja 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 robust 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 tjänstslutpunkterna i Azure Stack Hub, så du måste skapa ytterligare en delegerings- eller regel för villkorlig vidarebefordran.

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 Distributionen av Azure Stack Hub.

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

För att lösa DNS-namn för slutpunkter utanför Azure Stack Hub robust (till exempel: www.bing.com) måste du ange DNS-servrar för Azure Stack Hub robust för att vidarebefordra DNS-begäranden, för vilka Azure Stack Hub inte är auktoritativt. DNS-servrar som Azure Stack Hub robust vidarebefordrar begäranden till krävs i distributionsförslaget (i fältet DNS-vidarebefordrare). Ange minst två servrar i det här fältet för feltolerans. Utan dessa värden misslyckas den robusta distributionen av Azure Stack Hub. 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 robust. Brandväggar kan hjälpa till att skydda mot saker som DDOS-attacker (distribuerad denial-of-service), 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 som är robust 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 robust från företagsnätverket.

Översättning av nätverksadress

NAT (Network Address Translation) är den rekommenderade metoden för att tillåta att den virtuella distributionsdatorn (DVM) får åtkomst till externa resurser under distributionen. Även för virtuella datorer med nödåterställningskonsolen (ERCS) 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ändar-IP i poolen. Ett annat alternativ är en nat för många till en 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ändarna styr sina egna slutpunkter och publicerar regler i den programvarudefinierade nätverksstacken (SDN). Användarna måste kontakta den robusta Operatorn för Azure Stack Hub 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 operatorn ö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 robust Trafik i Azure Stack Hub. Om det stöds i framtida uppdateringar ges vägledning om hur du aktiverar SSL-avlyssning för Azure Stack Hub robust.

Scenario för edge-distributionsbrandvägg

I en edge-distribution distribueras Azure Stack Hub robust direkt bakom gränsroutern eller brandväggen. I dessa scenarier stöds det för brandväggen att ligga 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 aktiv-aktiv brandväggskonfiguration. Scenario 2 förlitar sig på 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. I säkerhetssyfte rekommenderas inte offentliga routningsbara IP-adresser i något annat nätverk i ett edge-scenario. 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öretagets intranät eller perimeternätverksbrandvägg

I ett företags intranät eller en perimeterdistribution distribueras Azure Stack Hub robust i en brandvägg med flera zoner eller mellan gränsbrandväggen och den interna företagsnätverksbrandväggen. 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 robusta 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 tillåts från Internet. Endast den offentliga VIP-poolen för det externa nätverket i Azure Stack Hub ska finnas i DMZ-zonen.
• Osäker zon. Det externa nätverket, Internet. Distribution av Azure Stack Hub som är robust 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 på ett säkert sätt mellan ett virtuellt nätverk i Azure Stack Hub robust och ett virtuellt nätverk i Azure. Du kan också skicka trafik säkert 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 med flera platser.

Innan du skapar och konfigurerar VPN-gatewayer för Azure Stack Hub robust bör du gå igenom övervägandena för robust nätverk i Azure Stack Hub. Du får lära dig hur konfigurationer för Azure Stack Hub robust 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. Till exempel:

• I Azure kan den grundläggande VPN-gateway-SKU:n rymma 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 med 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 endast en viss VPN-typ.

Viktigt!

För närvarande stöder Azure Stack Hub endast den routningsbaserade VPN-typen. Om enheten endast stöder principbaserade VPN:er stöds inte anslutningar till dessa enheter från Azure Stack Hub ruggedized. Dessutom stöder inte Azure Stack Hub robust användning av 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 kombinationer 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 robust.
• RouteBased: Routningsbaserade VPN använder vägar som är konfigurerade i tabellen IP-vidarebefordran eller routning. 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 valfri (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 tillgängliga för VPN-gatewayanslutningar. Ta reda på vilken konfiguration som passar bäst för dina behov. I följande avsnitt kan du visa informations- 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 huvudtopologierna för baslinjen, 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 (S2S) från plats till plats är en anslutning via IKEv2-vpn-tunneln (IPsec/IKE). 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 för en 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 robust anger du den gateway-SKU som du vill använda. Följande SKU:er för VPN-gateway stöds:

• Grundläggande
• Norm
• 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 stöder inte SKU:n för Ultra Performance Gateway, som endast används med Express Route.

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

• Azure Stack Hub ruggedized stöder inte principbaserade gatewayer.
• BGP stöds inte på Basic SKU.
• 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 gatewayanslutning 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 innehavare i Azure Stack Hub. 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 uppskattade aggregerade dataflödet per gateway-SKU:

	VPN Gateway-genomflöde (1)	VPN Gateway, max. IPsec-tunnlar (2)
Grundläggande 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 maximala möjliga dataflödesmåttet.
(2) – Maxtunnlar är summan per Azure Stack Hub-robust distribution för alla prenumerationer.
(3) – BGP-routning stöds inte för Basic SKU.

Viktigt!

Det går bara att skapa en PLATS-till-plats-VPN-anslutning 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 Azure Stack Hub robust 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 anslutning av mer än en plats-till-plats-VPN-anslutning till en VPN-gateway 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-enhet 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 din VPN-enhet finns det fler inställningar som du kan använda för att konfigurera anslutningen manuellt.

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

Fastighet	Värde
IKE-version	IKEv2
Diffie-Hellman-grupp	ECP384
Autentiseringsmetod	I förväg delad nyckel
Krypterings- och hash-algoritmer	AES256, SHA384
SA-livstid (tid)	28 800 sekunder

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

Fastighet	Värde
IKE-version	IKEv2
Krypterings- och hashalgoritmer (kryptering)	GCMAES256
Krypterings- och hashalgoritmer (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 är robust 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 gäller för en ny eller befintlig anslutning.

Att tänka på

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-enhetsleverantörens specifikationer 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

I det här avsnittet beskrivs arbetsflödet som krävs för att skapa och uppdatera IPsec/IKE-principen på en plats-till-plats-VPN-anslutning:

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 nyckelstyrkor som stöds

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

IPsec/IKEv2	Alternativ
IKEv2-kryptering	AES256, AES192, AES128, DES3, DES
IKEv2-integritet	SHA384, SHA256, SHA1, MD5
DH-grupp	ECP384, ECP256, DHGroup14, DHGroup2048, DHGroup2, DHGroup1, Ingen
IPsec-kryptering	GCMAES256, GCMAES192, GCMAES128, AES256, AES192, AES128, DES3, DES, Ingen
IPsec-integritet	GCMASE256, GCMAES192, GCMAES128, SHA256, SHA1, MD5
PFS-grupp	PFS24, ECP384, ECP256, PFS2048, PFS2, PFS1, Ingen
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äget eller fas 1.
• PFS-gruppen anger den Diffie-Hellmen-grupp som används i snabbläge eller fas 2.
• IKEv2 Main Mode SA-livslängden ä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

Ansluta 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 en fungerande kunskap om Azure.
• Du har en grundläggande förståelse för Azure Stack Hub robust.
• Du har en grundläggande förståelse för 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-robust gateway för flera innehavare.
  • skapa flera VRF:er (virtuell routning och vidarebefordran) om det finns fler än en klientorganisation i din robust distribution av Azure Stack Hub.
• En router som har:
  • En WAN-port som är ansluten till ExpressRoute-kretsen.
  • En LAN-port som är ansluten till Azure Stack Hub robust gateway för flera klientorganisationer.

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: