Azure Firewall gebruiken om een topologie met meerdere hubs en spokes te routeren

De hub-and-spoke-topologie is een gemeenschappelijk patroon voor netwerkarchitectuur in Azure waarmee netwerkresources worden geconsolideerd en netwerkservices worden gecentraliseerd. Deze topologie biedt netwerkconnectiviteit en -beveiliging voor virtuele netwerken die zijn geïmplementeerd in verschillende abonnementen of tenants.

U kunt hub-and-spoke-architecturen op twee manieren implementeren:

• Zelfbeheerde hub en spoke (traditioneel): u behoudt volledige controle over de virtuele hubnetwerken en routeringsconfiguratie.
• Virtual WAN: Microsoft beheert de virtuele hubnetwerken en vereenvoudigt het beheer via functies zoals routeringsintentie en routeringsbeleid.

Dit artikel is gericht op zelfbeheerde hub-and-spoke-topologieën waar u volledige zichtbaarheid en controle hebt over het virtuele hubnetwerk en de Azure Firewall-implementatie.

U kunt de beheeroverhead van een zelfbeheerde hub-and-spoke-implementatie verminderen met behulp van Azure Virtual Network Manager (AVNM). AVNM kan de configuratie van routetabellen automatiseren, maar het algemene ontwerp en de technieken veranderen niet vergeleken met de handmatige aanpak. De inhoud van dit artikel is van toepassing of u AVNM gebruikt of uw zelfbeheerde hub-en-spoke-topologie handmatig configureert.

Een alternatief voor routetabellen in de spoken-virtuele netwerken is het injecteren van routes in subnetten met Azure Route Server, zoals gedocumenteerd in Default route injection in spoke virtual networks. Dit patroon wordt echter niet vaak gebruikt vanwege de complexiteit die kan ontstaan door interacties tussen Azure Route Server en VPN- of ExpressRoute-virtuele netwerkgateways.

In een zelfbeheerde hub-and-spoke-configuratie:

• Hub: Een virtueel netwerk dat fungeert als het centrale connectiviteitspunt naar uw on-premises netwerk via VPN, ExpressRoute of Software-Defined Wide Area Network (SD-WAN). Je zet netwerkbeveiligingsapparaten uit, zoals firewalls, in het virtuele netwerk van de hub.
• Spokes: virtuele netwerken die peeren met de hub en uw workloads hosten.

Voor workloads verspreid over meerdere regio's implementeert u doorgaans één hub per regio om verkeer van de spokes in die regio samen te voegen. In het volgende diagram ziet u een zelfbeheerde hub-en-spoke-architectuur met twee spoke-virtuele netwerken in elke regio:

Hub-and-spoke-architectuur met één enkele regio

Als u het ontwerp voor meerdere regio's wilt begrijpen, moet u eerst de concepten van één regio begrijpen. In het volgende diagram ziet u de configuratie van de routeringstabel voor de eerste regio:

Houd rekening met de routeringsvereisten voor elke potentiële verkeersstroom in het ontwerp voor één regio om inzicht te krijgen in de door de gebruiker gedefinieerde routeconfiguratie:

• Spoke-to-spoke-verkeer: spokes worden niet aan elkaar gekoppeld en peering van virtuele netwerken is niet transitief. Elke spoke weet standaard hoe hij moet worden gerouteerd naar het virtuele hubnetwerk, maar niet naar andere spokes. Een route voor 0.0.0.0/0 toegepast op alle spoke-subnetten omvat spoke to spoke verkeer.
• Verkeer van spoke naar internet: De 0.0.0.0/0 route in de routetabel van de spoke leidt verkeer naar het openbare internet naar Azure Firewall. In een niet-privé subnet met standaard uitgaande toegang overschrijft de door de gebruiker gedefinieerde route de standaard internetsysteemroute. Nieuwe virtuele netwerken die zijn gemaakt met API-versies die na 31 maart 2026 zijn uitgebracht, gebruiken standaard privé-subnetten en vereisen een expliciete uitgaande methode. In dit ontwerp biedt Azure Firewall expliciete uitgaande connectiviteit. Zie De standaard uitgaande toegang in Azure voor meer informatie.
• Internet-naar-spoke-verkeer: verkeer van internet naar de spoke gaat meestal eerst via Azure Firewall. Azure Firewall heeft DNAT-regels (Destination Network Address Translation) geconfigureerd, waarmee ook het bron-IP-adres (Source Network Address Translation of SNAT) wordt omgezet. De spoke-workloads zien verkeer als afkomstig van het Azure Firewall-subnet. Door peering voor virtuele netwerken worden systeemroutes naar de hub (10.1.0.0/24) gemaakt, zodat de spokes het retourverkeer goed kunnen routeren.
• On-premises-naar-spoke- en spoke-naar-on-premises verkeer: Houd rekening met elke richting afzonderlijk:
  • On-premises-naar-spoke-verkeer: verkeer komt van het on-premises netwerk naar de VPN- of ExpressRoute-gateways. Met standaardroutering in Azure wordt voor elke spoke een systeemroute gemaakt in gatewaysubnet (en andere subnetten in het virtuele hubnetwerk). U moet deze systeemroutes overschrijven en de volgende hop instellen op het privé-IP-adres van de Azure Firewall. In dit voorbeeld hebt u twee routes nodig in een routetabel die is gekoppeld aan het gatewaysubnet, één voor elke spoke (10.1.1.0/24 en 10.1.2.0/24). Het gebruik van een samenvatting zoals 10.1.0.0/16 die omvat alle virtuele spoke-netwerken werkt niet omdat de systeemroutes die zijn geïnjecteerd door de peerings van het virtuele netwerk in het gatewaysubnet specifieker zijn (/24 vergeleken met de /16 samenvatting). Voor deze routetabel moet de wisselknop Gatewayroutes doorgeven zijn ingeschakeld (ingesteld op Ja), anders kan gatewayroutering onvoorspelbaar worden.
  • Spoke-to-on-premises verkeer: de peerings van het virtuele netwerk tussen de hub en spokes moeten Gatewaydoorvoer toestaan ingeschakeld hebben aan de hubzijde en Externe gateways gebruiken ingeschakeld hebben aan de spoke-zijde. Deze instellingen zijn vereist zodat de VPN- en ExpressRoute-gateways de spoke-voorvoegsels via Border Gateway Protocol (BGP) aankondigen naar lokale netwerken. Deze instellingen zorgen er ook voor dat de spokes standaard de voorvoegsels leren die vanaf on-premises naar Azure geadverteerd worden. Omdat on-premises prefixes specifieker zijn dan de door de gebruiker gedefinieerde route 0.0.0.0/0 in de spokenroutetabel, omzeilt het verkeer van spaken naar on-premises standaard de firewall. Om deze situatie te voorkomen, stel je de schakelaar van de Propagate gateway-routes in de spoke-routetabel op Nee , zodat on-premises prefixes niet worden geleerd en de 0.0.0.0/0 route wordt gebruikt voor verkeer naar on-premises.

Je kunt zowel de routetabel die bij de spokensubnetten hoort als de routetabel die bij het gateway-subnet hoort beheren door Azure Virtual Network Manager te gebruiken om administratieve overhead te verminderen. Zie Azure Firewall gebruiken als de volgende hop voor meer informatie.

Hub-virtuele-netwerk-workloads

Het uitrollen van workloads in het hub-virtuele netwerk, zoals Active Directory-domeincontrollers, DNS-servers of andere gedeelde infrastructuur, verhoogt de complexiteit van het hub-en-spokenontwerp. Vermijd het plaatsen van workloads in de hub. Zet ze in plaats daarvan in in een speciale spaak voor gedeelde diensten.

In deze sectie wordt de configuratie beschreven die is vereist voor hubworkloads, zodat u kunt evalueren of deze complexiteit acceptabel is voor uw vereisten. We beschrijven ook een veelvoorkomende fout die asymmetrische verkeersstromen en pakketverlies kan veroorzaken.

In het volgende diagram ziet u een ontwerp met één regio met een workloadsubnet in het virtuele hubnetwerk:

Het kritieke detail is dat de door de gebruiker gedefinieerde routes die zijn geconfigureerd in zowel het gatewaysubnet als de spoke-subnetten zijn gedefinieerd voor het specifieke workloadsubnet en niet voor het voorvoegsel van het hele virtuele hubnetwerk:

• Gateway subnet configuratie: Als u een route configureert in het gateway subnet voor het hele virtuele hubnetwerk (zoals in dit voorbeeld) wordt de systeemroute voor het virtuele hubnetwerk overschreven. Dit zorgt ervoor dat intra-subnet controleverkeer tussen de VPN- of ExpressRoute-gateways naar de firewall wordt verzonden, waardoor de gatewayoperatie mogelijk wordt onderbroken.
• Configuratie van spoke-subnet: Als u een route configureert in de spoke-subnetten voor het hele virtuele hubnetwerk (10.1.0.0/24 in dit voorbeeld) overschrijft u de systeemroute die is gemaakt door de peering met het virtuele hubnetwerk. Al het verkeer dat naar de hub wordt verzonden, wordt verzonden naar Azure Firewall, inclusief verkeer dat afkomstig is van Azure Firewall zelf, zoals internet-naar-spoke-verkeer dat via SNAT (Source Network Address Translation) gaat. Deze configuratie introduceert asymmetrisch verkeer en veroorzaakt pakketdruppels.

Inspectie van verkeer tussen subnetten

In de huidige opzet verwerkt de firewall het verkeer tussen spoken, maar intra-spoken verkeer blijft binnen het spokenvirtuele netwerk, waar je het aanstuurt met netwerkbeveiligingsgroepen. Dit ontwerp beschouwt virtuele netwerken als een beveiligingsgrens: de firewall inspecteert alleen verkeer dat een virtueel netwerk verlaat of binnenkomt.

Als u verkeer tussen subnetten in hetzelfde virtuele spoke-netwerk wilt controleren, wijzigt u de routetabel die is gekoppeld aan de spoke-subnetten, zoals wordt weergegeven in het volgende diagram:

In het vorige diagram worden twee spoke-subnetten geïntroduceerd in elk virtueel spoke-netwerk en worden de routetabellen voor de spokes in het virtuele netwerk A2 beschreven. Voor het verzenden van verkeer tussen subnetten naar de firewall is vereist dat elk subnet een afzonderlijke routetabel heeft, omdat de routes die in elk subnet moeten worden geïnstalleerd, verschillend zijn.

Voor subnet A21 hebt u deze twee extra routes nodig:

• Route naar 10.1.2.0/24: Overschrijft de systeemroute voor verkeer tussen virtuele netwerken. Zonder andere routes wordt al het verkeer tussen virtuele netwerken verzonden naar Azure Firewall, zelfs verkeer tussen virtuele machines in hetzelfde subnet.
• Route naar 10.1.2.0/26 met het volgende hop-virtuele netwerk: een uitzondering op de vorige route, zodat verkeer binnen dit specifieke subnet niet naar de firewall wordt verzonden, maar lokaal binnen het virtuele netwerk wordt gerouteerd. Deze route is specifiek voor elk subnet. Daarom hebt u voor elk subnet een afzonderlijke routetabel nodig.

SD-WAN virtuele netwerkapparaten

Als u SD-WAN NVA's (Network Virtual Appliances) gebruikt in plaats van VPN- of ExpressRoute-gateways, is het ontwerp vergelijkbaar, zoals wordt weergegeven in het volgende diagram:

Je kunt SD-WAN NVAs op verschillende manieren in Azure integreren. Zie SD-WAN integratie met azure-hub-and-spoke-netwerktopologieën voor meer informatie. Dit artikel toont integratie die gebruikmaakt van Azure Route Server, een van de meest gebruikte methoden om verkeer naar SD-WAN netwerken te routeren. De SD-WAN NVA’s kondigen de on-premises-prefixen aan bij Azure Route Server via BGP. Azure Route Server injecteert deze voorvoegsels in het Azure Firewall-subnet, zodat Azure Firewall routeringsinformatie heeft voor on-premises netwerken. Omdat de optie "Gatewayroutes propageren" is uitgeschakeld in de spoke-routetabel, leren de spokes de on-premises voorvoegsels niet.

Als u het voorvoegsel van elk virtueel spoke-netwerk niet wilt configureren in de routetabel die is gekoppeld aan het NVA-subnet, kunt u de SD-WAN NVA's in een specifiek virtueel netwerk plaatsen. Het virtuele NVA-netwerk leert de spoke-prefixen niet omdat er geen directe koppeling is en een samenvattingsroute mogelijk is, zoals wordt weergegeven in het volgende diagram.

Hub-and-spoke-architectuur voor meerdere regio's

Nadat u hebt begrepen hoe verkeer in één hub-and-spoke-regio werkt, is het eenvoudig om het ontwerp uit te breiden naar een architectuur met meerdere regio's. In het volgende diagram ziet u een bijgewerkt netwerkontwerp met hubs in twee regio's (A en B):

De enige toevoeging aan de configuratie is de routetabellen die zijn gekoppeld aan de Azure Firewall-subnetten in elke regio. Elk virtueel hubnetwerk kent alleen de voorvoegsels van de rechtstreeks gekoppelde virtuele netwerken, dus er is geen routering voor de voorvoegsels van externe spokes. Voeg door de gebruiker gedefinieerde routes toe voor elk Azure Firewall-subnet, zodat verkeer voor elke regio wordt gerouteerd naar de bijbehorende Azure Firewall.

In dit voorbeeld kan elke regio eenvoudig worden samengevat:

• Regio A bevat voorvoegsels in 10.1.0.0/16
• Regio B bevat voorvoegsels in 10.2.0.0/16

Het definiëren van IP-adressen in elke regio die eenvoudig worden samengevat, maakt uw routeringsconfiguratie eenvoudiger. Anders moet u één route maken voor elke remote spoke.

Schakel gatewayroutes doorgeven in op de routetabel van het Azure Firewall-subnet, zodat de firewall on-premises routes van VPN- en ExpressRoute-gateways kan leren.

Om het beheer van door de gebruiker gedefinieerde routes in een omgeving met meerdere regio's te vereenvoudigen, kunt u Azure Virtual Network Manager gebruiken. Zie Door de gebruiker gedefinieerde routes beheren in meerdere hub-and-spoke-topologieën met AVNM voor meer informatie.

Volgende stappen

• Meer informatie over het implementeren en configureren van een Azure Firewall.