Configurare GatewaySubnet in Azure: riservatela prima del gateway
GatewaySubnet è infrastruttura gestita del gateway. Fissate il nome esatto, un intervallo /27 o più grande e le regole di routing prima che il portale crei qualcosa.
Aprite la rete virtuale nel portale e guardate lo spazio degli indirizzi prima di toccare il pannello della subnet. Se quel /24 è già suddiviso in subnet di carico di lavoro senza nulla di libero, non c’è spazio per una prenotazione /27, e finirete per ridividere o per ampliare la VNet, che è un’altra modifica con un’altra revisione. Fissate prima lo spazio, poi create la subnet.
Quest’ordine conta perché la subnet del gateway non è una subnet di carico di lavoro con un nome speciale. È la prenotazione degli indirizzi per le istanze gestite del gateway, e Azure rifiuterà il gateway se la prenotazione è sbagliata.
Iniziate dallo spazio degli indirizzi
Scrivete il prefisso della VNet, le subnet di carico di lavoro e la prenotazione del gateway su una sola riga prima di digitare qualsiasi cosa. Una VNet su 10.60.0.0/16 ha spazio; scegliete un intervallo in fondo perché la crescita dei carichi di lavoro resti contigua.
Per esempio, 10.60.255.192/26 lascia 64 indirizzi al gateway mentre i carichi di lavoro restano in 10.60.0.0/20. È un esempio di pianificazione degli indirizzi, non una promessa di dimensionamento. Microsoft attualmente richiede /27 o più grande per i gateway VPN non Basic, dove più grande significa più indirizzi: una /26 ne dà 64, mentre una /28 ne dà 16. Arrotondate per eccesso, mai per difetto, finché il piano degli indirizzi si muove ancora.
Create la subnet con il nome esatto
Nel portale aggiungete una subnet e digitate il nome GatewaySubnet esattamente, G maiuscola e S maiuscola, senza spazi né suffissi. Azure confronta quella stringa, quindi Gateway-Subnet o gateway produce una subnet che il servizio gateway non userà.
Lo stesso passaggio dalla CLI, più facile da mettere in una revisione:
az network vnet subnet create --resource-group rg-hub --vnet-name vnet-hub --name GatewaySubnet --address-prefixes 10.60.255.192/26Lasciate vuota la subnet. Nessuna VM, nessun endpoint privato, nessuna delega di servizio. Se qualcosa vive già lì, la distribuzione fallisce e l’errore raramente nomina la risorsa che intralcia, quindi controllate l’elenco delle risorse della subnet prima di iniziare.
Tenete la subnet gestita libera da regole di carico di lavoro
Non collegate un gruppo di sicurezza di rete a questa subnet; Microsoft lo segnala come non supportato. Non associate una tabella di route la cui route predefinita invia 0.0.0.0/0 da qualche parte, perché può rompere il funzionamento del gateway, e tenete attiva la propagazione delle route del gateway.
Mettete le restrizioni di accesso che volevate davvero sulla subnet di carico di lavoro o a un confine di ispezione. Trattare GatewaySubnet come una subnet normale è l’errore che produce un gateway che si distribuisce pulito e poi non fa passare alcun traffico.
Il tunneling forzato ha un suo progetto documentato. Una route predefinita improvvisata sulla subnet del gateway non è quello.
Controllate le dipendenze che il portale non mostra
Prima di premere crea, scorrete l’elenco: nome esatto, prefisso dentro lo spazio della VNet, nessuna sovrapposizione con intervalli locali, nessuna risorsa di carico di lavoro all’interno, nessun NSG e nessuna tabella di route con una route predefinita. Ognuno di questi punti ha rotto una distribuzione reale. Poi confermate il progetto più ampio: il gateway di rete locale per il lato locale, gli spazi degli indirizzi che prevedete di instradare e se è previsto attivo-attivo o coesistenza. Queste scelte cambiano la conversazione sul dimensionamento, ed è molto più economico chiuderle ora.
Il riferimento alle impostazioni del gateway Azure è la pagina da citare quando qualcuno chiede perché la subnet non può ospitare una VM.
Se il gateway esiste già
Ridimensionare o sostituire una subnet del gateway non è una modifica della maschera. Controllate prima la procedura di modifica supportata per lo SKU e la generazione del gateway, ed elencate gli oggetti dipendenti: connessioni, IP pubblici, routing ed eventuali requisiti di ripristino.
Se la procedura richiede di ricreare il gateway, pianificatela come migrazione di servizio con una finestra e un rollback. Annotate la prenotazione scelta, il motivo della dimensione e le regole che deliberatamente non avete collegato, così il prossimo revisore non sistema la subnet vuota aggiungendo un NSG.