למה הוספת קידומת Azure VPN מנתקת את החיבור

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

שלושה אובייקטים, שאחד מהם מחזיק בקידומת

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

יש הסתייגות שלישית שכדאי לזכור. GatewaySubnet מארח את מופעי השער המנוהלים, חייב לשאת בדיוק את השם הזה, ולגבי SKU שאינם Basic מצופה שיהיה לפחות /27.

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

למה דווקא החיבור מוסר

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

המחיקה הזו היא ההשבתה, לכן התייחסו אליה כאל שינוי מתוכנן עם התחלה וסיום צפוי ולא כעריכה מהירה. ב-PowerShell הרצף קצר: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, ואז Set-AzLocalNetworkGateway עם -AddressPrefix המערך החדש, ואז New-AzVirtualNetworkGatewayConnection עם אותו -SharedKey ואותם שערים. שימוש חוזר במפתח חשוב, כי הצד המרוחק אינו מוגדר מחדש ומפתח חדש פירושו תיאום עם מי שמחזיק במכשיר המרוחק. אם צוות אחר מפעיל את המכשיר הזה, סכמו איתו את חלון הזמן לפני שאתם מסירים משהו.

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

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

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

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

קראו את המצב, לא את התג בפורטל

קראו את המצב מהמשאב ולא מהתג בפורטל. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 מחזיר ConnectionStatus יחד עם מוני בתים נכנסים ויוצאים, והמונים הם מה שמבדיל מנהרה שמחוברת ואינה נושאת דבר מזו שמעולם לא הוקמה.

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

טיימרים מסבירים סוג של ניתוקים שמיוחסים בטעות ל-VPN. מאזן העומס של Azure סוגר זרימות סרק לאחר הזמן שהוגדר, ארבע דקות כברירת מחדל כשנכתבו ההערות האלה וניתן להגדיל, ולכן שרת OpenVPN על VM בלי keepalive יכול ליפול כל כמה דקות בזמן שכל השאר נראה בריא. שער שהפלטפורמה ממחזרת יכול גם לקטוע חיבור VNet אל Web App, והכשל הזה נמצא בצד הפלטפורמה ולא בתצורת לקוח. הסימן הוא אם הניתוק עוקב אחרי מרווח קבוע או אחרי שינוי שעשיתם.

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

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