הגדרת GatewaySubnet ב-Azure: הקצו אותו לפני השער

פתחו את הרשת הווירטואלית בפורטל והסתכלו על מרחב הכתובות לפני שאתם נוגעים בלהב הרשת המשנה. אם ה-/24 הזה כבר מחולק לרשתות משנה של עומסי עבודה בלי שום דבר פנוי, אין מקום להקצאת /27, ובסוף או שתחלקו מחדש או שתרחיבו את ה-VNet, וזהו שינוי אחר עם סקירה אחרת. קבעו קודם את המרחב, ואז צרו את הרשת המשנה.

הסדר הזה חשוב מפני שרשת המשנה של השער אינה רשת משנה של עומס עבודה עם שם מיוחד. היא הקצאת הכתובות למופעי שער מנוהלים, ו-Azure יסרב לשער אם ההקצאה שגויה.

התחילו במרחב הכתובות

כתבו את הקידומת של ה-VNet, את רשתות המשנה של עומסי העבודה ואת הקצאת השער בשורה אחת לפני שאתם מקלידים משהו. ל-VNet על 10.60.0.0/16 יש מקום; בחרו טווח בסוף כדי שגדילת עומסי העבודה תישאר רציפה.

לדוגמה, 10.60.255.192/26 משאיר 64 כתובות לשער בעוד עומסי העבודה נשארים ב-10.60.0.0/20. זו דוגמה לתכנון כתובות, לא הבטחת גודל. Microsoft דורשת כיום /27 או גדול יותר לשערי VPN שאינם Basic, כאשר גדול יותר פירושו יותר כתובות: /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 ובלי טבלת ניתוב עם נתיב ברירת מחדל. כל אחד מאלה שבר פריסה אמיתית. אחר כך אשרו את העיצוב הרחב: שער הרשת המקומית לצד המקומי, מרחבי הכתובות שאתם מצפים לנתב, והאם מתוכנן מצב פעיל-פעיל או דו-קיום. הבחירות האלה משנות את השיחה על הגודל, והרבה יותר זול לסגור אותן עכשיו.

ההפניה להגדרות השער של Azure היא העמוד לצטט כשמישהו שואל למה רשת המשנה לא יכולה להכיל VM.

אם השער כבר קיים

שינוי גודל או החלפה של רשת משנה של שער אינה עריכת מסכה. בדקו תחילה את הליך השינוי הנתמך עבור ה-SKU והדור של השער, ורשמו את האובייקטים התלויים: חיבורים, כתובות IP ציבוריות, ניתוב וכל דרישת שחזור.

אם ההליך דורש יצירה מחדש של השער, תכננו אותו כהעברת שירות עם חלון וחזרה אחורה. רשמו את ההקצאה שבחרתם, את הסיבה לגודל ואת הכללים שבמכוון לא הצמדתם, כדי שהסוקר הבא לא יתקן את רשת המשנה הריקה על ידי הוספת NSG.