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:
- Skapa ett virtuellt nätverk och en VPN-gateway.
- Skapa en lokal nätverksgateway för anslutning mellan platser.
- Skapa en IPsec/IKE-princip med valda algoritmer och parametrar.
- Skapa en IPSec-anslutning med IPsec/IKE-principen.
- 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: