Nastavení GatewaySubnet v Azure: rezervujte ho před bránou

Otevřete virtuální síť na portálu a podívejte se na adresní prostor, než sáhnete na okno podsítě. Pokud je ta /24 už rozdělená na podsítě pracovních zátěží a nic není volné, není místo na rezervaci /27 a skončíte buď novým dělením, nebo rozšířením VNet, což je jiná změna s jinou revizí. Nejprve vyřešte prostor, potom vytvořte podsíť.

Na tom pořadí záleží, protože podsíť brány není podsíť pracovní zátěže se zvláštním názvem. Je to rezervace adres pro spravované instance brány a Azure bránu odmítne, pokud je rezervace špatná.

Začněte adresním prostorem

Než něco napíšete, zapište prefix VNet, podsítě pracovních zátěží a rezervaci brány na jeden řádek. VNet na 10.60.0.0/16 má místo; zvolte rozsah na konci, aby růst pracovních zátěží zůstal souvislý.

Například 10.60.255.192/26 nechává 64 adres pro bránu, zatímco pracovní zátěže zůstávají v 10.60.0.0/20. To je příklad plánování adres, ne slib velikosti. Microsoft nyní vyžaduje /27 nebo větší pro brány VPN mimo Basic, kde větší znamená více adres: /26 dává 64, zatímco /28 dává 16. Zaokrouhlujte nahoru, nikdy dolů, dokud se plán adres ještě hýbe.

Vytvořte podsíť s přesným názvem

Na portálu přidejte podsíť a napište název GatewaySubnet přesně, velké G a velké S, bez mezer nebo přípony. Azure tento řetězec porovnává, takže Gateway-Subnet nebo gateway vytvoří podsíť, kterou služba brány nepoužije.

Stejný krok z CLI, který se snáz zapisuje do revize:

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

Nechte podsíť prázdnou. Žádný VM, žádný privátní endpoint, žádná delegace služby. Pokud tam už něco žije, nasazení selže a chyba málokdy pojmenuje překážející prostředek, takže si před začátkem projděte seznam prostředků podsítě.

Udržujte spravovanou podsíť bez pravidel pracovních zátěží

Nepřipojujte k této podsíti skupinu zabezpečení sítě; Microsoft to označuje jako nepodporované. Nepřidružujte směrovací tabulku, jejíž výchozí trasa posílá 0.0.0.0/0 někam jinam, protože to může narušit provoz brány, a propagaci tras brány nechte zapnutou.

Omezení přístupu, která jste skutečně chtěli, dejte na podsíť pracovní zátěže nebo na hranici inspekce. Zacházet s GatewaySubnet jako s běžnou podsítí je chyba, která vytvoří bránu, jež se čistě nasadí a pak nepropustí žádný provoz.

Vynucené tunelování má vlastní dokumentovaný návrh. Improvizovaná výchozí trasa na podsíti brány to není.

Zkontrolujte závislosti, které portál nezobrazuje

Než stisknete vytvořit, projděte seznam: přesný název, prefix uvnitř prostoru VNet, žádné překrytí s místními rozsahy, žádné prostředky pracovních zátěží uvnitř, žádná NSG a žádná směrovací tabulka s výchozí trasou. Každá z těchto věcí už nějaké skutečné nasazení rozbila. Potom potvrďte širší návrh: místní síťovou bránu pro místní stranu, adresní prostory, které chcete směrovat, a zda se plánuje aktivní-aktivní režim nebo koexistence. Tyto volby mění rozhovor o velikosti a je mnohem levnější je vyřešit teď.

Stránka Referenční informace k nastavení brány Azure je to, na co se odkazuje, když se někdo ptá, proč podsíť nemůže pojmout VM.

Pokud brána už existuje

Změna velikosti nebo nahrazení podsítě brány není úprava masky. Nejprve zkontrolujte podporovaný postup změny pro SKU a generaci brány a vypište závislé objekty: připojení, veřejné IP adresy, směrování a případné požadavky na obnovu.

Pokud postup vyžaduje znovuvytvoření brány, naplánujte to jako migraci služby s oknem a návratem. Zaznamenejte rezervaci, kterou jste zvolili, důvod velikosti a pravidla, která jste záměrně nepřipojili, aby další recenzent neopravil prázdnou podsíť přidáním NSG.