VNet-peering och tjänstslutpunkter

Resurser i olika Azure-VNet kan inte kommunicera med varandra som standard — även om de finns i samma Azure-region. Stora organisationer har dock ofta flera VNet: separata VNet för utveckling, test och produktion eller olika VNet för olika avdelningar. VNet Peering ansluter två VNet direkt via Microsofts privata stamnät, så att resurser i båda VNet kan kommunicera som om de fanns i samma nätverk — utan att någon trafik går över det offentliga internet eller kräver en VPN-gateway.

VNet Peering är en icke-transitiv anslutning: om VNet A är peer-kopplat med VNet B och VNet B är peer-kopplat med VNet C kan VNet A inte kommunicera med VNet C om Ni inte skapar en separat peering mellan A och C. Peeringlänkar är dubbelriktade, men måste konfigureras på båda sidor — om Ni skapar en peering från A till B skapas inte automatiskt en från B till A. När båda sidorna har konfigurerats använder trafiken mellan de peer-kopplade VNet Azure-stamnätet, med låg svarstid och hög bandbredd som kan jämföras med kommunikation mellan undernät inom ett enda VNet.

VNet Peering har två omfångsalternativ: Local VNet Peering ansluter två VNets i samma Azure-region. Trafiken stannar inom regionen och medför en mindre överföringsavgift per GB. Global VNet Peering ansluter två VNets i olika Azure-regioner och dirigerar trafiken via Microsofts globala stamnät. Det gör att resurser i East US kan kommunicera privat med resurser i West Europe utan att trafiken passerar det offentliga internet. Global peering har en något högre överföringskostnad än lokal peering, men är fortfarande betydligt billigare och tillförlitligare än att dirigera trafiken via ett VPN.

Ett vanligt mönster i företag använder VNet Peering för att implementera en hub-and-spoke-topologi. Ett centralt hub-VNet tillhandahåller delade tjänster: Azure Firewall, VPN Gateway, DNS-servrar och övervakning. Flera spoke-VNets, ett per miljö eller arbetsbelastning, peer-kopplas med hubben. Genom att dirigera all trafik från spoke-nätverken via hubbens brandvägg får organisationen centraliserad säkerhetsinspektion utan komplex NSG-hantering i varje spoke. Eftersom peering inte är transitiv dirigerar hubbens brandvägg trafik mellan spoke-nätverken med hjälp av User-Defined Routes (UDRs).

VNet Peering har ett kritiskt krav: adressutrymmena för VNets som peer-kopplas får inte överlappa. Om VNet A använder 10.0.0.0/16 och VNet B också använder 10.0.0.0/16 misslyckas peering, eftersom Azure inte kan dirigera trafik mellan identiska adressintervall. Därför är det viktigt att planera icke-överlappande CIDR-intervall för alla VNets – och för lokala nätverk – innan arbetet påbörjas. Om ett VNets adressutrymme ändras efter att resurser har distribuerats måste VNet-nätverket återskapas, eller så måste den begränsade funktionen för att lägga till eller ta bort adressutrymme användas.

Service Endpoints utökar VNet-nätverkets identitet till Azure PaaS-tjänster som Azure Storage, Azure SQL Database, Azure Key Vault och Cosmos DB. När en service endpoint aktiveras på ett subnät dirigeras trafik från resurser i subnätet till den angivna Azure-tjänsten via Azure-stamnätet i stället för via det offentliga internet – även om tjänstens offentliga IP-adress används. Tjänsten kan därefter begränsa åtkomsten till endast resurser i VNets där service endpoint har aktiverats, vilket ger en betydande säkerhetsförbättring jämfört med endpoints som är åtkomliga via internet.

Service Endpoints och Private Endpoints ger båda säker åtkomst till Azure PaaS-tjänster, men fungerar på olika sätt: Service Endpoint – dirigerar trafik via Azure-stamnätet men använder fortfarande tjänstens offentliga IP-adress; service endpoint finns på subnätsnivå. Private Endpoint – tilldelar tjänsten en privat IP-adress från VNet-nätverket; den offentliga endpointen kan inaktiveras helt, vilket gör tjänsten verkligt privat. Private Endpoints ger starkare isolering och kan även nås från lokala nätverk via VPN/ExpressRoute. För högsta säkerhet föredras Private Endpoints; Service Endpoints är ett enklare och billigare alternativ.

När en Service Endpoint har aktiverats på ett subnät konfigureras Azure-tjänsten så att den endast accepterar anslutningar från det subnätet. För ett storage account innebär det att en VNet-regel läggs till i storage accountets brandväggsinställningar. Efter denna ändring kan endast virtuella datorer i det angivna subnätet nå storage accountet – all annan internettrafik nekas. Detta är ett snabbt och kostnadsfritt sätt att avsevärt förbättra säkerheten för ett storage account jämfört med att lämna det öppet för all internettrafik, särskilt för konton som innehåller känsliga programdata.

VNet Integration (som skiljer sig från VNet Peering) gör det möjligt för Azure App Service-program att göra utgående anrop till resurser i ett VNet. Utan VNet Integration går utgående trafik från en App Service alltid ut via det offentliga internet – även när den anropar resurser som Azure SQL eller Azure Cache for Redis i samma VNet. När VNet Integration är aktiverat dirigeras programmets utgående trafik in i VNet-nätverket och kan nå privata resurser. Detta kräver ett dedikerat delegerat subnät i VNet-nätverket med ett adressutrymme på minst /28.

Eftersom VNet Peering inte är transitiv krävs antingen direkt peering mellan varje par av VNets (O(n²)-komplexitet) eller en central routningshubb när fler än två VNets ska anslutas. I en hub-and-spoke-modell innehåller hubbens VNet en Network Virtual Appliance (NVA) eller Azure Firewall som fungerar som en transitrouter mellan spoke-nätverken. Varje spoke lägger till en UDR som pekar all trafik (0.0.0.0/0 eller specifika spoke-CIDR-intervall) till NVA:ns IP-adress i hubben. NVA:n vidarebefordrar sedan trafiken till rätt destinationsspoke, vilket i praktiken ger transitiv anslutning via hubben.

Viktiga begränsningar för VNet Peering: Icke-överlappande adressutrymmen krävs – planera CIDR-intervallen noggrant innan VNets skapas. Inte transitiv – peering mellan A-B och B-C ansluter inte A-C. Ett VNets adressutrymme kan inte ändras om det har aktiva peer-kopplingar utan att dessa tillfälligt tas bort. Gateway transit – spoke-VNets kan använda VPN- eller ExpressRoute-gatewayen i hubbens VNet genom att aktivera Use Remote Gateways i peering-konfigurationen, men då måste hubbens gateway skapas först. Det är viktigt att förstå dessa begränsningar när skalbara och lättunderhållna arkitekturer med flera VNets utformas.

I den här lektionen har ni lärt er att: VNet Peering ansluter två VNets via Microsofts stamnät för privat kommunikation med låg fördröjning utan VPN, men peering är inte transitiv, service endpoints dirigerar trafik från subnät till Azure PaaS-tjänster via stamnätet utan att exponera den mot det offentliga internet, och private endpoints är det starkare alternativet eftersom de tilldelar en PaaS-tjänst en privat IP-adress, vilket gör att den offentliga endpointen kan inaktiveras helt. Härnäst går vi igenom grunderna i Azure DNS och Load Balancer.