Behöver en Azure VNet med peering en egen VPN-gateway?
En VNet med peering kan använda hubbens VPN-gateway med en SKU som stöds och en inställning i varje peering-riktning. Verifiera de effektiva rutterna, inte peering-statusen.
En ny spoke-VNet dyker upp, hubben har redan en fungerande site-to-site-gateway, och den uppenbara frågan är om du måste betala för en andra gateway. Oftast inte: gateway-transit låter spoken använda hubbens gateway via peering. Tre villkor avgör om det fungerar, och inget av dem syns på peering-statusmärket. Peering-anslutning och tillstånd att använda någon annans gateway är separata inställningar, så två VM:er som redan kan pinga varandra bevisar ingenting om VPN-vägen.
Första villkoret: gatewayen, och spokens avsaknad av en
Azure stöder gateway-transit för VPN Gateway-SKU:er utöver Basic, och både regional och global peering kan bära den. Spoken använder en gateway som den inte äger, så den kan inte ha en egen: om det redan finns en gateway i spoken, eller ett alternativ för fjärrgateway redan är valt, blir den transitinställning du vill ha otillgänglig eller verkningslös. Kontrollera det innan du felsöker något, eftersom den inaktiverade kryssrutan är symptomet, inte felet. Läs SKU:n och den befintliga gatewayen först och titta sedan på peering-inställningarna.
Ta inte bort en befintlig spoke-gateway för att få alternativet att visas förrän du vet vad som är beroende av den. Migreringsordningen är viktigare än kryssrutan.
Andra villkoret: en inställning i varje peering-riktning
En peering är två objekt, ett på varje VNet, och transitinställningarna bor på olika sidor av det paret. Hubbens peering mot spoken måste tillåta hubbens gateway att betjäna spoken; spokens peering mot hubben måste acceptera hubbens gateway. Microsofts guide för gateway-transit namnger dem per riktning, och det är det enda sättet att hålla dem korrekta:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
En kontroll märkt remote ändrar betydelse beroende på vilken VNets peering du redigerar, så läs riktningen, inte ordet. Ställ in båda sidorna, spara och bekräfta att peeringen rapporterar anslutning på båda ställena.
Tredje villkoret: adressutrymme och behörighetsgränser
Transit kan inte få samma destinationsprefix att betyda två nätverk, så hubbens, spokens och det lokala nätets intervall måste vara åtskilda innan något av detta fungerar. VNet:erna kan också ligga i olika prenumerationer eller olika klienter; det är inte ett förbud, men identiteten som skapar eller uppdaterar varje peering behöver de nödvändiga behörigheterna på det nätverket. Ändringar mellan prenumerationer misslyckas ofta på behörigheter, och felet är lätt att feltolka som ett topologiproblem.
Skriv ner intervallen och ägarna före ändringen. Att gissa på något av dem ger en peering som ansluter och inte routar något.
Verifiera med effektiva rutter, inte med peering-status
Titta på de effektiva rutterna på nätverksgränssnittet för en spoke-arbetsbelastning och hitta det faktiska lokala prefixet. Kontrollera subnätets routingtabell och om spridningen av gateway-rutter är inaktiverad, eftersom en användardefinierad rutt eller en inspektionsapparat kan åsidosätta den väg som peering-flaggorna antyder. Bekräfta sedan den andra riktningen: det lokala nätverket måste veta hur det når spoke-prefixet via site-to-site-anslutningen, antingen genom inlärda annonser eller genom en explicit rutt och en matchande post för skyddat nätverk på kundens enhet. Om prefixet saknas på någon av sidorna är det inte peering-flaggorna som ska ändras.
Testa en tjänst från en spoke-arbetsbelastning och följ svaret. Ett test från VPN-gatewayen eller från en hub-VM använder ett annat källprefix och en annan väg.
Om topologin också betjänar point-to-site-klienter, validera deras installerade rutter separat. Windows-klientpaket kan behöva genereras om efter en topologiändring, och det är en klientroutningsuppgift snarare än bevis på att delningen av gatewayen misslyckades.
Vad delning av en gateway inte ger
Gateway-transit är en routningsbekvämlighet, inte en auktorisering. Nätverkssäkerhetsgrupper, lokala filter och regler på tjänstenivå avgör fortfarande vad en spoke-arbetsbelastning kan nå, så aktivera den specifika käll-till-mål-tjänsten i stället för att anta att den delade tunneln tillåter allt bakom den.
Peering är inte heller transitivt som folk hoppas. Att lägga till ytterligare en spoke, eller en privat slutpunkt, inför sina egna rutt- och åtkomstkrav som den befintliga transitinställningen inte täcker.