Azure-peering of VNet-nei-VNet-VPN? Beslis foar it rûtesetten

Azure jout dy teminsten twa manieren om twa firtuele netwurken te ferbinen, en it binne gjin útwikselbere ynstellingen op itselde objekt. Peering ferbynt de VNets op Microsoft syn rêchbonke sûnder gateway; in VNet-nei-VNet-VPN set in IPsec-relaasje tusken twa gateways dy'tst sels útbesteget, diminsjonearrest en folget. It beslút komt del op trije betingsten, en asst foar it tafoegjen fan in rûte net op alle trije antwurdzje kinst, bist in omwei oan it bouwen foar in model datst nea keazen hast.

Trije betingsten dy't it model beslisje

De earste is oft eat yn 'e eask in IPsec-grins nedich hat dy't fan dy is en dêr'tst nei wize kinst. De twadde is oft de adresromten skjin binne en oft de twa VNets allinnich mei elkoar prate moatte. De tredde is wa't eigner is fan hokker trochgongsrûte dan ek en fan 'e gateway-rekken. Antwurdzje se yn dy oarder, want de earste kin peering útslute, hoe oantreklik de twadde ek liket.

Wat beide modellen diele is in hurde adresseringsregel: de adresromten fan VNet meie net oerlaapje. Noch peering noch in VNet-nei-VNet-VPN is in stipe manier om twa identike berikken ûndûbelsinnich te meitsjen, en in oerlaap freget in mapping-ûntwerp of in werûntwerp, net in oar ferbiningstype.

Betingst 1: hast in IPsec-grins nedich dy't fan dy is?

Peering ferfiert ferkear oer Azure syn privee rêchbonke en freget gjin VPN-gateway foar de peered-ferbining sels. Dat is in útspraak oer ferfier, net in útspraak oer fersifering dy'tst oan in auditor jaan kinst as «wy rinne IPsec». As de eask in troch de klant konfigurearre tunnel, in spesifyk IKE-belied of in grins neamt dy't einiget op apparatuer dy'tst behearst, dan foldocht peering dêr net oan, hoe privee de rêchbonke ek is.

In VNet-nei-VNet-VPN biedt dy grins wol: twa gateways, in IPsec/IKE-relaasje, dielde kaaien en it hiele operasjonele oerflak dat dêrmei komt. Do erffest tunnelstatus, gateway-kapasiteit, SKU-limiten en de monitoaring dy't bewissiget dat de tunnel oan is. Dat is it goede antwurd as de eask krekt oer dy grins giet, beskreaun yn it peering-oersjoch as in apart ferbiningstype fan peering.

Wês like foarsichtich yn 'e oare rjochting. «Wy hawwe fersifering tusken VNets nedich» wurdt faak foldien troch de eigen TLS fan 'e workload, en dan is in gateway in kostenpost sûnder eask derachter. Skriuw de sin dy't de auditor lêze sil foar'tst it meganisme kiest.

Betingst 2: is de topology direkt, of moat eat trochgong krije?

Peering is net transityf. Twa VNets dy't oan in hub peered binne, binne dêrtroch net mei elkoar ferbûn, en in rûte dy't yn ien rjochting te wurkjen liket, is meast in peering dy't mar oan ien kant Connected berikt hat. Beide kanten moatte bestean en beide moatte Connected sjen litte, en dat is it earste datst kontrolearrest as ferkear stil ferdwynt.

As de eask berikberens fan it pleatslike netwurk fia in hub is, dan is gateway-transit in apart ûntwerp mei spesifike rollen: de hub hat de gateway, it spoke-peering lit gateway-transit ta, en it spoke moat trochstjoerd ferkear tastean. Dat binne eigenskippen op it peering, gjin automatyske gefolgen fan it ferbinen fan 'e VNets:

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

De effektive rûtetabel is it earlike antwurd op «bestiet it paad?». Hy lit it type folgjende hop sjen dat it platfoarm echt brûke sil, dus in peering dat konfigurearre liket mar net ferbûn is, ferskynt as in ûntbrekkende of ferkearde rûte yn stee fan in riedsel.

Betingst 3: wa't eigner is fan 'e trochgongsrûte en de rekken?

Elke ekstra hop hat in eigner. By peering betsjut in nije VNet in nij peering-pear oan beide kanten en, foar trochgong, in hub dy't ferkear trochstjoert en in rûtetabel dy't dêrnei bliuwt wizen. By in VPN betsjut in nije VNet noch in gateway of noch in ferbining op in besteande, mei syn eigen kapasiteitsplafond om te folgjen.

Kosten folgje deselde foarm mar net deselde posten: peering-tariven binne ferbining en dataferfier, wylst in VPN gateway-oeren en syn eigen ferfierstariven tafoeget. Ferlykje it totaal foar de topology dy'tst echt in jier draaie silst, ynklusyf de twadde tunnel en de monitoaring, net de priis fan ien ferbining hjoed. Nim it wurk mei dat nimmen fakturearret: immen moat kaaien draaie, de tunnelstatus folgje en it alarm om trije oere nachts beantwurdzje as in gateway werstart. Krekt dy post beslûtsjocht meast it skeel, want it is de iennige dy't nea yn in offerte ferskynt.

Hokkerst ek kiest, test trije streamen: de bedoelde, in wegere dy't wegere bliuwe moat, en it gefal fan werstel wêrby't de hub-gateway of in peering del is. In model dat allinnich it lokkige paad ferklearret, is net ferifiearre, it is demonstrearre.

Ferifiearje de kar tsjin syn eigen bewearing

Skriuw ien sin dy't it model, de grins en de eigner neamt, en kontrolearje dan dat de útrôle steat dêrmei oerienkomt. Foar peering betsjut dat beide peering-steaten Connected, de effektive rûte lit de peering-folgjende-hop sjen foar it bestimming-prefiks, en gjin gateway yn it paad. Foar in VNet-nei-VNet-VPN betsjut it beide ferbiningen Connected, oerienkommende kaaien en belied op beide gateways, en in rûte waans folgjende hop de firtuele-netwurk-gateway is.

As de kontrôles it net iens binne mei de sin, reparearje dan earst de sin. It measte betizing yn dizze ûntwerpen komt fan in hybride dy't nimmen beskreaun hat: in peering foar it workload-subnet, in VPN foar ien âlde tsjinst en in rûtetabel dy't stil ien fan beide foarkar jout.