Standaardroute-injectie in virtuele spoke-netwerken

Een van de meest voorkomende architecturen in Azure is het hub- en spoke-ontwerp, waarbij workloads die zijn geïmplementeerd in een virtueel spoke-netwerk (VNet) verkeer verzenden via gedeelde netwerkapparaten die aanwezig zijn in het hub-VNet. Door de gebruiker gedefinieerde routes (UDR) moeten doorgaans worden geconfigureerd in de spoke-VNets om verkeer naar beveiligingsapparaten in de hub te sturen. Voor dit ontwerp moeten beheerders deze routes echter op veel spokes beheren.

Azure Route Server biedt een gecentraliseerd punt waar virtuele netwerkapparaten (NVA's) routes kunnen adverteren die worden geïnjecteerd in de spoke-VNets. Op deze manier hoeven beheerders geen routetabellen te maken en bij te werken in spoke-VNets.

Topologie

In het volgende diagram ziet u een eenvoudig hub- en spoke-ontwerp met een hub-VNet en twee spoke-VNets. In de hub zijn een virtueel netwerkapparaat en een routeserver geïmplementeerd. Zonder de routeserver moeten door de gebruiker gedefinieerde routes in elke spoke worden geconfigureerd. Deze UDR's bevatten meestal een standaardroute voor 0.0.0.0/0 waarmee al het verkeer van de spoke-VNets via de NVA wordt verzonden. Dit scenario kan bijvoorbeeld worden gebruikt om het verkeer te inspecteren voor beveiligingsdoeleinden.

Met de routeserver in het hub-VNet hoeft u geen door de gebruiker gedefinieerde routes te gebruiken. De NVA adverteert netwerkvoorvoegsels aan de routeserver, die ze injecteert zodat ze worden weergegeven in de effectieve routes van een virtuele machine die is geïmplementeerd in het hub-VNet of spoke-VNet die zijn gekoppeld aan het hub-VNet met de instelling Gebruik de gateway of routeserver van het externe virtuele netwerk.

Verbinding maken iviteit van on-premises via de NVA

Als de NVA wordt gebruikt om connectiviteit te bieden met on-premises netwerk via IPsec VPN's of SD-WAN-technologieën, kan hetzelfde mechanisme worden gebruikt om verkeer van de spokes naar de NVA aan te trekken. Daarnaast kan de NVA dynamisch de Azure-voorvoegsels van de Azure Route Server leren en deze adverteren met een dynamisch routeringsprotocol naar on-premises. In het volgende diagram wordt deze installatie beschreven:

Privéverkeer inspecteren via de NVA

In de vorige secties ziet u het verkeer dat wordt geïnspecteerd door het virtuele netwerkapparaat (NVA) door een 0.0.0.0/0 standaardroute van de NVA naar de routeserver te injecteren. Als u echter alleen spoke-to-spoke- en spoke-to-on-premises verkeer wilt inspecteren via de NVA, moet u er rekening mee houden dat Azure Route Server geen route adverteert die hetzelfde of langer voorvoegsel is dan de adresruimte van het virtuele netwerk die is geleerd van de NVA. Met andere woorden, Azure Route Server injecteert deze voorvoegsels niet in het virtuele netwerk en ze worden niet geprogrammeerd op de NIC's van virtuele machines in de hub- of spoke-VNets.

Azure Route Server zal echter een groter subnet adverteren dan de VNet-adresruimte die is geleerd van de NVA. Het is mogelijk om vanuit de NVA een supernet te adverteren van wat u in uw virtuele netwerk hebt. Als uw virtuele netwerk bijvoorbeeld gebruikmaakt van de RFC 1918-adresruimte 10.0.0.0/16, kan uw NVA adverteren 10.0.0.0/8 naar de Azure Route Server en worden deze voorvoegsels opgenomen in de hub- en spoke-VNets. Naar dit VNet-gedrag wordt verwezen in About BGP met VPN Gateway.

Belangrijk

Als u een scenario hebt waarin voorvoegsels met dezelfde lengte worden geadverteerd vanuit ExpressRoute en de NVA, geeft Azure de voorkeur aan en programmeert Azure de routes die zijn geleerd van ExpressRoute. Zie de volgende sectie voor meer informatie.

Verbinding maken iviteit van on-premises via virtuele netwerkgateways

Als er een VPN of een ExpressRoute-gateway bestaat in hetzelfde virtuele netwerk als de Route Server en NVA om connectiviteit met on-premises netwerken te bieden, worden routes die door deze gateways zijn geleerd, ook geprogrammeerd in de spoke-VNets. Deze routes overschrijven de standaardroute (0.0.0.0/0) die door de routeserver is geïnjecteerd, omdat ze specifieker zijn (langere netwerkmaskers). In het volgende diagram wordt het vorige ontwerp beschreven, waar een ExpressRoute-gateway is toegevoegd.

U kunt de subnetten in de spoke-VNets niet configureren om alleen de routes van de Azure Route Server te leren. Als u Gatewayroutes doorgeven uitschakelt in een routetabel die is gekoppeld aan een subnet, kunnen beide typen routes (routes van de gateway van het virtuele netwerk en routes van de Azure Route Server) worden opgenomen in NIC's in dat subnet.

De routeserver kondigt standaard alle voorvoegsels aan die zijn geleerd van de NVA naar ExpressRoute. Dit is mogelijk niet gewenst, bijvoorbeeld vanwege de routelimieten van ExpressRoute of de routeserver zelf. In dat geval kan de NVA de routes aankondigen naar de routeserver, inclusief de BGP-community no-advertise (met waarde 65535:65282). Wanneer Route Server routes ontvangt met deze BGP-community, worden ze in de subnetten geplaatst, maar worden ze niet geadverteerd naar andere BGP-peers (zoals ExpressRoute- of VPN-gateways of andere NVA's).

SDWAN-co-existentie met ExpressRoute en Azure Firewall

Een bepaald geval van het vorige ontwerp is wanneer klanten de Azure Firewall in de verkeersstroom invoegen om al het verkeer naar on-premises netwerken te inspecteren, hetzij via ExpressRoute of via SD-WAN/VPN-apparaten. In deze situatie hebben alle spoke-subnetten routetabellen die voorkomen dat de spokes een route van ExpressRoute of de RouteServer leren en standaardroutes (0.0.0.0.0/0) hebben met de Azure Firewall als volgende hop, zoals in het volgende diagram wordt weergegeven:

Het Azure Firewall-subnet leert de routes die afkomstig zijn van zowel ExpressRoute als de VPN/SDWAN NVA, en bepaalt of verkeer op één manier of de andere wordt verzonden. Zoals beschreven in de vorige sectie, als het NVA-apparaat meer dan 200 routes naar de routeserver adverteert, moet het de BGP-routes verzenden die zijn gemarkeerd met de BGP-community no-advertise. Op deze manier worden de SDWAN-voorvoegsels niet opnieuw naar on-premises geïnjecteerd via Express-Route.

Verkeerssymmetrie

Als er meerdere NVA-exemplaren worden gebruikt in een actief/actief scenario voor betere tolerantie of schaalbaarheid, is verkeerssymmetrie een vereiste als de NVA's de status van de verbindingen moeten behouden. Dit is bijvoorbeeld het geval van Firewalls van de volgende generatie.

• Voor connectiviteit van de virtuele Azure-machines met het openbare internet maakt de NVA gebruik van SNAT (Source Network Address Translation), zodat uitgaand verkeer wordt opgehaald uit het openbare IP-adres van de NVA, waardoor verkeerssymmetrie wordt bereikt.
• Voor inkomend verkeer van internet naar werkbelastingen die worden uitgevoerd op virtuele machines, naast doelnetwerkadresomzetting (DNAT), moeten de NVA's bronnetwerkadresomzetting (SNAT) uitvoeren om ervoor te zorgen dat het retourverkeer van de virtuele machines terechtkomt in hetzelfde NVA-exemplaar dat het eerste pakket heeft verwerkt.
• Voor Azure-naar-Azure-connectiviteit, omdat de virtuele bronmachine onafhankelijk van de bestemming de routeringsbeslissing neemt, is SNAT vandaag vereist om verkeerssymmetrie te bereiken.

Meerdere NVA-exemplaren kunnen ook worden geïmplementeerd in een actieve/passieve installatie, bijvoorbeeld als een van deze exemplaren slechtere routes (met een langer AS-pad) adverteert dan de andere. In dit geval injecteert Azure Route Server alleen de voorkeursroute in de virtuele VNet-machines en wordt de minder voorkeursroute alleen gebruikt wanneer het primaire NVA-exemplaar stopt met adverteren via BGP.

Verschillende routeservers om routes te adverteren naar virtuele netwerkgateways en naar VNets

Zoals in de vorige secties is getoond, heeft Azure Route Server een dubbele rol:

• Er worden routes naar/van virtuele netwerkgateways (VPN en ExpressRoute) geleerd en geadverteerd
• Het configureert geleerde routes op het VNet en op rechtstreeks gekoppelde VNets

Deze dubbele functionaliteit is vaak interessant, maar soms kan het schadelijk zijn voor bepaalde vereisten. Als de routeserver bijvoorbeeld wordt geïmplementeerd in een VNet met een NVA met een route 0.0.0.0/0 en een ExpressRoute-gateway voor reclamevoorvoegsels van on-premises, configureert deze alle routes (zowel de 0.0.0.0/0 als de NVA en de on-premises voorvoegsels) op de virtuele machines in het VNet en rechtstreeks gekoppelde VNets. Als gevolg hiervan, omdat de on-premises voorvoegsels meer specifiek zijn dan 0.0.0.0/0, wordt het verkeer tussen on-premises en Azure de NVA overgeslagen. Als dit niet gewenst is, hebben de vorige secties in dit artikel laten zien hoe u BGP-doorgifte kunt uitschakelen in de VM-subnetten en UDR's configureert.

Er is echter een alternatieve, dynamischere benadering. Het is mogelijk om verschillende Azure Route-servers te gebruiken voor verschillende functionaliteit: een van deze servers is verantwoordelijk voor interactie met de gateways van het virtuele netwerk en de andere voor interactie met de routering van het virtuele netwerk. In het volgende diagram ziet u een mogelijk ontwerp voor dit:

Route Server 1 in de hub wordt gebruikt om de voorvoegsels van de SDWAN in ExpressRoute te injecteren. Omdat de spoke-VNets zijn gekoppeld aan het hub-VNet zonder de gateway of routeserver van het externe virtuele netwerk (in de spoke-VNet-peering) en de gateway of routeserver van dit virtuele netwerk gebruiken (gatewaydoorvoer in de hub-VNet-peering), leren de spoke-VNets deze routes niet (noch de SDWAN-voorvoegsels noch de ExpressRoute-voorvoegsels).

Om routes door te geven aan de spoke-VNets, gebruikt de NVA Route Server 2, geïmplementeerd in een nieuw hulp-VNet. De NVA geeft slechts één 0.0.0.0/0 route door naar Route Server 2. Omdat de spoke-VNets zijn gekoppeld aan dit hulp-VNet met de gateway of routeserver van het externe virtuele netwerk (in de spoke-VNet-peering) en de gateway of routeserver van dit virtuele netwerk gebruiken (gatewayoverdracht in de hub-VNet-peering), wordt de 0.0.0.0/0 route geleerd door alle virtuele machines in de spokes.

De volgende hop voor de 0.0.0.0/0 route is de NVA, dus de spoke-VNets moeten nog steeds worden gekoppeld aan het hub-VNet. Een ander belangrijk aspect is dat het hub-VNet moet worden gekoppeld aan het VNet waar Route Server 2 wordt geïmplementeerd, anders kan het geen BGP-aangrenzing maken.

Als verkeer van ExpressRoute naar de spoke-VNets moet worden verzonden naar een firewall-NVA voor inspectie, is er nog steeds een routetabel in het GatewaySubnet vereist, anders verzendt de virtuele ExpressRoute-netwerkgateway pakketten naar de virtuele machines met behulp van de routes die worden geleerd van VNet-peering. De routes in deze routetabel moeten overeenkomen met de spoke-voorvoegsels en de volgende hop moet het IP-adres van de firewall-NVA zijn (of de load balancer vóór de firewall-NVA's voor redundantie). De firewall NVA kan hetzelfde zijn als de SDWAN NVA in het bovenstaande diagram, of het kan een ander apparaat zijn, zoals Azure Firewall, omdat de SDWAN NVA routes kan adverteren met de volgende hop die verwijst naar andere IP-adressen. In het volgende diagram ziet u dit ontwerp met de toevoeging van Azure Firewall:

Dit ontwerp maakt automatische injectie van routes in spoke-VNets mogelijk zonder interferentie van andere routes die zijn geleerd vanuit ExpressRoute, VPN of een SDWAN-omgeving, en het toevoegen van firewall-NVA's voor verkeersinspectie.

Gerelateerde inhoud

• Meer informatie over ondersteuning voor Azure Route Server voor ExpressRoute en Azure VPN.
• Meer informatie over het configureren van peering tussen Azure Route Server en Virtueel netwerkapparaat.