Standardruttinmatning i virtuella ekernätverk
En av de vanligaste arkitekturerna i Azure är nav- och ekerdesignen, där arbetsbelastningar som distribueras i ett virtuellt ekernätverk (VNet) skickar trafik via delade nätverksenheter som finns i det virtuella hubbnätverket. Användardefinierade vägar (UDR) måste vanligtvis konfigureras i de virtuella ekernätverken för att styra trafiken mot säkerhetsenheter i hubben. Den här designen kräver dock att administratörer hanterar dessa vägar över många ekrar.
Azure Route Server erbjuder en centraliserad punkt där virtuella nätverksinstallationer (NVA) kan annonsera vägar som matas in i de virtuella ekernätverken. På så sätt behöver administratörer inte skapa och uppdatera routningstabeller i virtuella ekernätverk.
Topologi
Följande diagram visar en enkel hubb- och ekerdesign med ett virtuellt hubbnätverk och två virtuella ekernätverk. I hubben har en virtuell nätverksinstallation och en routningsserver distribuerats. Utan routningsservern måste användardefinierade vägar konfigureras i varje eker. Dessa UDF:er innehåller vanligtvis en standardväg för 0.0.0.0/0 som skickar all trafik från de virtuella ekernätverken via NVA. Det här scenariot kan till exempel användas för att inspektera trafiken i säkerhetssyfte.
Med routningsservern i det virtuella hubbnätverket behöver du inte använda användardefinierade vägar. NVA annonserar nätverksprefix till routningsservern, som matar in dem så att de visas i de effektiva vägarna för alla virtuella datorer som distribueras i det virtuella hubbnätverket eller eker-VNet som är peer-kopplade till det virtuella hubbnätverket med inställningen Använd det virtuella fjärrnätverkets gateway eller routningsserver.
Anslutning till lokal plats via NVA
Om NVA används för att tillhandahålla anslutning till det lokala nätverket via IPsec VPN eller SD-WAN-teknik kan samma mekanism användas för att locka trafik från ekrarna till NVA. Dessutom kan NVA dynamiskt lära sig Azure-prefixen från Azure Route Server och annonsera dem med ett dynamiskt routningsprotokoll till lokalt. Följande diagram beskriver den här konfigurationen:
Inspektera privat trafik via NVA
I föregående avsnitt visas den trafik som inspekteras av den virtuella nätverksinstallationen (NVA) genom att mata in en 0.0.0.0/0 standardväg från NVA till routningsservern. Men om du bara vill inspektera eker-till-eker- och eker-till-lokal trafik via NVA bör du tänka på att Azure Route Server inte annonserar en väg som är samma eller längre prefix än det virtuella nätverksadressutrymme som lärts från NVA. Med andra ord kommer Azure Route Server inte att mata in dessa prefix i det virtuella nätverket och de kommer inte att programmeras på nätverkskorten för virtuella datorer i de virtuella hubb- eller ekernätverken.
Azure Route Server annonserar dock ett större undernät än det VNet-adressutrymme som har lärts från NVA. Det är möjligt att annonsera från NVA ett supernät av det du har i ditt virtuella nätverk. Om ditt virtuella nätverk till exempel använder RFC 1918-adressutrymmet 10.0.0.0/16kan din NVA annonsera 10.0.0.0/8 till Azure Route Server och dessa prefix matas in i de virtuella hubb- och ekernätverken. Det här VNet-beteendet refereras i Om BGP med VPN Gateway.
Viktigt!
Om du har ett scenario där prefix med samma längd annonseras från ExpressRoute och NVA föredrar Och programmerar Azure de vägar som lärts från ExpressRoute. Mer information finns i nästa avsnitt.
Anslutning till lokal plats via virtuella nätverksgatewayer
Om det finns en VPN- eller ExpressRoute-gateway i samma virtuella nätverk som routningsservern och NVA för att tillhandahålla anslutning till lokala nätverk, programmeras även vägar som de här gatewayerna har lärt sig i de virtuella ekernätverken. Dessa vägar åsidosätter standardvägen (0.0.0.0/0) som matas in av routningsservern, eftersom de skulle vara mer specifika (längre nätverksmasker). I följande diagram beskrivs den tidigare designen, där en ExpressRoute-gateway har lagts till.
Du kan inte konfigurera undernäten i de virtuella ekernätverken så att de bara lär sig vägarna från Azure Route Server. Om du inaktiverar "Sprid gatewayvägar" i en routningstabell som är associerad med ett undernät förhindrar du att båda typerna av vägar (vägar från den virtuella nätverksgatewayen och vägarna från Azure Route Server) matas in i nätverkskort i undernätet.
Som standard annonserar Routningsservern alla prefix som har lärts från NVA till ExpressRoute också. Detta kanske inte är önskvärt, till exempel på grund av routningsgränserna för ExpressRoute eller själva routningsservern. I så fall kan NVA meddela sina vägar till routningsservern, inklusive BGP-communityn no-advertise (med värdet 65535:65282). När Route Server tar emot vägar med den här BGP-communityn matas de in i undernäten, men de annonseras inte till andra BGP-peer-datorer (till exempel ExpressRoute eller VPN-gatewayer eller andra NVA:er).
SDWAN-samexistens med ExpressRoute och Azure Firewall
Ett särskilt fall av den tidigare designen är när kunder infogar Azure Firewall i trafikflödet för att inspektera all trafik som går till lokala nätverk, antingen via ExpressRoute eller via SD-WAN/VPN-enheter. I den här situationen har alla ekerundernät routningstabeller som hindrar ekrarna från att lära sig någon väg från ExpressRoute eller routningsservern och har standardvägar (0.0.0.0/0) med Azure Firewall som nästa hopp, som följande diagram visar:
Azure Firewall-undernätet lär sig vägarna som kommer från både ExpressRoute och VPN/SDWAN NVA och bestämmer om trafik ska skickas på ett eller annat sätt. Enligt beskrivningen i föregående avsnitt, om NVA-installationen annonserar fler än 1 000 vägar till routningsservern, bör den skicka sina BGP-vägar markerade med BGP-communityn no-advertise. På så sätt matas inte SDWAN-prefixen tillbaka till lokalt via Express-Route.
Trafiksymmetri
Om flera NVA-instanser används i ett aktivt/aktivt scenario för bättre återhämtning eller skalbarhet är trafiksymmetri ett krav om nva:erna behöver behålla anslutningarnas tillstånd. Detta gäller till exempel nästa generations brandväggar.
- För anslutning från virtuella Azure-datorer till det offentliga Internet använder NVA källnätverksadressöversättning (SNAT) så att utgående trafik kommer att hämtas från NVA:ns offentliga IP-adress och därmed uppnå trafiksymmetri.
- För inkommande trafik från Internet till arbetsbelastningar som körs på virtuella datorer, utöver målnätverksadressöversättning (DNAT), måste de virtuella nätverksinstallationerna utföra källnätverksadressöversättning (SNAT) för att säkerställa att returtrafiken från de virtuella datorerna hamnar på samma NVA-instans som bearbetade det första paketet.
- Eftersom den virtuella källdatorn tar routningsbeslutet oberoende av målet krävs SNAT idag för att uppnå trafiksymmetri för Azure-till-Azure-anslutningen.
Flera NVA-instanser kan även distribueras i en aktiv/passiv installation, till exempel om en av dem annonserar sämre vägar (med en längre AS-sökväg) än den andra. I det här fallet matar Azure Route Server bara in den önskade vägen i de virtuella virtuella VNet-datorerna, och den mindre föredragna vägen används bara när den primära NVA-instansen slutar annonsera via BGP.
Olika routningsservrar för att annonsera vägar till virtuella nätverksgatewayer och till virtuella nätverk
Som föregående avsnitt har visat har Azure Route Server en dubbel roll:
- Den lär sig och annonserar vägar till/från virtuella nätverksgatewayer (VPN och ExpressRoute)
- Den konfigurerar inlärda vägar i sitt virtuella nätverk och på direkt peer-kopplade virtuella nätverk
Den här dubbla funktionen är ofta intressant, men ibland kan det vara skadligt för vissa krav. Om routningsservern till exempel distribueras i ett virtuellt nätverk med en NVA som annonserar en 0.0.0.0/0-väg och en ExpressRoute-gateway som annonserar prefix lokalt, konfigureras alla vägar (både 0.0.0.0.0/0 från NVA och de lokala prefixen) på de virtuella datorerna i det virtuella nätverket och direkt peerkopplade virtuella nätverk. Eftersom de lokala prefixen därför är mer specifika än 0.0.0.0/0 kringgår trafiken mellan den lokala miljön och Azure NVA. Om detta inte är önskvärt har de föregående avsnitten i den här artikeln visat hur du inaktiverar BGP-spridning i de virtuella datorundernäten och konfigurerar UDR.
Det finns dock en alternativ, mer dynamisk metod. Det är möjligt att använda olika Azure Route-servrar för olika funktioner: en av dem ansvarar för att interagera med de virtuella nätverksgatewayerna och den andra för att interagera med den virtuella nätverksroutningen. Följande diagram visar en möjlig design för detta:
Route Server 1 i hubben används för att mata in prefixen från SDWAN i ExpressRoute. Eftersom de virtuella ekernätverken peerkopplas med det virtuella hubbnätverket utan använd det virtuella fjärrnätverkets gateway eller routningsserver (i peering för eker-VNet) och Använd det här virtuella nätverkets gateway eller routningsserver (gatewayöverföring i hubbens VNet-peering) lär sig de virtuella ekernätverken inte dessa vägar (varken SDWAN-prefixen eller ExpressRoute-prefixen).
För att sprida vägar till de virtuella ekernätverken använder NVA Route Server 2, som distribueras i ett nytt extra virtuellt nätverk. NVA sprider bara en enda 0.0.0.0/0 väg till Route Server 2. Eftersom de virtuella ekernätverken peerkopplas med det här extra virtuella nätverket med Använd det virtuella fjärrnätverkets gateway eller routningsserver (i eker-VNet-peering) och Använd det här virtuella nätverkets gateway eller routningsserver (gatewayöverföring i hubbens VNet-peering) 0.0.0.0/0 kommer vägen att läras av alla virtuella datorer i ekrarna.
Nästa hopp för 0.0.0.0/0 vägen är NVA, så de virtuella ekernätverken måste fortfarande vara peer-kopplade till det virtuella hubbnätverket. En annan viktig aspekt att observera är att det virtuella hubbnätverket måste peerkopplas till det virtuella nätverk där Route Server 2 distribueras, annars kan det inte skapa BGP-angränsande.
Om trafik från ExpressRoute till de virtuella ekernätverken ska skickas till en brandväggs-NVA för inspektion krävs fortfarande en routningstabell i GatewaySubnet, annars skickar den virtuella ExpressRoute-nätverksgatewayen paket till de virtuella datorerna med hjälp av de vägar som lärts från VNet-peering. Vägarna i den här routningstabellen ska matcha ekerprefixen och nästa hopp ska vara IP-adressen för brandväggens NVA (eller lastbalanseraren framför brandväggens NVA:er för redundans). Brandväggens NVA kan vara samma som SDWAN NVA i diagrammet ovan, eller så kan det vara en annan enhet, till exempel Azure Firewall, eftersom SDWAN NVA kan annonsera vägar med nästa hopp som pekar på andra IP-adresser. Följande diagram visar den här designen med tillägget av Azure Firewall:
Kommentar
För all trafik från en lokal plats som är avsedd för privata slutpunkter kringgår den här trafiken brandväggens NVA eller Azure Firewall i hubben. Detta resulterar dock i asymmetrisk routning (vilket kan leda till förlust av anslutning mellan lokala och privata slutpunkter) eftersom privata slutpunkter vidarebefordrar lokal trafik till brandväggen. För att säkerställa routningssymmetri, aktivera nätverkspolicyer för routningstabeller för privata slutpunkter på de undernät där privata slutpunkter är distribuerade.
Den här designen möjliggör automatisk inmatning av vägar i eker-VNet utan interferens från andra vägar som lärts från ExpressRoute, VPN eller en SDWAN-miljö och tillägg av brandväggs-NVA:er för trafikinspektion.