Heeft een Azure VNet met peering een eigen VPN-gateway nodig?

Er verschijnt een nieuwe spoke-VNet, de hub heeft al een werkende site-to-sitegateway, en de voor de hand liggende vraag is of u voor een tweede gateway moet betalen. Meestal niet: gateway-transit laat de spoke de gateway van de hub via peering gebruiken. Drie voorwaarden bepalen of dat werkt, en geen ervan is zichtbaar op de peering-statusbadge. Peering-connectiviteit en toestemming om iemands anders gateway te gebruiken zijn aparte instellingen, dus twee VM's die elkaar al kunnen pingen bewijzen niets over het VPN-pad.

Eerste voorwaarde: de gateway, en het ontbreken ervan in de spoke

Azure ondersteunt gateway-transit voor VPN Gateway-SKU's anders dan Basic, en zowel regionale als globale peering kunnen die dragen. De spoke gebruikt een gateway die hij niet bezit, dus kan hij er geen eigen hebben: als er al een gateway in de spoke staat, of een optie voor een externe gateway al is geselecteerd, is de gewenste transitinstelling niet beschikbaar of niet effectief. Controleer dat voordat u iets debugt, want het uitgeschakelde selectievakje is het symptoom, niet de fout. Lees eerst de SKU en de bestaande gateway, en kijk dan naar de peering-instellingen.

Verwijder geen bestaande spoke-gateway om de optie te laten verschijnen voordat u weet wat ervan afhangt. De migratievolgorde is belangrijker dan het selectievakje.

Tweede voorwaarde: één instelling in elke peering-richting

Een peering bestaat uit twee objecten, één op elke VNet, en de transitinstellingen staan aan verschillende kanten van dat paar. De peering van de hub naar de spoke moet de gateway van de hub toestaan de spoke te bedienen; de peering van de spoke naar de hub moet de gateway van de hub accepteren. Microsofts gids voor gateway-transit noemt ze per richting, en dat is de enige manier om ze goed te houden:

Een besturingselement met het label remote verandert van betekenis afhankelijk van van welke VNet u de peering bewerkt, dus lees de richting, niet het woord. Stel beide kanten in, sla op en bevestig dat de peering op beide plekken als verbonden wordt gemeld.

Derde voorwaarde: adresruimte en machtigingsgrenzen

Transit kan niet maken dat hetzelfde bestemmingsprefix twee netwerken betekent, dus de bereiken van hub, spoke en het lokale netwerk moeten los van elkaar staan voordat iets hiervan werkt. De VNet's kunnen ook in verschillende abonnementen of verschillende tenants staan; dat is geen verbod, maar de identiteit die elke peering maakt of bijwerkt heeft de vereiste machtigingen op dat netwerk nodig. Wijzigingen tussen abonnementen mislukken vaak op machtigingen, en de fout is gemakkelijk verkeerd te lezen als een topologieprobleem.

Schrijf de bereiken en de eigenaren op vóór de wijziging. Gokken op een van beide levert een peering op die verbindt en niets routeert.

Verifieer met effectieve routes, niet met peering-status

Kijk naar de effectieve routes op de netwerkinterface van een spoke-workload en vind het werkelijke lokale prefix. Controleer de routetabel van het subnet en of de verspreiding van gatewayroutes is uitgeschakeld, omdat een door de gebruiker gedefinieerde route of een inspectieapparaat het pad kan overrulen dat de peering-vlaggen suggereren. Bevestig daarna de andere richting: het lokale netwerk moet weten hoe het het spoke-prefix via de site-to-siteverbinding bereikt, hetzij via geleerde aankondigingen, hetzij via een expliciete route en een bijbehorende vermelding voor een beschermd netwerk op het klantapparaat. Als het prefix aan een van beide kanten ontbreekt, zijn de peering-vlaggen niet wat er gewijzigd moet worden.

Test één dienst vanaf een spoke-workload en volg het antwoord. Een test vanaf de VPN-gateway of vanaf een hub-VM gebruikt een ander bronprefix en een ander pad.

Als de topologie ook point-to-site-clients bedient, valideer dan hun geïnstalleerde routes apart. Windows-clientpakketten kunnen na een topologiewijziging opnieuw gegenereerd moeten worden, en dat is een taak voor clientrouting, niet het bewijs dat het delen van de gateway is mislukt.

Wat het delen van een gateway niet geeft

Gateway-transit is een routeringsgemak, geen autorisatie. Netwerkbeveiligingsgroepen, lokale filters en regels op serviceniveau bepalen nog steeds wat een spoke-workload kan bereiken, dus schakel de specifieke bron-naar-bestemmingdienst in in plaats van aan te nemen dat de gedeelde tunnel alles erachter toestaat.

Peering is ook niet transitief zoals mensen hopen. Het toevoegen van nog een spoke, of een privé-eindpunt, brengt eigen routerings- en toegangsvereisten mee die de bestaande transitinstelling niet dekt.