Configurarea GatewaySubnet în Azure: rezervați-l înainte de gateway
GatewaySubnet este infrastructură gestionată de gateway. Stabiliți numele exact, un interval /27 sau mai mare și regulile de rutare înainte ca portalul să creeze ceva.
Deschideți rețeaua virtuală în portal și priviți spațiul de adrese înainte de a atinge panoul subrețelei. Dacă acel /24 este deja împărțit în subrețele de lucru fără nimic liber, nu există loc pentru o rezervare /27 și veți ajunge fie să reîmpărțiți, fie să extindeți VNet-ul, ceea ce este o altă modificare cu altă revizuire. Stabiliți mai întâi spațiul, apoi creați subrețeaua.
Această ordine contează pentru că subrețeaua gateway-ului nu este o subrețea de lucru cu un nume special. Este rezervarea de adrese pentru instanțele gestionate de gateway, iar Azure va refuza gateway-ul dacă rezervarea este greșită.
Începeți cu spațiul de adrese
Scrieți prefixul VNet-ului, subrețelele de lucru și rezervarea gateway-ului pe o singură linie înainte de a tasta ceva. Un VNet pe 10.60.0.0/16 are loc; alegeți un interval la final pentru ca creșterea sarcinilor de lucru să rămână continuă.
De exemplu, 10.60.255.192/26 lasă 64 de adrese pentru gateway, în timp ce sarcinile de lucru rămân în 10.60.0.0/20. Acesta este un exemplu de planificare a adreselor, nu o promisiune privind dimensiunea. Microsoft cere în prezent /27 sau mai mare pentru gateway-urile VPN care nu sunt Basic, unde mai mare înseamnă mai multe adrese: un /26 oferă 64, iar un /28 oferă 16. Rotunjiți în sus, niciodată în jos, cât timp planul de adrese încă se mișcă.
Creați subrețeaua cu numele exact
În portal, adăugați o subrețea și tastați numele GatewaySubnet exact, G mare și S mare, fără spații sau sufix. Azure compară acel șir, așa că Gateway-Subnet sau gateway produce o subrețea pe care serviciul de gateway nu o va folosi.
Același pas din CLI, mai ușor de trecut într-o revizuire:
az network vnet subnet create --resource-group rg-hub --vnet-name vnet-hub --name GatewaySubnet --address-prefixes 10.60.255.192/26Lăsați subrețeaua goală. Fără VM, fără endpoint privat, fără delegare de serviciu. Dacă acolo locuiește deja ceva, implementarea eșuează și eroarea numește rareori resursa care încurcă, așa că verificați lista de resurse a subrețelei înainte să începeți.
Țineți subrețeaua gestionată liberă de reguli de lucru
Nu atașați un grup de securitate de rețea la această subrețea; Microsoft marchează asta ca neacceptată. Nu asociați un tabel de rutare a cărui rută implicită trimite 0.0.0.0/0 undeva, pentru că poate strica funcționarea gateway-ului, și țineți activată propagarea rutelor gateway-ului.
Puneți restricțiile de acces pe care le-ați dorit cu adevărat pe subrețeaua de lucru sau la o limită de inspecție. Tratarea GatewaySubnet ca o subrețea obișnuită este greșeala care produce un gateway ce se implementează curat și apoi nu lasă să treacă niciun trafic.
Tunelarea forțată are propriul design documentat. O rută implicită improvizată pe subrețeaua gateway-ului nu este aceea.
Verificați dependențele pe care portalul nu le arată
Înainte de a apăsa creare, parcurgeți lista: nume exact, prefix în spațiul VNet-ului, fără suprapunere cu intervalele locale, fără resurse de lucru înăuntru, fără NSG și fără tabel de rutare cu rută implicită. Fiecare dintre acestea a stricat o implementare reală. Apoi confirmați designul mai larg: gateway-ul de rețea locală pentru partea locală, spațiile de adrese pe care intenționați să le rutați și dacă este planificat modul activ-activ sau coexistența. Aceste alegeri schimbă discuția despre dimensiune și este mult mai ieftin să le închideți acum.
Referința pentru setările gateway-ului Azure este pagina de citat când cineva întreabă de ce subrețeaua nu poate găzdui o VM.
Dacă gateway-ul există deja
Redimensionarea sau înlocuirea unei subrețele de gateway nu este o editare de mască. Verificați mai întâi procedura de modificare acceptată pentru SKU-ul și generația gateway-ului, și listați obiectele dependente: conexiuni, IP-uri publice, rutare și orice cerință de recuperare.
Dacă procedura cere recrearea gateway-ului, planificați-o ca migrare de serviciu cu fereastră și revenire. Notați rezervarea aleasă, motivul dimensiunii și regulile pe care în mod deliberat nu le-ați atașat, ca următorul revizor să nu repare subrețeaua goală adăugând un NSG.