Använda Azure Firewall för att dirigera en topologi med flera hubbar och ekrar

Topologin hub-and-spoke är ett vanligt mönster för nätverksarkitektur i Azure som konsoliderar nätverksresurser och centraliserar nätverkstjänster. Den här topologin ger nätverksanslutning och säkerhet till virtuella nätverk som distribueras i olika prenumerationer eller klientorganisationer.

Du kan implementera hub-and-spoke-arkitekturer på två sätt:

• Självhanterad hub-and-spoke (traditionell): Du behåller fullständig kontroll över de virtuella hubbnätverken och routningskonfigurationen.
• Virtual WAN: Microsoft hanterar de virtuella hubbnätverken och förenklar administration via funktioner som routnings-avsikter och routningsprinciper.

Den här artikeln fokuserar på självadministrerade hubb- och ekertopologier där du har fullständig insyn och kontroll över det virtuella hubbnätverket och distributionen av Azure Firewall.

Du kan minska administrationskostnaderna för en självhanterad hub-and-spoke-implementering med hjälp av Azure Virtual Network Manager (AVNM). AVNM kan automatisera konfigurationen av rutttabeller, men den övergripande designen och teknikerna förändras inte jämfört med den manuella metoden. Innehållet i den här artikeln gäller oavsett om du använder AVNM eller konfigurerar din självhanterade hub-and-spoke-topologi manuellt.

Ett alternativ till routningstabeller i virtuella ekernätverk är att injicera rutter i undernät med Azure Route Server, så som beskrivs i Injektion av standardrutter i virtuella ekernätverk. Detta mönster används dock inte ofta på grund av den komplexitet som kan uppstå vid interaktioner mellan Azure Route Server och VPN- eller ExpressRoute-virtuella nätverksgateways.

I en självhanterad hub-and-spoke-konfiguration:

• Hubb: Ett virtuellt nätverk som fungerar som central anslutningspunkt till ditt lokala nätverk via VPN, ExpressRoute eller Software-Defined Wide Area Network (SD-WAN). Du installerar nätverkssäkerhetsenheter, såsom brandväggar, i hubbens virtuella nätverk.
• Ekrar: Virtuella nätverk som peerkopplas med hubben och är värdar för dina arbetsbelastningar.

För arbetsbelastningar fördelade över flera regioner brukar du vanligtvis distribuera en hubb per region för att samla trafik från anslutningarna i den regionen. Följande diagram visar en självhanterad hub-and-spoke-arkitektur med två virtuella ekernätverk i varje region:

Arkitektur för nav och eker för en region

För att förstå designen för flera regioner måste du först förstå begreppen för en region. Följande diagram visar konfigurationen av routningstabellen för den första regionen:

Överväg routningskraven för varje potentiellt trafikflöde i designen för en region för att förstå den användardefinierade routningskonfigurationen:

• Spoke-to-spoke-trafik: Ekrar är inte peer-kopplade till varandra och peering för virtuella nätverk är inte transitivt. Varje eker vet hur man dirigerar till det virtuella hubbnätverket som standard, men inte till andra ekrar. En väg för 0.0.0.0/0 tillämpad på alla talundernät omfattar tal-till-tal-trafik.
• Trafik från ekern till internet: Routen 0.0.0.0/0 i routetabellen för ekern dirigerar trafik till det publika internetet till Azure Firewall. I ett icke-privat subnät som har standardåtkomst för utgående trafik, åsidosätter den användardefinierade rutten standardrutten för internetsystemet. Nya virtuella nätverk skapade med API-versioner som släpptes efter den 31 mars 2026 använder privata subnät som standard och kräver en explicit utgående metod. I denna design ger Azure Firewall explicit utgående anslutning. Mer information finns i Standardåtkomst för utgående trafik i Azure.
• Internet-till-eker-trafik: Trafik från Internet till ekern går vanligtvis genom Azure Firewall först. Azure Firewall har konfigurerat DNAT-regler (Destination Network Address Translation), som även översätter källans IP-adress (källnätverksadressöversättning eller SNAT). Ekerbelastningarna uppfattar trafiken som att den kommer från Azure Firewall-undernätet. Peering för virtuella nätverk skapar systemvägar till hubben (10.1.0.0/24), så ekrarna vet hur de dirigerar returtrafik.
• Lokal-till-nav och nav-till-lokal trafik: Överväg varje riktning separat:
  • Lokal-till-eker-trafik: Trafiken kommer från det lokala nätverket till VPN- eller ExpressRoute-gatewayerna. Med standarddirigering i Azure skapas en systemväg i GatewaySubnet (och andra undernät i det virtuella hubbnätverket) för varje delnät. Du måste åsidosätta dessa systemvägar och ange nästa hopp till Azure Firewalls privata IP-adress. I det här exemplet behöver du två rutter i en routetabell som är associerad med gateway-undernätet, en för varje nod (10.1.1.0/24 och 10.1.2.0/24). Användning av en sammanfattning som 10.1.0.0/16 som omfattar alla virtuella spindelnätverk fungerar inte eftersom systemrutterna som injiceras av de virtuella nätverkspeeringarna inom gatewayundernätet är mer specifika (/24 än sammanfattningen /16). Den här routningstabellen måste ha växlingsknappen Sprid gatewayvägar aktiverad (inställd på Ja), annars kan gatewayroutning bli oförutsägbar.
  • Spoke-till-lokal trafik: Peerings för virtuella nätverk mellan hubben och spokarna måste ha Tillåt gatewayöverföring aktiverat på hubbsidan och Använd fjärrgatewayer aktiverat på spoksidan. De här inställningarna krävs så att VPN- och ExpressRoute-gatewayerna annonserar talprefixen över Border Gateway Protocol (BGP) till lokala nätverk. Dessa inställningar gör också att förbindelserna lär sig prefixen som tillkännages från lokala nätverk till Azure som standard. Eftersom de lokala prefixen är mer specifika än den användardefinierade routen 0.0.0.0/0 i routningstabellen för spoke-nätverket går trafiken från spoke-nätverk till lokala nätverk som standard förbi brandväggen. För att förhindra den här situationen ställer du in Sprid gateway-rutter-växlingsknappen på Nej i spoke-routningstabellen så att prefix från det lokala nätverket inte lärs in och 0.0.0.0/0-rutten används för trafik till det lokala nätverket.

Du kan hantera både routningstabellen som är associerad med spoke-undernäten och routningstabellen som är associerad med gateway-undernätet med hjälp av Azure Virtual Network Manager för att minska den administrativa belastningen. Mer information finns i Använda Azure Firewall som nästa hopp.

Arbetsbelastningar för virtuellt hubbnätverk

Att distribuera arbetsbelastningar i hubbens virtuella nätverk, såsom služba Active Directory-domänkontroller, DNS-servrar eller annan delad infrastruktur, ökar komplexiteten i hub-och-eker-designen. Undvik att placera arbetsbelastningar i hubben. Placera dem i stället i en dedikerad spoke för gemensamma tjänster.

I det här avsnittet beskrivs den konfiguration som krävs för hubbarbetsbelastningar så att du kan utvärdera om den här komplexiteten är acceptabel för dina krav. Vi beskriver också ett vanligt misstag som kan orsaka asymmetrisk trafik och paketförluster.

Följande diagram visar en design för en region med ett arbetsbelastningsundernät i det virtuella hubbnätverket:

Den viktiga informationen är att de användardefinierade vägar som konfigurerats i både gatewayundernätet och ekerundernäten definieras för det specifika arbetsbelastningsundernätet och inte för hela navets virtuella nätverksprefix:

• Gateway-undernätskonfiguration: Om du konfigurerar en väg i gatewayundernätet för hela det virtuella hubbnätverket (10.1.0.0/24 i det här exemplet) åsidosätts systemvägen för det virtuella hubbnätverket. Detta gör att trafik för intra-undernätskontroll mellan VPN- eller ExpressRoute-gateway skickas till brandväggen, vilket kan störa gatewaydriften.
• Konfiguration av spoke-underliggande nätverk: Genom att konfigurera en rutt i spoke-nätverken för hela det virtuella hubbnätverket (10.1.0.0/24 i detta exempel) åsidosätts den systemrutt som skapats vid peering med det virtuella hubbnätverket. All trafik som skickas till hubben skickas till Azure Firewall, inklusive trafik som kommer från själva Azure Firewall, till exempel internet-till-eker-trafik som går via SNAT (Source Network Address Translation). Den här konfigurationen introducerar asymmetrisk trafik och orsakar paketförluster.

Trafikkontroll mellan undernät

I den nuvarande konfigurationen hanterar brandväggen trafiken mellan spoke-nätverk, men trafik inom en spoke förblir inom det virtuella spoke-nätverket, där du styr den med hjälp av nätverkssäkerhetsgrupper. Den här designen betraktar virtuella nätverk som en säkerhetsgräns: brandväggen inspekterar endast trafik som lämnar eller går in i ett virtuellt nätverk.

Om du vill inspektera trafik mellan undernät i samma virtuella ekernätverk ändrar du routningstabellen som är associerad med ekerundernäten enligt följande diagram:

I föregående diagram introduceras två ekerundernät i varje virtuellt ekernätverk, och routningstabellerna för ekrarna i det virtuella nätverket A2 beskrivs. Att skicka trafik mellan undernät till brandväggen kräver att varje undernät har en separat routningstabell eftersom vägarna som ska installeras i varje undernät skiljer sig åt.

För undernät A21 behöver du följande två extra vägar:

• Väg till 10.1.2.0/24: Åsidosätter systemvägen för intra-virtuell nätverkstrafik. Utan andra vägar skickas all intra-virtuell nätverkstrafik till Azure Firewall, även trafik mellan virtuella datorer i samma undernät.
• Dirigera till 10.1.2.0/26 med nästa hopp Virtuellt nätverk: Ett undantag till föregående väg, så trafik i det här specifika undernätet skickas inte till brandväggen utan dirigeras lokalt i det virtuella nätverket. Den här vägen är specifik för varje undernät, varför du behöver en separat routningstabell för varje undernät.

SD-WAN virtuella nätverksapparater

Om du använder SD-WAN virtuella nätverksinstallationer (NVA) i stället för VPN- eller ExpressRoute-gatewayer är designen liknande, som du ser i följande diagram:

Du kan integrera SD-WAN NVAs i Azure på olika sätt. Mer information finns i SD-WAN integration med Azure hub-and-spoke-nätverkstopologier. Den här artikeln visar integration som använder Azure Route Server, en av de vanligaste metoderna för att dirigera trafik till SD-WAN nätverk. SD-WAN-NVA:erna annonserar ut de lokala nätverksprefixen till Azure Route Server via BGP. Azure Route Server matar in dessa prefix i Azure Firewall-undernätet så att Azure Firewall har routningsinformation för lokala nätverk. Ekrarna lär sig inte de lokala prefixen eftersom alternativet "Sprid gatewayvägar" är inaktiverat i ekervägstabellen.

Om du inte vill konfigurera prefixet för varje spoke-nätverk i routningstabellen som är associerad med NVA-undernätet, kan du placera SD-WAN Nätverksvirtualiseringsapplikationer (NVA:er) i deras dedikerade virtuella nätverk. Eftersom det virtuella NVA-nätverket inte är direkt peerkopplat med spoke-prefixen, lär det sig inte dem. En översiktsväg är möjlig, vilket visas i följande diagram:

Arkitektur med nav-och-ekrar för flera regioner

När du förstår hur trafik fungerar inom en enda hub-and-spoke-region är det enkelt att utöka designen till en arkitektur med flera regioner. Följande diagram visar en uppdaterad nätverksdesign med hubbar i två regioner (A och B):

Det enda tillägget till konfigurationen är de routningstabeller som är associerade med Azure Firewall-undernäten i varje region. Varje virtuellt navnätverk känner bara till prefixen för de direkt peerkopplade virtuella nätverken, så det finns ingen routning för prefixen för fjärr ekrar. Lägg till användardefinierade vägar för varje Azure Firewall-undernät så att trafik för varje region dirigeras till motsvarande Azure Firewall.

I det här exemplet kan varje region enkelt sammanfattas:

• Region A innehåller prefix i 10.1.0.0/16
• Region B innehåller prefix i 10.2.0.0/16

Om du definierar IP-adresser i varje region som enkelt sammanfattas blir routningskonfigurationen enklare. Annars måste du skapa en rutt för varje fjärransluten anslutning.

Aktivera Spridning av gatewayvägar i azure firewall-undernätets routningstabell så att brandväggen kan lära sig lokala vägar från VPN- och ExpressRoute-gatewayer.

För att förenkla hanteringen av användardefinierade vägar i en miljö med flera regioner kan du använda Azure Virtual Network Manager. Mer information finns i Hantera användardefinierade vägar över flera hubb- och ekertopologier med AVNM.

Nästa steg

• Lär dig hur du distribuerar och konfigurerar en Azure Firewall.