Azure GatewaySubnet-opstelling: reserveer dit voordat die gateway bestaan

Maak die virtuele netwerk in die portaal oop en kyk na die adresruimte voordat jy aan die subnetblad raak. As daardie /24 al in werklas-subnette opgedeel is met niks oop nie, is daar geen ruimte vir ’n /27-reservering nie, en sal jy eindig deur óf te herverdeel óf die VNet te verbreed, wat ’n ander verandering met ’n ander hersiening is. Bepaal eers die ruimte en skep dan die subnet.

Daardie volgorde maak saak, want die gateway-subnet is nie ’n werklas-subnet met ’n spesiale naam nie. Dit is die adresreservering vir bestuurde gateway-instanties, en Azure sal die gateway weier as die reservering verkeerd is.

Begin met die adresruimte

Skryf die VNet-voorvoegsel, die werklas-subnette en die gateway-reservering op een lyn voordat jy iets intik. ’n VNet op 10.60.0.0/16 het ruimte; kies ’n reeks aan die einde sodat werklas-groei aaneenlopend bly.

Byvoorbeeld, 10.60.255.192/26 laat 64 adresse vir die gateway terwyl werklaslaste in 10.60.0.0/20 bly. Dit is ’n voorbeeld van adresbeplanning, nie ’n belofte oor grootte nie. Microsoft vereis tans /27 of groter vir nie-Basiese VPN-gateways, waar groter meer adresse beteken: ’n /26 gee 64, terwyl ’n /28 16 gee. Rond op, nooit af nie, terwyl die adresplan nog beweeg.

Skep die subnet met die presiese naam

Voeg in die portaal ’n subnet by en tik die naam GatewaySubnet presies, hoofletter G en hoofletter S, sonder spasies of agtervoegsel. Azure pas daardie string, so Gateway-Subnet of gateway lewer ’n subnet wat die gateway-diens nie sal gebruik nie.

Dieselfde stap vanaf die CLI, wat makliker in ’n hersiening is:

az network vnet subnet create --resource-group rg-hub --vnet-name vnet-hub --name GatewaySubnet --address-prefixes 10.60.255.192/26

Los die subnet leeg. Geen VM, geen private endpoint, geen diensdelegasie nie. As iets al daar woon, misluk die ontplooiing en die fout noem selde die hulpbron in die pad, so kyk voor jy begin na die subnet se hulpbronlys.

Hou die bestuurde subnet vry van werklas-reëls

Moet nie ’n netwerksekuriteitsgroep aan hierdie subnet koppel nie; Microsoft merk dit as onondersteun. Moet nie ’n roetetabel assosieer waarvan die verstekroete 0.0.0.0/0 êrens heen stuur nie, want dit kan gateway-werking breek, en hou gateway-roetepropagasie geaktiveer.

Plaas die toegangsbeperkings wat jy eintlik wou gehad het op die werklas-subnet of by ’n inspeksiegrens. Om GatewaySubnet soos ’n gewone subnet te behandel, is die fout wat ’n gateway lewer wat skoon ontplooi en dan geen verkeer deurlaat nie.

Geforseerde tonneling het sy eie gedokumenteerde ontwerp. ’n Geïmproviseerde verstekroete op die gateway-subnet is nie dit nie.

Kontroleer die afhanklikhede wat die portaal nie wys nie

Voordat jy op skep druk, loop die lys na: presiese naam, voorvoegsel binne die VNet-ruimte, geen oorvleueling met plaaslike reekse nie, geen werklas-hulpbronne binne nie, geen NSG nie, en geen roetetabel met ’n verstekroete nie. Elkeen daarvan het al ’n werklike ontplooiing gebreek. Bevestig dan die wyer ontwerp: die plaaslike netwerkpoort vir die plaaslike kant, die adresruimtes wat jy verwag om te roeteer, en of aktief-aktief of naasbestaan beplan word. Daardie keuses verander die gesprek oor grootte, en dit is baie goedkoper om dit nou te bepaal.

Die Azure-verwysing vir gateway-instellings is die bladsy om aan te haal wanneer iemand vra waarom die subnet nie ’n VM kan huisves nie.

As die gateway al bestaan

Om ’n gateway-subnet te verklein of te vervang is nie ’n maskerwysiging nie. Kontroleer eers die ondersteunde veranderingsprosedure vir die gateway-SKU en generasie, en lys die afhanklike objekte: verbindings, openbare IP’s, roetering en enige herstelvereiste.

As die prosedure vereis dat die gateway herskep word, beplan dit as ’n diensmigrasie met ’n venster en ’n terugrol. Teken die reservering aan wat jy gekies het, die rede vir die grootte, en die reëls wat jy doelbewus nie gekoppel het nie, sodat die volgende keurder nie die leë subnet regmaak deur ’n NSG by te voeg nie.