ב-Azure שלושה אובייקטים שונים נקראים כתובת השער. הכתובת הפרטית מוקצית מ-GatewaySubnet. הכתובת הציבורית היא משאב IP ציבורי נפרד שתצורת ה-IP של השער מצביעה עליו. המנוי וסביבת הענן הם ההקשר שבו המעטפת שלך מוצאת אחד מהם. שנה אחד והשניים האחרים נשארים במקומם, ולכן עבודת כתובות כל כך часто נעצרת באמצע.

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

איזה משלושת האובייקטים אתה באמת משנה

תן שם לאובייקט לפני שאתה פותח את הפורטל. שער VPN לוקח את הכתובת הפרטית שלו מתת-רשת שחייבת להיקרא בדיוק GatewaySubnet, ו-Azure מקצה אותה מהקידומת הזו; אין שדה כללי לנעוץ אותה. הכתובת נראית יציבה רק מפני שתת-הרשת יציבה. שנה את הכתובת של תת-הרשת או בנה מחדש את השער והיא עוברת איתם.

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

ObjectWhere it livesWhat a change forces
Private addressGatewaySubnet prefix, assigned at deploymentSubnet resize or rebuild, then routes, NSGs and peer review
Public addressPublic IP resource referenced by the IP configurationGateway reprovision, peer and allowlist edits, new client profiles
Subscription contextYour PowerShell or CLI sessionNothing in Azure, and it clears most not-found errors

מלאי לפני שמשהו זז

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

Get-AzContext | Select-Object Subscription, Tenant, Environment
Get-AzVirtualNetworkGateway -ResourceGroupName rg-hub -Name gw-hub |
  Select-Object Name, Sku, EnableActiveActive, IpConfigurations
Get-AzVirtualNetworkGatewayConnection -ResourceGroupName rg-hub |
  Select-Object Name, ConnectionStatus, ConnectionType

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

החלפת ה-IP הציבורי בשער הפעיל

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

$gw = Get-AzVirtualNetworkGateway -ResourceGroupName rg-hub -Name gw-hub
$pip = New-AzPublicIpAddress -Name pip-gw-hub-2 -ResourceGroupName rg-hub `
  -Location westeurope -AllocationMethod Static -Sku Standard
$conf = New-AzVirtualNetworkGatewayIpConfig -Name gwipconfig1 `
  -SubnetId $gw.IpConfigurations[0].Subnet.Id -PublicIpAddressId $pip.Id
Set-AzVirtualNetworkGateway -VirtualNetworkGateway $gw -IpConfigurations $conf

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

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

העברת השער למנוי אחר

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

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

az resource move --destination-group rg-hub `
  --destination-subscription-id 00000000-0000-0000-0000-000000000000 `
  --ids /subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/rg-hub/providers/Microsoft.Network/virtualNetworkGateways/gw-hub

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

כשהשער נראה חסר, בדוק את ההקשר

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

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

Set-AzContext -SubscriptionId 11111111-1111-1111-1111-111111111111
Get-AzResource -ResourceId /subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/rg-hub/providers/Microsoft.Network/virtualNetworkGateways/gw-hub

אמת משני הקצוות לפני הניקוי

מחובר הוא מצב, לא ראיה. בדוק את מצב המנהרה לכל חיבור, מצב עמית BGP אם אתה מריץ ניתוב דינמי, ומסלולים אפקטיביים בתת-רשת עומס. אחר כך העבר בקשה אמיתית אחת דרך אפליקציה שתלויה במנהרה. חיבור יכול לדווח שהוא מחובר כשהקידומת שאתה צריך חסרה בטבלת המסלולים.

Get-AzVirtualNetworkGatewayBGPPeerStatus -VirtualNetworkGatewayName gw-hub -ResourceGroupName rg-hub
Get-AzEffectiveRouteTable -NetworkInterfaceName nic-app -ResourceGroupName rg-app

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

  • ההקשר נעול למנוי שבעל השער
  • ה-IP הציבורי הישן נשמר ותלויותיו נרשמו
  • כל חיבור ירוק ובקשה אמיתית אחת דרכו
  • משתמשי נקודה-לאתר הועברו לפרופיל המחודש
  • רשומת ה-DNS שונתה והערך הקודם שלה נרשם

מאמרים קשורים