Azure-peering eller VPN från VNet till VNet? Bestäm före routningen

Azure ger dig minst två sätt att ansluta två virtuella nätverk, och de är inte utbytbara inställningar på samma objekt. Peering kopplar ihop VNet-en på Microsofts stomnät utan gateway; en VPN från VNet till VNet sätter en IPsec-relation mellan två gatewayer som du distribuerar, dimensionerar och övervakar. Beslutet kokar ner till tre villkor, och om du inte kan svara på alla tre innan du lägger till en rutt bygger du en omväg för en modell du aldrig valde.

Tre villkor som avgör modellen

Det första är om något i kravet behöver en IPsec-gräns som du äger och kan peka på. Det andra är om adressrymderna är rena och de två VNet-en bara behöver prata med varandra. Det tredje är vem som äger en eventuell transitväg och gateway-fakturan. Svara i den ordningen, för det första kan utesluta peering hur attraktivt det andra än ser ut.

Det båda modellerna delar är en hård adresseringsregel: VNet-enas adressrymder får inte överlappa. Varken peering eller en VPN från VNet till VNet är ett stött sätt att göra två identiska intervall entydiga, och en överlappning kräver en mappningsdesign eller en omdesign, inte en annan anslutningstyp.

Villkor 1: behöver du en IPsec-gräns som du äger?

Peering transporterar trafik över Azures privata stomnät och kräver ingen VPN-gateway för själva peer-anslutningen. Det är ett påstående om transport, inte ett påstående om kryptering som du kan ge en revisor som «vi kör IPsec». Om kravet namnger en kundkonfigurerad tunnel, en specifik IKE-policy eller en gräns som terminerar på utrustning du kontrollerar, uppfyller peering det inte, hur privat stomnätet än är.

En VPN från VNet till VNet ger just den gränsen: två gatewayer, en IPsec/IKE-relation, delade nycklar och hela den operativa yta som följer med. Du ärver tunnelstatus, gateway-kapacitet, SKU-gränser och övervakningen som bevisar att tunneln är uppe. Det är rätt svar när kravet handlar just om den gränsen, som i peering-översikten beskrivs som en annan anslutningstyp än peering.

Var lika noggrann åt andra hållet. «Vi behöver kryptering mellan VNet-en» uppfylls ofta av arbetslastens egen TLS, och då är en gateway en kostnad utan krav bakom. Skriv meningen revisorn ska läsa innan du väljer mekanism.

Villkor 2: är topologin direkt, eller måste något transitera?

Peering är inte transitiv. Två VNet som är peerade till ett hub är inte därmed kopplade till varandra, och en rutt som ser ut att fungera i en riktning är oftast en peering som bara nådde Connected på ena sidan. Båda sidorna måste finnas och båda måste visa Connected, och det är det första du kontrollerar när trafiken tyst försvinner.

Om kravet är åtkomst till det lokala nätet genom ett hub är gateway-transit en egen design med bestämda roller: huben äger gatewayen, spoke-peeringen tillåter gateway-transit och spoken måste tillåta vidarebefordrad trafik. Det är egenskaper på peeringen, inte automatiska konsekvenser av att koppla ihop VNet-en:

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 effektiva rutttabellen är det ärliga svaret på «finns vägen?». Den visar typen av nästa hopp som plattformen faktiskt använder, så en peering som ser konfigurerad ut men inte är ansluten visas som en saknad eller felaktig rutt i stället för som ett mysterium.

Villkor 3: vem äger transitvägen och fakturan?

Varje extra hopp har en ägare. Med peering innebär ett nytt VNet ett nytt peering-par på båda sidor och, för transit, ett hub som fortsätter vidarebefordra trafik och en rutttabell som fortsätter peka på det. Med en VPN innebär ett nytt VNet en annan gateway eller en annan anslutning på en befintlig, med sitt eget kapacitetstak att hålla koll på.

Kostnaden följer samma form men inte samma poster: peering-avgifter är anslutning och dataöverföring, medan en VPN lägger till gateway-timmar och egna överföringsavgifter. Jämför totalen för den topologi du faktiskt kommer köra i ett år, inklusive den andra tunneln och övervakningen, inte priset för en anslutning i dag. Ta med arbetet som ingen fakturerar: någon måste rotera nycklar, följa tunnelstatus och svara på larmet klockan tre på natten när en gateway startar om. Den posten avgör oftast diskussionen, eftersom den är den enda som aldrig dyker upp i en offert.

Vad du än väljer, testa tre flöden: det avsedda, ett nekat som ska förbli nekat och fallet med återställning när hubens gateway eller en peering ligger nere. En modell som bara förklarar den lyckliga vägen är inte verifierad, den är demonstrerad.

Verifiera valet mot dess eget påstående

Skriv en mening som namnger modellen, gränsen och ägaren och kontrollera sedan att det utrullade tillståndet stämmer med den. För peering betyder det att båda peering-tillstånden är Connected, att den effektiva rutten visar peering som nästa hopp för destinationsprefixet och att det inte finns någon gateway på vägen. För en VPN från VNet till VNet betyder det att båda anslutningarna är Connected, att nycklar och principer stämmer på båda gatewayerna och att rutten har den virtuella nätverksgatewayen som nästa hopp.

Om kontrollerna säger emot meningen, rätta meningen först. Det mesta av förvirringen i dessa designer kommer från en hybrid som ingen beskrev: en peering för arbetslastens subnät, en VPN för en gammal tjänst och en rutttabell som tyst föredrar en av dem.