Azure-peering eller VPN fra VNet til VNet? Beslut før routing

Azure giver dig mindst to måder at forbinde to virtuelle netværk på, og de er ikke udskiftelige indstillinger på det samme objekt. Peering forbinder VNettene på Microsofts backbone uden en gateway; en VPN fra VNet til VNet sætter et IPsec-forhold mellem to gateways, som du implementerer, dimensionerer og overvåger. Beslutningen handler om tre betingelser, og hvis du ikke kan svare på alle tre, før du tilføjer en rute, er du ved at bygge en omvej til en model, du aldrig valgte.

Tre betingelser, der afgør modellen

Den første er, om noget i kravet har brug for en IPsec-grænse, som du ejer og kan pege på. Den anden er, om adresserummet er rent, og om de to VNet kun skal tale med hinanden. Den tredje er, hvem der ejer en eventuel transitvej og gatewayregningen. Svar i den rækkefølge, for den første kan udelukke peering, uanset hvor tillokkende den anden ser ud.

Det fælles for begge modeller er en hård adresseringsregel: VNettenes adresserum må ikke overlappe. Hverken peering eller en VPN fra VNet til VNet er en understøttet måde at gøre to identiske intervaller entydige på, og et overlap kræver et mapping-design eller et redesign, ikke en anden forbindelsestype.

Betingelse 1: har du brug for en IPsec-grænse, du ejer?

Peering fører trafik over Azures private backbone og kræver ikke en VPN-gateway for selve peerforbindelsen. Det er en udtalelse om transport, ikke en udtalelse om kryptering, du kan give en revisor som »vi kører IPsec«. Hvis kravet nævner en kundekonfigureret tunnel, en bestemt IKE-politik eller en grænse, der terminerer på udstyr, du kontrollerer, opfylder peering det ikke, uanset hvor privat backbonen er.

En VPN fra VNet til VNet giver netop den grænse: to gateways, et IPsec/IKE-forhold, delte nøgler og hele det operationelle overflade, der følger med. Du arver tunnelstatus, gatewaykapacitet, SKU-grænser og den overvågning, der beviser, at tunnelen er oppe. Det er det rigtige svar, når kravet netop handler om den grænse, som i peering-oversigten beskrives som en anden forbindelsestype end peering.

Vær lige så omhyggelig i den anden retning. »Vi har brug for kryptering mellem VNet« opfyldes ofte af arbejdsbyrdens egen TLS, og så er en gateway en udgift uden et krav bag sig. Skriv den sætning, revisoren skal læse, før du vælger mekanismen.

Betingelse 2: er topologien direkte, eller skal noget transitere?

Peering er ikke transitiv. To VNet, der er peered til et hub, er ikke dermed forbundet med hinanden, og en rute, der ser ud til at virke i én retning, er som regel en peering, der kun nåede Connected på den ene side. Begge sider skal findes, og begge skal vise Connected, og det er det første, du tjekker, når trafikken stille forsvinder.

Hvis kravet er adgang til det lokale netværk gennem et hub, er gateway-transit et separat design med bestemte roller: hubben ejer gatewayen, spoke-peeringen tillader gateway-transit, og spokeen skal tillade videresendt trafik. Det er egenskaber på peeringen, ikke automatiske konsekvenser af at forbinde VNettene:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

Den effektive rutetabel er det ærlige svar på »findes vejen?«. Den viser den næste hop-type, som platformen faktisk vil bruge, så en peering, der ser konfigureret ud, men ikke er forbundet, viser sig som en manglende eller forkert rute i stedet for et mysterium.

Betingelse 3: hvem ejer transitvejen og regningen?

Hvert ekstra hop har en ejer. Med peering betyder et nyt VNet et nyt peering-par i begge sider og, for transit, et hub, der fortsætter med at videresende trafik, og en rutetabel, der fortsat peger på det. Med en VPN betyder et nyt VNet endnu en gateway eller endnu en forbindelse på en eksisterende, med sit eget kapacitetsloft at holde øje med.

Omkostningen følger samme form, men ikke samme poster: peering-opkrævninger er forbindelse og dataoverførsel, mens en VPN tilføjer gatewaytimer og sine egne overførselsomkostninger. Sammenlign totalen for den topologi, du faktisk vil køre i et år, inklusive den anden tunnel og overvågningen, ikke prisen for én forbindelse i dag. Medtag det arbejde, ingen fakturerer: nogen skal rotere nøgler, holde øje med tunnelstatus og svare på alarmen klokken tre om natten, når en gateway genstarter. Den post er som regel det, der afgør diskussionen, fordi den er den eneste, der aldrig optræder i et tilbud.

Uanset hvad du vælger, test tre flows: det tilsigtede, et afvist der skal forblive afvist, og det tilfælde hvor hub-gatewayen eller en peering er nede. En model, der kun forklarer den glade vej, er ikke verificeret, den er demonstreret.

Verificer valget mod dets egen påstand

Skriv én sætning, der navngiver modellen, grænsen og ejeren, og kontroller derefter, at den udrullede tilstand svarer til den. For peering betyder det, at begge peering-tilstande er Connected, at den effektive rute viser peering som næste hop for destinationspræfikset, og at der ikke er nogen gateway på vejen. For en VPN fra VNet til VNet betyder det, at begge forbindelser er Connected, at nøgler og politikker stemmer på begge gateways, og at ruten har den virtuelle netværksgateway som næste hop.

Hvis kontrollerne er uenige med sætningen, så ret sætningen først. Det meste forvirring i disse designs kommer fra en hybrid, ingen har beskrevet: en peering til arbejdsbyrdens undernet, en VPN til én gammel tjeneste og en rutetabel, der stille foretrækker en af dem.