Azure-peering aŭ VPN de VNet al VNet? Decidu antaŭ enkursigo

Azure donas al vi almenaŭ du manierojn konekti du virtualajn retojn, kaj ili ne estas interŝanĝeblaj agordoj sur la sama objekto. Peering kunigas la VNet-ojn sur la dorso de Microsoft sen pordego; VPN de VNet al VNet metas IPsec-rilaton inter du pordegoj, kiujn vi memstarigas, grandigas kaj observas. La decido dependas de tri kondiĉoj, kaj se vi ne povas respondi al ĉiuj tri antaŭ ol aldoni vojon, vi pretas konstrui ĉirkaŭvojon por modelo, kiun vi neniam elektis.

Tri kondiĉoj, kiuj decidas la modelon

La unua estas ĉu io en la postulo bezonas IPsec-limon, kiun vi posedas kaj al kiu vi povas montri. La dua estas ĉu la adresspacoj estas puraj kaj ĉu la du VNet-oj nur bezonas paroli unu kun la alia. La tria estas kiu posedas ajnan trairecan vojon kaj la pordegan fakturon. Respondu en tiu ordo, ĉar la unua povas forigi peering, kiel ajn alloga aspektas la dua.

Kion ambaŭ modeloj kunhavas estas malmola adresregulo: la adresspacoj de VNet ne rajtas interkovriĝi. Nek peering nek VPN de VNet al VNet estas subtenata maniero igi du identajn gamojn sendubaj, kaj interkovro bezonas mapadan dezajnon aŭ redezajnon, ne alian konektotipon.

Kondiĉo 1: ĉu vi bezonas IPsec-limon, kiun vi posedas?

Peering portas trafikon sur la privata dorso de Azure kaj ne postulas VPN-pordegon por la peered-konekto mem. Tio estas aserto pri transporto, ne aserto pri ĉifrado, kiun vi povas prezenti al revizoro kiel «ni uzas IPsec». Se la postulo nomas kliente agorditan tunelon, specifan IKE-politikon aŭ limon, kiu finiĝas sur ekipaĵo, kiun vi kontrolas, peering ne plenumas ĝin, kiel ajn privata estas la dorso.

VPN de VNet al VNet ja provizas tiun limon: du pordegoj, IPsec/IKE-rilato, komunaj ŝlosiloj kaj la tuta operacia surfaco, kiu venas kun ĝi. Vi heredas tunelan staton, pordegan kapaciton, SKU-limojn kaj la observadon, kiu pruvas, ke la tunelo funkcias. Tio estas la ĝusta respondo, kiam la postulo temas precize pri tiu limo, priskribita en la superrigardo de peering kiel aparta konektotipo.

Estu same zorgema en la alia direkto. «Ni bezonas ĉifradon inter VNet-oj» ofte plenumiĝas per la propra TLS de la laborŝarĝo, kaj tiam pordego estas kosto sen postulo malantaŭ ĝi. Skribu la frazon, kiun la revizoro legos, antaŭ ol elekti la mekanismon.

Kondiĉo 2: ĉu la topologio estas rekta, aŭ ĉu io devas trairi?

Peering ne estas traireca. Du VNet-oj peered al centro ne estas per tio konektitaj unu al la alia, kaj vojo, kiu ŝajnas funkcii en unu direkto, kutime estas peering, kiu atingis Connected nur unuflanke. Ambaŭ flankoj devas ekzisti kaj ambaŭ devas montri Connected, kaj tio estas la unua afero, kiun vi kontrolu, kiam trafiko silente malaperas.

Se la postulo estas atingi la surlokan reton tra centro, pordega traireco estas aparta dezajno kun specifaj roloj: la centro posedas la pordegon, la spoke-peering permesas pordegan trairecon, kaj la spoke devas permesi plusenditan trafikon. Tiuj estas ecoj de la peering, ne aŭtomataj sekvoj de konektado de la VNet-oj:

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

La efektiva vojtabelo estas la honesta respondo al «ĉu la vojo ekzistas?». Ĝi montras la tipon de sekva salteto, kiun la platformo efektive uzos, do peering, kiu aspektas agordita sed ne estas konektita, aperas kiel mankanta aŭ malĝusta vojo anstataŭ kiel mistero.

Kondiĉo 3: kiu posedas la trairecan vojon kaj la fakturon?

Ĉiu plia salteto havas posedanton. Kun peering, nova VNet signifas novan peering-paron ambaŭflanke kaj, por traireco, centron, kiu daŭre plusendas trafikon, kaj vojtabelon, kiu daŭre montras al ĝi. Kun VPN, nova VNet signifas alian pordegon aŭ alian konekton sur ekzistanta, kun propra kapacita plafono observebla.

Kosto sekvas la saman formon sed ne la samajn erojn: peering-kotizoj estas konekto kaj datentransigo, dum VPN aldonas pordegajn horojn kaj proprajn transigkotizojn. Komparu la tuton por la topologio, kiun vi efektive funkciigos dum jaro, inkluzive de la dua tunelo kaj la observado, ne la prezon de unu konekto hodiaŭ. Inkluzivu la laboron, kiun neniu fakturas: iu devas rotacii ŝlosilojn, observi la tunelan staton kaj respondi la alarmon je la tria nokte, kiam pordego restartas. Tiu ero kutime decidas la argumenton, ĉar ĝi estas la sola, kiu neniam aperas en cito.

Kiun ajn vi elektos, testu tri fluojn: la celitan, rifuzitan, kiu devas resti rifuzita, kaj la reakiran kazon, kiam la centra pordego aŭ peering estas malfunkcia. Modelo, kiu klarigas nur la feliĉan vojon, ne estis kontrolita, ĝi estis montrita.

Kontrolu la elekton kontraŭ ĝia propra aserto

Skribu unu frazon, kiu nomas la modelon, la limon kaj la posedanton, poste kontrolu, ke la deplojita stato kongruas kun ĝi. Por peering tio signifas, ke ambaŭ peering-statoj estas Connected, ke la efektiva vojo montras la peering-sekvsalteton por la cella prefikso, kaj ke neniu pordego estas en la vojo. Por VPN de VNet al VNet ĝi signifas, ke ambaŭ konektoj estas Connected, ke ŝlosiloj kaj politikoj kongruas sur ambaŭ pordegoj, kaj ke vojo havas la virtualretan pordegon kiel sekvan salteton.

Se la kontroloj malkongruas kun la frazo, unue riparu la frazon. Plejparto de la konfuzo en tiuj dezajnoj venas de hibrido, kiun neniu priskribis: peering por la laborŝarĝa subreto, VPN por unu malnova servo, kaj vojtabelo, kiu silente preferas unu el ili.