Agordi GatewaySubnet en Azure: rezervu ĝin antaŭ la pordego

Malfermu la virtualan reton en la portalo kaj rigardu la adresan spacon antaŭ ol tuŝi la subretan panelon. Se tiu /24 jam estas dividita en laborŝarĝajn subretojn sen io libera, mankas loko por /27-rezervo, kaj vi finos aŭ redistribuante aŭ larĝigante la VNet-on, kio estas alia ŝanĝo kun alia revizio. Fiksu unue la spacon, poste kreu la subreton.

Tiu ordo gravas ĉar la pordega subreto ne estas laborŝarĝa subreto kun speciala nomo. Ĝi estas la adresa rezervo por administrataj pordegaj ekzempleroj, kaj Azure rifuzos la pordegon se la rezervo malĝustas.

Komencu per la adresa spaco

Skribu la VNet-prefikson, la laborŝarĝajn subretojn kaj la pordegan rezervon en unu linio antaŭ ol tajpi ion. VNet ĉe 10.60.0.0/16 havas lokon; elektu intervalon ĉe la fino por ke la kresko de laborŝarĝoj restu kontinua.

Ekzemple, 10.60.255.192/26 lasas 64 adresojn por la pordego dum laborŝarĝoj restas en 10.60.0.0/20. Tio estas ekzemplo de adresa planado, ne promeso pri grando. Microsoft nun postulas /27 aŭ pli grandan por ne-Basic VPN-pordegoj, kie pli granda signifas pli da adresoj: /26 donas 64, dum /28 donas 16. Rondigu supren, neniam malsupren, dum la adresa plano ankoraŭ moviĝas.

Kreu la subreton kun la ĝusta nomo

En la portalo aldonu subreton kaj tajpu la nomon GatewaySubnet ĝuste, granda G kaj granda S, sen spacoj aŭ sufikso. Azure kongruigas tiun ĉenon, do Gateway-Subnet aŭ gateway produktas subreton kiun la pordega servo ne uzos.

La sama paŝo el la CLI, kiu estas pli facile metebla en revizion:

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

Lasu la subreton malplena. Neniu VM, neniu privata finpunkto, neniu serva delegado. Se io jam loĝas tie, la deplojo malsukcesas kaj la eraro malofte nomas la rimedon en la vojo, do kontrolu la rimedoliston de la subreto antaŭ ol komenci.

Tenu la administrata subreto libera de laborŝarĝaj reguloj

Ne alligu retan sekurecan grupon al ĉi tiu subreto; Microsoft markas tion ne subtenata. Ne asociu enkursigan tabelon kies defaŭlta vojo sendas 0.0.0.0/0 ie, ĉar tio povas rompi la funkciadon de la pordego, kaj tenu la pordegan vojdisvastigon ŝaltita.

Metu la alirajn limigojn kiujn vi efektive volis sur la laborŝarĝan subreton aŭ ĉe inspektan limon. Trakti GatewaySubnet kiel ordinaran subreton estas la eraro kiu produktas pordegon kiu deplojiĝas pure kaj poste trapasas neniun trafikon.

Deviga tunelado havas sian propran dokumentitan dezajnon. Improvizita defaŭlta vojo sur la pordega subreto ne estas tio.

Kontrolu la dependecojn kiujn la portalo ne montras

Antaŭ ol premi krei, trairu la liston: ĝusta nomo, prefikso ene de la VNet-spaco, neniu koincido kun lokaj intervaloj, neniuj laborŝarĝaj rimedoj interne, neniu NSG kaj neniu enkursiga tabelo kun defaŭlta vojo. Ĉiu el tiuj rompis realan deplojon. Poste konfirmu la pli vastan dezajnon: la lokan retan pordegon por la loka flanko, la adresajn spacojn kiujn vi atendas enkursigi, kaj ĉu aktiva-aktiva aŭ kunekzistado estas planata. Tiuj elektoj ŝanĝas la konversacion pri grando, kaj estas multe pli malmultekoste decidi ilin nun.

La referenco pri pordegaj agordoj de Azure estas la paĝo citenda kiam iu demandas kial la subreto ne povas enteni VM-on.

Se la pordego jam ekzistas

Ŝanĝi la grandecon aŭ anstataŭigi pordegan subreton ne estas maska redakto. Unue kontrolu la subtenatan ŝanĝproceduron por la SKU kaj generacio de la pordego, kaj listigu la dependajn objektojn: konektoj, publikaj IP-oj, enkursigado kaj ajna postulo pri restarigo.

Se la proceduro postulas rekrei la pordegon, planu tion kiel servan migradon kun fenestro kaj rulfalo. Notu la rezervon kiun vi elektis, la kialon de la grando kaj la regulojn kiujn vi intence ne alligis, por ke la sekva revizianto ne riparu la malplenan subreton aldonante NSG-on.