Azure-peering eller VPN fra VNet til VNet? Bestem før ruting

Azure gir deg minst to måter å koble to virtuelle nettverk på, og de er ikke utskiftbare innstillinger på samme objekt. Peering kobler VNet-ene på Microsofts stamnett uten gateway; en VPN fra VNet til VNet setter en IPsec-relasjon mellom to gatewayer som du distribuerer, dimensjonerer og overvåker. Beslutningen koker ned til tre betingelser, og hvis du ikke kan svare på alle tre før du legger til en rute, er du i ferd med å bygge en omvei for en modell du aldri valgte.

Tre betingelser som avgjør modellen

Den første er om noe i kravet trenger en IPsec-grense som du eier og kan peke på. Den andre er om adresserommene er rene og de to VNet-ene bare trenger å snakke sammen. Den tredje er hvem som eier en eventuell transitvei og gateway-regningen. Svar i den rekkefølgen, for den første kan utelukke peering uansett hvor attraktiv den andre ser ut.

Det begge modellene deler, er en hard adresseringsregel: VNet-enes adresserom må ikke overlappe. Verken peering eller en VPN fra VNet til VNet er en støttet måte å gjøre to identiske områder entydige på, og en overlapp krever et mapping-design eller en redesign, ikke en annen tilkoblingstype.

Betingelse 1: trenger du en IPsec-grense som du eier?

Peering fører trafikk over Azures private stamnett og krever ikke en VPN-gateway for selve peered-forbindelsen. Det er en uttalelse om transport, ikke en uttalelse om kryptering du kan gi en revisor som «vi kjører IPsec». Hvis kravet navngir en kundekonfigurert tunnel, en bestemt IKE-policy eller en grense som terminerer på utstyr du kontrollerer, oppfyller peering det ikke, uansett hvor privat stamnettet er.

En VPN fra VNet til VNet gir nettopp den grensen: to gatewayer, en IPsec/IKE-relasjon, delte nøkler og hele det operative overflaten som følger med. Du arver tunnelstatus, gateway-kapasitet, SKU-grenser og overvåkingen som beviser at tunnelen er oppe. Det er det riktige svaret når kravet nettopp handler om den grensen, som i peering-oversikten beskrives som en annen tilkoblingstype enn peering.

Vær like nøye i den andre retningen. «Vi trenger kryptering mellom VNet-ene» oppfylles ofte av arbeidsmengdens egen TLS, og da er en gateway en kostnad uten krav bak. Skriv setningen revisoren skal lese før du velger mekanismen.

Betingelse 2: er topologien direkte, eller må noe transitere?

Peering er ikke transitiv. To VNet-er som er peered til et hub, er ikke dermed koblet til hverandre, og en rute som ser ut til å virke i én retning, er som regel en peering som bare nådde Connected på den ene siden. Begge sider må finnes, og begge må vise Connected, og det er det første du sjekker når trafikken stille forsvinner.

Hvis kravet er tilgang til det lokale nettet gjennom et hub, er gateway-transit et eget design med bestemte roller: huben eier gatewayen, spoke-peeringen tillater gateway-transit, og spoken må tillate videresendt trafikk. Det er egenskaper på peeringen, ikke automatiske konsekvenser av å koble VNet-ene:

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 rutetabellen er det ærlige svaret på «finnes veien?». Den viser typen neste hopp som plattformen faktisk vil bruke, så en peering som ser konfigurert ut men ikke er koblet til, vises som en manglende eller feil rute i stedet for et mysterium.

Betingelse 3: hvem eier transitveien og regningen?

Hvert ekstra hopp har en eier. Med peering betyr et nytt VNet et nytt peering-par på begge sider og, for transit, et hub som fortsetter å videresende trafikk og en rutetabell som fortsatt peker på det. Med en VPN betyr et nytt VNet en annen gateway eller en annen tilkobling på en eksisterende, med sin egen kapasitetstak å holde øye med.

Kostnaden følger samme form, men ikke samme poster: peering-avgifter er tilkobling og dataoverføring, mens en VPN legger til gateway-timer og egne overføringsavgifter. Sammenlign totalen for topologien du faktisk vil kjøre i et år, inkludert den andre tunnelen og overvåkingen, ikke prisen for én tilkobling i dag. Ta med arbeidet ingen fakturerer: noen må rotere nøkler, følge tunnelstatus og svare på alarmen klokken tre om natten når en gateway starter på nytt. Den posten er som regel det som avgjør diskusjonen, fordi den er den eneste som aldri dukker opp i et tilbud.

Uansett hva du velger, test tre flyter: den tiltenkte, en avvist som skal forbli avvist, og tilfellet der hub-gatewayen eller en peering er nede. En modell som bare forklarer den lykkelige veien, er ikke verifisert, den er demonstrert.

Verifiser valget mot dets egen påstand

Skriv én setning som navngir modellen, grensen og eieren, og kontroller deretter at den utrullede tilstanden passer med den. For peering betyr det at begge peering-tilstandene er Connected, at den effektive ruten viser peering som neste hopp for destinasjonsprefikset, og at det ikke er noen gateway på veien. For en VPN fra VNet til VNet betyr det at begge tilkoblingene er Connected, at nøkler og policyer stemmer på begge gatewayene, og at ruten har den virtuelle nettverksgatewayen som neste hopp.

Hvis kontrollene er uenige med setningen, rett setningen først. Det meste av forvirringen i disse designene kommer fra en hybrid ingen har beskrevet: en peering for arbeidsmengdens subnett, en VPN for én gammel tjeneste og en rutetabell som stille foretrekker en av dem.