Azure GatewaySubnet સેટઅપ: ગેટવે પહેલાં જગ્યા રિઝર્વ કરો

પોર્ટલમાં વર્ચ્યુઅલ નેટવર્ક ખોલો અને સબનેટ બ્લેડને અડકતા પહેલાં એડ્રેસ સ્પેસ જુઓ. જો એ /24 પહેલેથી વર્કલોડ સબનેટમાં વહેંચાયેલું હોય અને કંઈ ખાલી ન હોય, તો /27 રિઝર્વેશન માટે જગ્યા નથી, અને અંતે તમારે ફરીથી વહેંચવું પડશે અથવા VNet વિસ્તારવું પડશે, જે બીજી સમીક્ષા સાથેનો બીજો ફેરફાર છે. પહેલાં જગ્યા નક્કી કરો, પછી સબનેટ બનાવો.

એ ક્રમ મહત્ત્વનો છે કારણ કે ગેટવે સબનેટ ખાસ નામવાળું વર્કલોડ સબનેટ નથી. તે મેનેજ્ડ ગેટવે ઇન્સ્ટન્સ માટે એડ્રેસ રિઝર્વેશન છે, અને રિઝર્વેશન ખોટું હોય તો Azure ગેટવે નકારી કાઢશે.

એડ્રેસ સ્પેસથી શરૂ કરો

કંઈપણ ટાઇપ કરતા પહેલાં VNet પ્રીફિક્સ, વર્કલોડ સબનેટ અને ગેટવે રિઝર્વેશન એક લાઇનમાં લખો. 10.60.0.0/16 પરની VNetમાં જગ્યા છે; અંતમાં એક રેન્જ પસંદ કરો જેથી વર્કલોડ વૃદ્ધિ સતત રહે.

ઉદાહરણ તરીકે, 10.60.255.192/26 ગેટવે માટે 64 એડ્રેસ છોડે છે જ્યારે વર્કલોડ 10.60.0.0/20 માં રહે છે. આ એડ્રેસ પ્લાનિંગનું ઉદાહરણ છે, સાઇઝનું વચન નહીં. Microsoft હાલમાં નોન-Basic VPN ગેટવે માટે /27 કે તેથી મોટી રેન્જ માંગે છે, જ્યાં મોટી એટલે વધુ એડ્રેસ: /26 64 આપે છે, જ્યારે /28 16 આપે છે. એડ્રેસ પ્લાન હજી ચાલુ હોય ત્યારે ઉપર રાઉન્ડ કરો, ક્યારેય નીચે નહીં.

ચોક્કસ નામ સાથે સબનેટ બનાવો

પોર્ટલમાં સબનેટ ઉમેરો અને નામ GatewaySubnet બરાબર લખો, મોટો G અને મોટો S, સ્પેસ કે પ્રત્યય વગર. Azure એ સ્ટ્રિંગ મેળવે છે, તેથી Gateway-Subnet અથવા gateway એવું સબનેટ બનાવે છે જે ગેટવે સેવા વાપરશે નહીં.

CLI થી એ જ પગલું, જે સમીક્ષામાં લખવું સહેલું છે:

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

સબનેટ ખાલી રાખો. કોઈ VM નહીં, કોઈ પ્રાઇવેટ એન્ડપોઇન્ટ નહીં, કોઈ સર્વિસ ડેલિગેશન નહીં. જો ત્યાં પહેલેથી કંઈક રહેતું હોય, તો ડિપ્લોયમેન્ટ નિષ્ફળ જાય છે અને ભૂલ ભાગ્યે જ રસ્તામાં આવતા રિસોર્સનું નામ લે છે, તેથી શરૂ કરતા પહેલાં સબનેટની રિસોર્સ યાદી તપાસો.

મેનેજ્ડ સબનેટને વર્કલોડ નિયમોથી મુક્ત રાખો

આ સબનેટ સાથે નેટવર્ક સિક્યોરિટી ગ્રુપ જોડશો નહીં; Microsoft તેને અસમર્થિત ગણે છે. એવું રાઉટ ટેબલ સાંકળશો નહીં જેનું ડિફોલ્ટ રૂટ 0.0.0.0/0 ક્યાંક મોકલે, કારણ કે તે ગેટવેની કામગીરી તોડી શકે છે, અને ગેટવે રૂટ પ્રોપેગેશન ચાલુ રાખો.

તમે ખરેખર ઇચ્છતા હતા તે એક્સેસ પ્રતિબંધો વર્કલોડ સબનેટ પર અથવા ઇન્સ્પેક્શન સીમા પર મૂકો. GatewaySubnetને સામાન્ય સબનેટ જેવું ગણવું એ જ ભૂલ છે જે એવો ગેટવે બનાવે છે જે સ્વચ્છ રીતે ડિપ્લોય થાય અને પછી કોઈ ટ્રાફિક પસાર કરે નહીં.

ફોર્સ્ડ ટનલિંગની પોતાની દસ્તાવેજી ડિઝાઇન છે. ગેટવે સબનેટ પર તાત્કાલિક બનાવેલો ડિફોલ્ટ રૂટ એ નથી.

પોર્ટલ ન દર્શાવતી નિર્ભરતાઓ તપાસો

બનાવો દબાવતા પહેલાં યાદી પર જાઓ: ચોક્કસ નામ, VNet સ્પેસની અંદર પ્રીફિક્સ, ઓન-પ્રેમાઇસિસ રેન્જ સાથે ઓવરલેપ નહીં, અંદર વર્કલોડ રિસોર્સ નહીં, NSG નહીં, અને ડિફોલ્ટ રૂટવાળું રાઉટ ટેબલ નહીં. આમાંથી દરેકે આબાદ ડિપ્લોયમેન્ટ તોડ્યું છે. પછી વિશાળ ડિઝાઇનની ખાતરી કરો: ઓન-પ્રેમાઇસિસ બાજુ માટે લોકલ નેટવર્ક ગેટવે, તમે રૂટ કરવાની અપેક્ષા રાખતા એડ્રેસ સ્પેસ, અને એક્ટિવ-એક્ટિવ કે સહઅસ્તિત્વ યોજાયું છે કે નહીં. એ પસંદગીઓ સાઇઝની વાતચીત બદલે છે, અને તે હવે નક્કી કરવી ઘણી સસ્તી છે.

જ્યારે કોઈ પૂછે કે સબનેટ VM કેમ રાખી શકતું નથી, ત્યારે ટાંકવાનું પાનું Azure ગેટવે સેટિંગ્સ સંદર્ભ છે.

જો ગેટવે પહેલેથી અસ્તિત્વમાં હોય

ગેટવે સબનેટનું સાઇઝ બદલવું કે બદલવું એ માસ્ક એડિટ નથી. પહેલાં ગેટવે SKU અને જનરેશન માટે સમર્થિત ફેરફાર પ્રક્રિયા તપાસો, અને નિર્ભર ઑબ્જેક્ટની યાદી બનાવો: કનેક્શન, પબ્લિક IP, રાઉટિંગ અને કોઈપણ પુનઃપ્રાપ્તિ જરૂરિયાત.

જો પ્રક્રિયા ગેટવે ફરીથી બનાવવાની માંગ કરે, તો તેને વિન્ડો અને રોલબેક સાથે સેવા માઇગ્રેશન તરીકે યોજો. તમે પસંદ કરેલું રિઝર્વેશન, સાઇઝનું કારણ અને જાણી જોઈને ન જોડેલા નિયમો નોંધો, જેથી આગલો સમીક્ષક NSG ઉમેરીને ખાલી સબનેટ સુધારે નહીં.