Azure-peering eller VPN frå VNet til VNet? Avgjer før ruting

Azure gir deg minst to måtar å kople to virtuelle nettverk på, og dei er ikkje utskiftbare innstillingar på same objekt. Peering koplar VNet-ane på stamnettet til Microsoft utan gateway; ein VPN frå VNet til VNet set ein IPsec-relasjon mellom to gatewayar som du distribuerer, dimensjonerer og overvakar. Avgjerda kokar ned til tre vilkår, og om du ikkje kan svare på alle tre før du legg til ei rute, er du i ferd med å byggje ein omveg for ein modell du aldri valde.

Tre vilkår som avgjer modellen

Det første er om noko i kravet treng ei IPsec-grense som du eig og kan peike på. Det andre er om adresseromma er reine og dei to VNet-ane berre treng å snakke saman. Det tredje er kven som eig ein eventuell transitveg og gateway-rekninga. Svar i den rekkjefølgja, for den første kan utelukke peering uansett kor attraktiv den andre ser ut.

Det begge modellane deler, er ei hard adresseringsregel: adresseromma til VNet-ane må ikkje overlappe. Korkje peering eller ein VPN frå VNet til VNet er ein støtta måte å gjere to identiske område eintydige på, og ein overlapp krev eit mapping-design eller ei ny utforming, ikkje ein annan tilkoplings type.

Vilkår 1: treng du ei IPsec-grense som du eig?

Peering fører trafikk over det private stamnettet til Azure og krev ikkje ein VPN-gateway for sjølve peered-tilkoplinga. Det er ei utsegn om transport, ikkje ei utsegn om kryptering du kan gje ein revisor som «vi køyrer IPsec». Om kravet nemner ein kundekonfigurert tunnel, ein bestemt IKE-policy eller ei grense som terminerer på utstyr du kontrollerer, oppfyller peering det ikkje, uansett kor privat stamnettet er.

Ein VPN frå VNet til VNet gir nettopp den grensa: to gatewayar, ein IPsec/IKE-relasjon, delte nøklar og heile den operative flata som følgjer med. Du arvar tunnelstatus, gateway-kapasitet, SKU-grenser og overvakinga som provar at tunnelen er oppe. Det er det rette svaret når kravet nettopp handlar om den grensa, som i peering-oversynet er skildra som ein annan tilkoplingstype enn peering.

Ver like nøye i den andre retninga. «Vi treng kryptering mellom VNet-ane» blir ofte oppfylt av eigen TLS i arbeidsmengda, og då er ein gateway ein kostnad utan krav bak. Skriv setninga revisoren skal lese før du vel mekanismen.

Vilkår 2: er topologien direkte, eller må noko transittere?

Peering er ikkje transitiv. To VNet som er peered til ein hub, er ikkje dermed kopla til kvarandre, og ei rute som ser ut til å verke i éi retning, er som regel ein peering som berre nådde Connected på den eine sida. Begge sider må finnast, og begge må vise Connected, og det er det første du sjekkar når trafikken stille forsvinn.

Om kravet er tilgang til det lokale nettet gjennom ein hub, er gateway-transit eit eige design med bestemte roller: huben eig gatewayen, spoke-peeringen tillèt gateway-transit, og spoken må tillète videresend trafikk. Det er eigenskapar på peeringen, ikkje automatiske følgjer av å kople VNet-ane:

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 ærlege svaret på «finst vegen?». Han viser typen neste hopp som plattforma faktisk vil bruke, så ein peering som ser konfigurert ut men ikkje er kopla til, viser seg som ei manglande eller feil rute i staden for eit mysterium.

Vilkår 3: kven eig transitvegen og rekninga?

Kvar ekstra hopp har ein eigar. Med peering tyder eit nytt VNet eit nytt peering-par på begge sider og, for transit, ein hub som held fram med å videresende trafikk og ein rutetabell som framleis peikar på han. Med ein VPN tyder eit nytt VNet ein annan gateway eller ei anna tilkopling på ein eksisterande, med sitt eige kapasitetstak å halde auge med.

Kostnaden følgjer same form, men ikkje same postar: peering-avgifter er tilkopling og dataoverføring, medan ein VPN legg til gateway-timar og eigne overføringsavgifter. Samanlikn totalen for topologien du faktisk vil køyre i eit år, inkludert den andre tunnelen og overvakinga, ikkje prisen for éi tilkopling i dag. Ta med arbeidet ingen fakturerer: nokon må rotere nøklar, følgje tunnelstatus og svare på alarmen klokka tre om natta når ein gateway startar på nytt. Den posten er som regel det som avgjer diskusjonen, fordi han er den einaste som aldri dukkar opp i eit tilbod.

Uansett kva du vel, test tre flytar: den tiltenkte, ein avvist som skal halde fram å vere avvist, og tilfellet der hub-gatewayen eller ein peering er nede. Ein modell som berre forklarer den lukkelege vegen, er ikkje verifisert, han er demonstrert.

Verifiser valet mot påstanden hans eigen

Skriv éi setning som nemner modellen, grensa og eigaren, og kontroller deretter at den utrulla tilstanden passar med henne. For peering tyder det at begge peering-tilstandane er Connected, at den effektive ruta viser peering som neste hopp for destinasjonsprefikset, og at det ikkje er nokon gateway på vegen. For ein VPN frå VNet til VNet tyder det at begge tilkoplingane er Connected, at nøklar og policyar stemmer på begge gatewayane, og at ruta har den virtuelle nettverksgatewayen som neste hopp.

Om kontrollane er usamde med setninga, rett setninga først. Det meste av forvirringa i desse designa kjem frå ein hybrid ingen har skildra: ein peering for subnettet til arbeidsmengda, ein VPN for éin gamal teneste og ein rutetabell som stille føretrekkjer ein av dei.