Azure-peering of VNet-naar-VNet-VPN? Beslis voordat je gaat routeren

Azure geeft je minstens twee manieren om twee virtuele netwerken te verbinden, en het zijn geen uitwisselbare instellingen op hetzelfde object. Peering verbindt de VNetten op de backbone van Microsoft zonder gateway; een VNet-naar-VNet-VPN zet een IPsec-relatie tussen twee gateways die je zelf uitrolt, dimensioneert en monitort. De beslissing komt neer op drie voorwaarden, en als je niet alle drie kunt beantwoorden voordat je een route toevoegt, sta je op het punt een omweg te bouwen voor een model dat je nooit hebt gekozen.

Drie voorwaarden die het model bepalen

De eerste is of iets in de eis een IPsec-grens nodig heeft die van jou is en waar je naar kunt wijzen. De tweede is of de adresruimten schoon zijn en de twee VNetten alleen met elkaar hoeven te praten. De derde is wie eigenaar is van elk transitpad en van de gateway-factuur. Beantwoord ze in die volgorde, want de eerste kan peering uitsluiten, hoe aantrekkelijk de tweede ook lijkt.

Wat beide modellen delen is een harde adresseringsregel: de adresruimten van de VNetten mogen elkaar niet overlappen. Noch peering, noch een VNet-naar-VNet-VPN is een ondersteunde manier om twee identieke reeksen ondubbelzinnig te maken, en een overlap vraagt om een mapping-ontwerp of een herontwerp, niet om een ander verbindingstype.

Voorwaarde 1: heb je een IPsec-grens nodig die van jou is?

Peering vervoert verkeer over de private backbone van Azure en vereist geen VPN-gateway voor de peered-verbinding zelf. Dat is een uitspraak over transport, geen uitspraak over versleuteling die je een auditor kunt geven als «wij draaien IPsec». Als de eis een door de klant geconfigureerde tunnel, een specifiek IKE-beleid of een grens noemt die eindigt op apparatuur die jij beheert, voldoet peering daar niet aan, hoe privé de backbone ook is.

Een VNet-naar-VNet-VPN levert die grens wel: twee gateways, een IPsec/IKE-relatie, gedeelde sleutels en het hele operationele oppervlak dat daarbij hoort. Je erft de tunnelstatus, de gateway-capaciteit, SKU-limieten en de monitoring die bewijst dat de tunnel staat. Dat is het juiste antwoord wanneer de eis precies over die grens gaat, die in het peering-overzicht als een ander verbindingstype dan peering wordt beschreven.

Wees even zorgvuldig in de andere richting. «Wij hebben versleuteling tussen VNetten nodig» wordt vaak vervuld door de eigen TLS van de workload, en dan is een gateway een kostenpost zonder eis erachter. Schrijf de zin die de auditor leest voordat je het mechanisme kiest.

Voorwaarde 2: is de topologie direct, of moet er iets transiteren?

Peering is niet transitief. Twee VNetten die aan een hub zijn gepeerd, zijn daardoor niet met elkaar verbonden, en een route die in één richting lijkt te werken is meestal een peering die alleen aan één kant Connected heeft bereikt. Beide kanten moeten bestaan en beide moeten Connected tonen, en dat is het eerste dat je controleert wanneer verkeer stil verdwijnt.

Is de eis bereikbaarheid van het lokale netwerk via een hub, dan is gateway-transit een apart ontwerp met specifieke rollen: de hub bezit de gateway, de spoke-peering staat gateway-transit toe, en de spoke moet doorgestuurd verkeer toestaan. Dat zijn eigenschappen op de peering, geen automatische gevolgen van het verbinden van de VNetten:

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 effectieve routetabel is het eerlijke antwoord op «bestaat het pad?». Hij toont het type volgende hop dat het platform echt gebruikt, dus een peering die geconfigureerd lijkt maar niet is verbonden, verschijnt als een ontbrekende of verkeerde route in plaats van als een raadsel.

Voorwaarde 3: wie bezit het transitpad en de factuur?

Elke extra hop heeft een eigenaar. Bij peering betekent een nieuw VNet een nieuw peering-paar aan beide kanten en, voor transit, een hub die verkeer blijft doorsturen en een routetabel die daar op blijft wijzen. Bij een VPN betekent een nieuw VNet een extra gateway of een extra verbinding op een bestaande, met een eigen capaciteitsplafond om in de gaten te houden.

De kosten volgen dezelfde vorm maar niet dezelfde posten: peering-kosten zijn verbinding en dataoverdracht, terwijl een VPN gateway-uren en eigen overdrachtskosten toevoegt. Vergelijk het totaal voor de topologie die je echt een jaar draait, inclusief de tweede tunnel en de monitoring, niet de prijs van één verbinding vandaag. Reken de arbeid mee die niemand factureert: iemand moet sleutels roteren, de tunnelstatus volgen en 's nachts om drie uur de melding beantwoorden als een gateway herstart. Die post beslist meestal de discussie, omdat het de enige is die nooit in een offerte verschijnt.

Wat je ook kiest, test drie stromen: de bedoelde, een geweigerde die geweigerd moet blijven, en het herstelgeval waarin de hub-gateway of een peering ligt. Een model dat alleen het gelukkige pad uitlegt, is niet geverifieerd maar gedemonstreerd.

Verifieer de keuze tegen haar eigen bewering

Schrijf één zin die het model, de grens en de eigenaar noemt, en controleer dan of de uitgerolde toestand daarmee overeenkomt. Voor peering betekent dat beide peering-toestanden Connected, de effectieve route toont de peering-volgende-hop voor het bestemmingsprefix, en geen gateway in het pad. Voor een VNet-naar-VNet-VPN betekent het beide verbindingen Connected, passende sleutels en beleid op beide gateways, en een route waarvan de volgende hop de gateway van het virtuele netwerk is.

Als de controles het oneens zijn met de zin, repareer dan eerst de zin. Het meeste misverstand in deze ontwerpen komt van een hybride die niemand beschreef: een peering voor het workload-subnet, een VPN voor één oude dienst en een routetabel die stilletjes een van beide voortrekt.