Virtual WAN-arkitektur optimerad för avdelningsspecifika krav

Azure Virtual WAN
Azure ExpressRoute
Azure Virtual Network

Ett globalt tillverkningsföretag tillhandahöll den arkitektur som beskrivs i den här artikeln. Företagets avdelningar för driftsteknik och informationsteknik är starkt integrerade och kräver ett enda internt nätverk. Men miljöerna har drastiskt olika säkerhet och prestandakrav. På grund av den känsliga karaktären hos företagets verksamhet måste all trafik vara brandväggsskyddad och en IDPS-lösning (Intrångsidentifiering och skyddssystem) måste finnas på plats. It-avdelningen har mindre krävande säkerhetskrav för nätverket, men den avdelningen vill optimera för prestanda så att användarna får åtkomst till IT-program med låg svarstid.

Beslutsfattare på företaget vände sig till Azure Virtual WAN för att uppfylla globala behov för ett enda nätverk med varierande säkerhet och prestandakrav. De har också en lösning som är enkel att hantera, distribuera och skala. När de lägger till regioner kan de fortsätta att växa sömlöst med ett nätverk som är mycket optimerat för deras behov.

Potentiella användningsfall

Vanliga användningsfall för den här arkitekturen är:

  • En global organisation som kräver en centraliserad fillösning för affärskritiskt arbete.
  • Högpresterande filarbetsbelastningar som kräver lokaliserade cachelagrade filer.
  • En flexibel distanspersonal för användare både på och från kontoret.

Arkitektur

Diagram som visar en arkitektur som är optimerad för säkerhet eller prestanda, beroende på avdelning.

Ladda ned en Visio-fil med den här arkitekturen.

Här är en sammanfattning av arkitekturen:

  • Användare får åtkomst till virtuella nätverk från en gren.
  • Azure ExpressRoute utökar de lokala nätverken till Microsoft-molnet via en privat anslutning med hjälp av en anslutningsleverantör.
  • En Virtuell WAN-hubb dirigerar trafik på lämpligt sätt för säkerhet eller prestanda. Hubben innehåller olika tjänstslutpunkter för att aktivera anslutningen.
  • Användardefinierade vägar tvingar trafik till NVA:erna vid behov.
  • Varje NVA inspekterar trafik som flödar till ett virtuellt nätverk.
  • Peering för virtuella nätverk ger VNet-till-VNet-kontroll i den prestandaoptimerade miljön.

Företaget har flera regioner och fortsätter att distribuera regioner till modellen. Företaget distribuerar endast en säkerhetsoptimerad eller prestandaoptimerad miljö när det behövs. Miljöerna dirigerar följande trafik via den virtuella nätverksinstallationen (NVA):

Trafikvägar

Destinationer
VNet1 VNet2 VNet3 VNet4 Gren Internet
Säkerhetsoptimerad källa VNet1 Intra-VNet NVA1-VNet2 NVA1-hub-VNet3 NVA1-hub-VNet4 NVA1-hub-branch NVA1-internet
Prestandaoptimerad källa VNet3 hub-NVA1-VNet1 hub-NVA1-VNet2 Intra-VNet NVA2-VNet4 hub-branch NVA2-internet
Grenkälla Gren hub-NVA1-VNet1 hub-NVA1-VNet2 hub-VNet3 hub-VNet4 Ej tillämpligt Ej tillämpligt

Diagram som visar trafikvägar för arkitekturen.

Som föregående diagram visar tvingar en NVA- och routningsarkitektur alla trafikvägar i den säkerhetsoptimerade miljön att använda NVA mellan de virtuella nätverken och hubben i en gemensam arkitektur i lager.

Den prestandaoptimerade miljön har ett mer anpassat routningsschema. Det här schemat tillhandahåller en brandväggs- och trafikkontroll där de behövs. Den tillhandahåller ingen brandvägg där den inte behövs. VNet-till-VNet-trafik i det prestandaoptimerade utrymmet tvingas via NVA2, men trafik från gren till VNet kan gå direkt över hubben. På samma sätt behöver allt som är på väg till den säkra miljön inte gå till NVA VNet2 eftersom det inspekteras i utkanten av den säkra miljön av NVA i NVA VNet1. Resultatet är snabb åtkomst till grenen. Arkitekturen ger fortfarande VNet-till-VNet-kontroll i den prestandaoptimerade miljön. Detta är inte nödvändigt för alla kunder, men kan utföras via peerings som du kan se i arkitekturen.

Associationer och spridningar av Virtual WAN-hubben

Konfigurera vägar för Virtual WAN-hubben på följande sätt:

Name Associerad till Sprida till
NVA VNet1 defaultRouteTable defaultRouteTable
NVA VNet2 PerfOptimizedRouteTable defaultRouteTable
VNet3 PerfOptimizedRouteTable defaultRouteTable
VNet4 PerfOptimizedRouteTable defaultRouteTable

Routningskrav

  • En anpassad väg i standardroutningstabellen i Virtual WAN-hubben för att dirigera all trafik för VNet1 och VNet2 till secOpt Anslut ion.

    Vägnamn Måltyp Målprefix Nästa hopp Nästa hopp-IP
    Säkerhetsoptimerad väg CIDR 10.1.0.0/16 secOpt Anslut ion <IP-adress för NVA1>
  • En statisk väg på secOpt Anslut ion som vidarebefordrar trafiken för VNet1 och VNet2 till IP-adressen för NVA1.

    Name Adressprefix Nästa hopptyp Nästa hopp-IP-adress
    rt-to-secOptimized 10.1.0.0/16 Virtuell installation <IP-adress för NVA1>
  • En anpassad routningstabell på virtual WAN-hubben med namnet perfOptimizedRouteTable. Den här tabellen används för att säkerställa att de prestandaoptimerade virtuella nätverken inte kan kommunicera med varandra via hubben och måste använda peering till NVA VNet2.

  • En UDR som är associerad med alla undernät i VNet1 och VNet2 för att dirigera all trafik tillbaka till NVA1.

    Name Adressprefix Nästa hopptyp Nästa hopp-IP-adress
    rt-all 0.0.0.0/0 Virtuell installation <IP-adress för NVA1>
  • En UDR som är associerad med alla undernät i VNet3 och VNet4 för att dirigera VNet-till-VNet-trafik och Internettrafik till NVA2.

    Name Adressprefix Nästa hopptyp Nästa hopp-IP-adress
    rt-to-internet 0.0.0.0/0 Virtuell installation <IP-adress NVA2>
    vnet-till-vnet 10.2.0.0/16 Virtuell installation <IP-adress för NVA2>

Kommentar

Du kan ersätta NVA IP-adresser med lastbalanserarens IP-adresser i routningen om du distribuerar en arkitektur med hög tillgänglighet med flera NVA:er bakom lastbalanseraren.

Komponenter

  • Azure Virtual WAN. Virtual WAN är en nätverkstjänst som sammanför många funktioner för nätverk, säkerhet och routning för att tillhandahålla ett enda operativt gränssnitt. I det här fallet förenklas och skalas routningen till de anslutna virtuella nätverken och grenarna.
  • Azure ExpressRoute. ExpressRoute utökar lokala nätverk till Microsoft-molnet via en privat anslutning.
  • Azure Virtual Network. Virtuellt nätverk är den grundläggande byggstenen för ditt privata nätverk i Azure. Med virtuellt nätverk kan många typer av Azure-resurser, till exempel virtuella Azure-datorer, kommunicera med förbättrad säkerhet med varandra, Internet och lokala nätverk.
  • Virtuell WAN-hubb. En virtuell hubb är ett virtuellt nätverk som Microsoft hanterar. Hubben innehåller olika tjänstslutpunkter för att aktivera anslutningen.
  • Hubbanslutningar för virtuella nätverk. Hubbens virtuella nätverksanslutningsresurs ansluter hubben sömlöst till dina virtuella nätverk.
  • Statiska vägar. Statiska vägar ger en mekanism för att styra trafiken via en nästa hopp-IP.
  • Hubbroutningstabeller. Du kan skapa en virtuell hubbväg och tillämpa vägen på routningstabellen för den virtuella hubben.
  • Peering för virtuella nätverk. Genom att använda peering för virtuella nätverk kan du sömlöst ansluta två eller flera virtuella nätverk i Azure.
  • Användardefinierade vägar. Användardefinierade vägar är statiska vägar som åsidosätter standardvägarna för Azure-systemet eller lägger till fler vägar i ett undernäts routningstabell. De används här för att tvinga trafik till NVA:erna vid behov.
  • Virtuella nätverksinstallationer. Virtuella nätverksinstallationer är marketplace-erbjudna nätverksinstallationer. I det här fallet distribuerade företaget Palo Altos NVA, men alla NVA-brandväggar skulle fungera här.

Alternativ

Om du bara vill distribuera en NVA-miljö med hög säkerhet kan du följa den här modellen: Dirigera trafik via en NVA.

Information om hur du distribuerar en anpassad NVA-modell som stöder både routning av trafik till en dedikerad brandvägg för Internet och routning av grentrafik via en NVA finns i Dirigera trafik via NVA:er med hjälp av anpassade inställningar.

Det tidigare alternativet distribuerar en högsäkerhetsmiljö bakom en NVA och erbjuder vissa funktioner för att distribuera en anpassad miljö. Men det skiljer sig från det användningsfall som beskrivs i den här artikeln på två sätt. Först visar den de två modellerna isolerat i stället för i kombination. För det andra stöder den inte VNet-till-VNet-trafik i den anpassade miljön (vad vi kallar den prestandaoptimerade miljön här).

Att tänka på

I den här distributionen passerar vägar som korsar Virtual WAN-hubben till en prestandaoptimerad miljö inte genom NVA i den miljön. Det här är ett potentiellt problem med trafik mellan regioner som visas här:

Diagram som visar ett potentiellt problem med trafik mellan regioner.

Trafik mellan regioner mellan prestandaoptimerade miljöer korsar inte NVA. Det här är en begränsning för direkt routning av hubbtrafik till de virtuella nätverken.

Tillgänglighet

Virtual WAN är en nätverkstjänst med hög tillgänglighet. Du kan konfigurera fler anslutningar eller sökvägar från grenen för att få flera vägar till Virtual WAN-tjänsten. Men du behöver inget ytterligare inom VWAN-tjänsten.

Du bör konfigurera NVA:er i en arkitektur med hög tillgänglighet som liknar den som beskrivs här: Distribuera NVA:er med hög tillgänglighet.

Prestanda

Den här lösningen optimerar nätverkets prestanda vid behov. Du kan ändra routningen enligt dina egna krav, vilket gör att trafiken till grenen kan korsa NVA och trafiken mellan virtuella nätverk för att flöda fritt eller använda en enda brandvägg för utgående Internet.

Skalbarhet

Den här arkitekturen är skalbar mellan regioner. Tänk på dina krav när du konfigurerar routningsetiketter för grupperingsvägar och vidarebefordran av grentrafik mellan de virtuella hubbarna.

Säkerhet

Med NVA:er kan du använda funktioner som IDPS med Virtual WAN.

Motståndskraft

Information om återhämtning finns i Tillgänglighet tidigare i den här artikeln.

Kostnadsoptimering

Prissättningen för den här arkitekturen beror mycket på de NVA:er som du distribuerar. En 2 Gbit/s ER-anslutning och en Virtual WAN-hubb som bearbetar 10 TB per månad finns i den här prisuppskattningen.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Nästa steg