VNet-peering og tjenestesluttpunkter

Ressurser i ulike Azure-VNet-er kan ikke kommunisere med hverandre som standard – selv om de befinner seg i samme Azure-region. Store organisasjoner har imidlertid ofte flere VNet-er: separate VNet-er for utvikling, testing og produksjon, eller ulike VNet-er for forskjellige avdelinger. VNet-peering kobler to VNet-er direkte gjennom Microsofts private backbone-nettverk. Dermed kan ressurser i begge VNet-ene kommunisere som om de var i samme nettverk – uten at trafikken går over det offentlige internett eller krever en VPN-gateway.

VNet-peering er en ikke-transitiv tilkobling: Hvis VNet A er paret med VNet B, og VNet B er paret med VNet C, kan ikke VNet A kommunisere med VNet C med mindre De oppretter en separat peering mellom A og C. Peering-koblinger er toveis, men må konfigureres på begge sider – det å opprette en peering fra A til B oppretter ikke automatisk en fra B til A. Når begge sider er konfigurert, bruker trafikken mellom de parede VNet-ene Azure-backbone-nettverket med lav ventetid og høy båndbredde, sammenlignbart med kommunikasjon mellom delnett i ett enkelt VNet.

VNet Peering har to alternativer for omfang: Local VNet Peering kobler sammen to VNet-er i den samme Azure-regionen. Trafikken forblir i regionen og medfører en liten overføringskostnad per GB. Global VNet Peering kobler sammen to VNet-er i ulike Azure-regioner, og trafikken rutes over Microsofts globale backbone. Dette gjør det mulig for ressurser i East US å kommunisere privat med ressurser i West Europe uten å gå via det offentlige internett. Global peering har noe høyere overføringskostnader enn lokal peering, men er fortsatt betydelig billigere og mer pålitelig enn ruting via et VPN.

Et vanlig mønster i virksomheter bruker VNet Peering til å implementere en hub-og-eiker-topologi. Et sentralt hub-VNet er vert for delte tjenester: Azure Firewall, VPN Gateway, DNS-servere og overvåking. Flere spoke-VNet-er, ett per miljø eller arbeidsbelastning, kobles sammen med huben gjennom peering. Ved å rute all trafikk fra eikene gjennom hub-brannmuren får organisasjonen sentralisert sikkerhetsinspeksjon uten kompleks NSG-administrasjon i hver eik. Siden peering ikke er transitiv, ruter hub-brannmuren trafikk mellom eikene ved hjelp av User-Defined Routes (UDRs).

VNet Peering har ett kritisk krav: adresseområdene til VNet-er som kobles sammen gjennom peering, må ikke overlappe. Hvis VNet A bruker 10.0.0.0/16 og VNet B også bruker 10.0.0.0/16, mislykkes peering fordi Azure ikke kan rute trafikk mellom identiske adresseområder. Derfor er det svært viktig å planlegge CIDR-områder som ikke overlapper, for alle VNet-er og lokale nettverk, før du begynner. Hvis du endrer adresseområdet til et VNet etter at ressurser er distribuert, må du opprette VNet-et på nytt eller bruke den begrensede funksjonen for å legge til eller fjerne adresseområder.

Service Endpoints utvider identiteten til VNet-et til Azure PaaS-tjenester som Azure Storage, Azure SQL Database, Azure Key Vault og Cosmos DB. Når du aktiverer et tjenesteendepunkt på et subnett, rutes trafikk fra ressurser i subnettet til den angitte Azure-tjenesten over Azure-backbone i stedet for over det offentlige internett, selv om tjenestens offentlige IP-adresse brukes. Tjenesten kan deretter begrense tilgangen til bare ressurser i VNet-er der tjenesteendepunktet er aktivert. Dette gir en betydelig sikkerhetsforbedring sammenlignet med endepunkter som er tilgjengelige fra internett.

Service Endpoints og Private Endpoints gir begge sikker tilgang til Azure PaaS-tjenester, men de fungerer på ulike måter: Service Endpoint – ruter trafikken over Azure-backbone, men bruker fortsatt tjenestens offentlige IP-adresse. Tjenesteendepunktet finnes på subnettnivå. Private Endpoint – tilordner tjenesten en privat IP-adresse fra VNet-et ditt. Det offentlige endepunktet kan deaktiveres helt, slik at tjenesten blir virkelig privat. Private Endpoints gir sterkere isolasjon og kan også nås fra lokale nettverk over VPN/ExpressRoute. For høyest sikkerhet foretrekkes Private Endpoints; Service Endpoints er et enklere og rimeligere alternativ.

Når du har aktivert et tjenesteendepunkt på et subnett, konfigurerer du Azure-tjenesten til å bare godta tilkoblinger fra dette subnettet. For en lagringskonto innebærer dette at du legger til en VNet-regel i brannmurinnstillingene for lagringskontoen. Etter denne endringen kan bare virtuelle maskiner i det angitte subnettet nå lagringskontoen – all annen internettrafikk nektes. Dette er en rask og kostnadsfri måte å forbedre sikkerheten for lagringskontoen betydelig på, sammenlignet med å la den være åpen for all internettrafikk, særlig for kontoer som inneholder sensitive applikasjonsdata.

VNet Integration, som er forskjellig fra VNet Peering, gjør det mulig for Azure App Service-applikasjoner å foreta utgående kall til ressurser inne i et VNet. Uten VNet Integration går utgående trafikk fra en App Service alltid via det offentlige internett, også når den kaller ressurser som Azure SQL eller Azure Cache for Redis i det samme VNet-et. Når VNet Integration er aktivert, rutes applikasjonens utgående trafikk inn i VNet-et, slik at den kan nå private ressurser. Dette krever et dedikert delegert subnett i VNet-et med et adresseområde på minst /28.

Ettersom VNet Peering ikke er transitiv, krever tilkobling av mer enn to VNet-er enten direkte peering mellom hvert par (O(n²)-kompleksitet) eller en sentral rutingshub. I en hub-og-eiker-modell inneholder hub-VNet-et en Network Virtual Appliance (NVA) eller Azure Firewall som fungerer som en transittruter mellom eiker-VNet-ene. Hver eik legger til en UDR som peker all trafikk (0.0.0.0/0 eller bestemte CIDR-områder for eikene) til NVA-ens IP-adresse i huben. NVA-en videresender deretter trafikken til riktig eik, og gir dermed i praksis transitiv tilkobling gjennom huben.

Viktige begrensninger ved VNet Peering: Adresseområder som ikke overlapper, er påkrevd – planlegg CIDR-områdene nøye før du oppretter VNet-er. Ikke-transitivt – peering mellom A og B samt B og C kobler ikke A og C sammen. Du kan ikke endre størrelsen på adresseområdet til et VNet hvis det har aktive peer-tilkoblinger, uten å slette dem midlertidig. Gateway transit – eike-VNet-er kan bruke VPN- eller ExpressRoute-gatewayen i hub-VNet-et ved å aktivere 'Use Remote Gateways' i peering-konfigurasjonen, men dette krever at hub-gatewayen er opprettet først. Det er viktig å forstå disse begrensningene når du utformer skalerbare og vedlikeholdbare arkitekturer med flere VNet-er.

I denne leksjonen lærte du at VNet Peering kobler sammen to VNet-er over Microsofts backbone for privat kommunikasjon med lav forsinkelse uten VPN, men at peering ikke er transitiv, at tjenesteendepunkter ruter subnetttrafikk til Azure PaaS-tjenester over backbone uten å eksponere den mot det offentlige internett, og at private endepunkter er det sikrere alternativet, fordi de tilordner en PaaS-tjeneste en privat IP-adresse slik at det offentlige endepunktet kan deaktiveres helt. Neste tema er det grunnleggende om Azure DNS og Load Balancer.