Azure-peering of VNet-tot-VNet-VPN? Besluit voor jy roetes byvoeg

Azure bied jou minstens twee maniere om twee virtuele netwerke te verbind, en dit is nie verwisselbare instellings op dieselfde objek nie. Peering verbind die VNets op Microsoft se ruggraat sonder 'n gateway; 'n VNet-tot-VNet-VPN plaas 'n IPsec-verhouding tussen twee gateways wat jy ontplooi, dimensioneer en monitor. Die besluit kom neer op drie voorwaardes, en as jy nie al drie kan antwoord voordat jy 'n roete byvoeg nie, is jy op die punt om 'n workaround te bou vir 'n model wat jy nooit gekies het nie.

Drie voorwaardes wat die model bepaal

Die eerste is of enigiets in die vereiste 'n IPsec-grens nodig het wat jy besit en kan aanwys. Die tweede is of die adresruimtes skoon is en die twee VNets net met mekaar hoef te praat. Die derde is wie die eienaar is van enige transitiwiteitsroete en van die gateway-rekening. Beantwoord hulle in daardie volgorde, want die eerste een kan peering uitskakel maak nie saak hoe aantreklik die tweede lyk nie.

Wat albei modelle deel, is 'n harde adresseringsreël: die VNet-adresruimtes mag nie oorvleuel nie. Nie peering nie en ook nie 'n VNet-tot-VNet-VPN is 'n ondersteunde manier om twee identiese reekse ondubbelsinnig te maak nie, en 'n oorvleueling vereis 'n karteringsontwerp of 'n herontwerp eerder as 'n ander verbindingstipe.

Voorwaarde 1: het jy 'n IPsec-grens nodig wat jy besit?

Peering dra verkeer oor Azure se private ruggraat en vereis nie 'n VPN-gateway vir die peering-verbinding self nie. Dit is 'n stelling oor vervoer, nie 'n stelling oor enkripsie wat jy aan 'n ouditeur kan sê as 'ons gebruik IPsec' nie. As die vereiste 'n kliënt-gekonfigureerde tonnel, 'n spesifieke IKE-beleid of 'n grens noem wat op toerusting eindig wat jy beheer, dan voldoen peering nie daaraan nie, hoe privaat die ruggraat ook al is.

'n VNet-tot-VNet-VPN verskaf wel daardie grens: twee gateways, 'n IPsec/IKE-verhouding, gedeelde sleutels en die hele operasionele oppervlak wat daarmee saamkom. Jy erf tonneltoestand, gateway-kapasiteit, SKU-limiete en die monitering wat bewys die tonnel is op. Dit is die korrekte antwoord wanneer die vereiste spesifiek oor daardie grens gaan, wat in die peering-oorsig beskryf word as 'n verbindingstipe wat van peering verskil.

Wees ewe versigtig in die ander rigting. 'Ons het enkripsie tussen VNets nodig' word dikwels bevredig deur die werklaag se eie TLS, en dan is 'n gateway 'n koste sonder enige vereiste daaragter. Skryf die sin wat die ouditeur sal lees voordat jy die meganisme kies.

Voorwaarde 2: is die topologie direk, of moet iets transiteer?

Peering is nie transitiief nie. Twee VNets wat aan 'n hub gepeer is, is daardeur nie aan mekaar verbind nie, en 'n roete wat in een rigting werk, is gewoonlik 'n peering wat net aan een kant Connected bereik het. Albei kante moet bestaan en albei moet Connected wys, en dit is die eerste ding om te kontroleer wanneer verkeer stilweg verdwyn.

As die vereiste on-premises bereikbaarheid deur 'n hub is, is gateway-transit 'n aparte ontwerp met spesifieke rolle: die hub besit die gateway, die spoke-peering laat gateway-transit toe, en die spoke moet deurgevoerde verkeer toelaat. Dit is eienskappe op die peering, nie outomatiese gevolge van die verbinding van die VNets nie:

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

Die effektiewe roetetabel is die eerlike antwoord op 'bestaan die pad?'. Dit wys die tipe volgende sprong wat die platform werklik sal gebruik, so 'n peering wat opgestel lyk maar nie gekoppel is nie, verskyn as 'n ontbrekende of verkeerde roete eerder as 'n raaisel.

Voorwaarde 3: wie besit die transitiwiteitsroete en die rekening?

Elke bykomende sprong het 'n eienaar. Met peering beteken 'n nuwe VNet 'n nuwe peering-paar aan albei kante en, vir transito, 'n hub wat aanhou verkeer aanstuur en 'n roetetabel wat aanhou daarop wys. Met 'n VPN beteken 'n nuwe VNet nog 'n gateway of nog 'n verbinding op 'n bestaande een, met sy eie kapasiteitsplafon om dop te hou.

Koste volg dieselfde vorm maar nie dieselfde lynitems nie: peering-heffings is verbinding en data-oordrag, terwyl 'n VPN gateway-ure en sy eie oordragheffings byvoeg. Vergelyk die totaal vir die topologie wat jy werklik vir 'n jaar sal bedryf, insluitend die tweede tonnel en die monitering, nie die prys van een verbinding vandag nie. Sluit die arbeid in wat niemand faktureer nie: iemand moet sleutels roteer, tonneltoestand dophou en die waarskuwing om drie in die oggend antwoord wanneer 'n gateway herbegin. Daardie lynitem is gewoonlik wat die argument beslis, want dit is die enigste een wat nooit in 'n kwotasie verskyn nie.

Watter een jy ook al kies, toets drie vloeie: die beoogde een, 'n geweierde een wat geweier moet bly, en die herstelgeval waar die hub-gateway of 'n peering af is. 'n Model wat net die gelukkige pad verduidelik, is nie geverifieer nie, dit is gedemonstreer.

Verifieer die keuse teen sy eie bewering

Skryf een sin wat die model, die grens en die eienaar noem, en kontroleer dan dat die ontplooide toestand daarby pas. Vir peering beteken dit albei peering-toestande Connected, die effektiewe roete wat die peering-volgende-sprong vir die bestemmingsprefiks wys, en geen gateway op die pad nie. Vir 'n VNet-tot-VNet-VPN beteken dit albei verbindings Connected, passende sleutels en beleide op albei gateways, en 'n roete waarvan die volgende sprong die virtuele netwerk-gateway is.

As die kontroles met die sin verskil, maak eers die sin reg. Die meeste verwarring in hierdie ontwerpe kom van 'n hibried wat niemand beskryf het nie: 'n peering vir die werklaag-subnet, 'n VPN vir een legacy-diens, en 'n roetetabel wat stilweg een van hulle verkies.