ExpressRoute בתוספת VPN: אילו תחומי כשל אתם מכסים?
מנהרת IPsec שנייה מכסה נקודת קצה, לא את המעגל שמתחתיה. מפו כל תחום כשל, ואז החליטו אם נתיב גיבוי לא מוצפן מותר.
מנהרת IPsec שרצה מעל peering פרטי של ExpressRoute מוסיפה הצפנה לתעבורה שכבר קיימת. מנהרה שנייה משפרת את זמינות נקודת הקצה, והיא לא עושה דבר וחצי דבר לנתיב הספק שמתחת לשתיהן. קל לאבד את ההבחנה הזו כשהלוחות מציגים שתי מנהרות ירוקות וסקירת התכנון שואלת שאלה אחרת: אילו כשלים החיבור הזה חייב לשרוד? ענו על זה קודם, ואז ספרו מנהרות, כי מספר האינדיקטורים הירוקים הוא תכונה של שכבת ההצפנה ומספר תחומי הכשל הוא תכונה של הנתיב כולו.
התחילו בכשלים, לא במנהרות ירוקות
כתבו ארבע שורות לפני שאתם משרטטים משהו: כשל של נקודת קצה אחת של VPN או מופע peer אחד, כשל של נתב מקומי אחד או חיבור מייל ראשון, כשל של נתיב ExpressRoute המשותף, ו-IPsec שאינו זמין בזמן ש-peering פרטי עדיין נושא תעבורה. כל שורה נוקבת במה שהתכנון חייב לשמר, ולכל אחת עונה מנגנון אחר.
| Failure | What must survive | What does not cover it |
|---|---|---|
| One VPN endpoint or instance | An alternate encryption endpoint and a route to it | A second tunnel terminating on the same instance |
| One local router or first mile | Independent local equipment and transport reachability | Any number of logical tunnels |
| The ExpressRoute path | A separately designed surviving underlay | An IPsec tunnel layered on the same circuit |
| IPsec unavailable, peering up | The intended encrypted-only or approved fallback policy | Assuming the tunnel is the only route |
Microsoft מתעדת VPN מאתר לאתר עם IP פרטי מעל peering פרטי של ExpressRoute, ואת הדו-קיום הנתמך עם חיבורים מאתר לאתר מבוססי אינטרנט. דו-קיום זה הוא תכנון שכבת תשתית אחר, והוא אינו מופיע רק מפני שהוספתם עוד נקודת קצה של מנהרה פרטית.
תחום כשל 1: נקודת הקצה של ה-VPN
שתי מנהרות על שער אחד הן בדרך כלל זוגות active-active שמסתיימים באותו משאב בצד Azure. הן מגנות מפני בעיה של מנהרה אחת או מופע אחד, ואינן מגנות מפני כך שהמשאב הזה יהפוך ללא זמין, יוגדר מחדש או יאזל בקיבולת. יתירות נקודת קצה פירושה נקודת קצה שנייה נתמכת, עם נתיב משלה ותצורה משלה, בתוספת מסלול שיכול להגיע אליה.
בדקו מה פרסתם בפועל ולא מה שהתרשים אומר, כי השער מקבץ את המשאבים האלה בדרכים שמסתירות את הקשר ביניהם:
az network vpn-connection show -g rg-connectivity -n vpn-to-hub --query '{conn:connectionStatus,tunnels:tunnelConnectionStatus}'
az network vnet-gateway show -g rg-connectivity -n gw-hub --query '{sku:sku.name,activeActive:enableBgp,peers:bgpSettings.peers}'אם שתי המנהרות מצביעות לשער אחד עם IP ציבורי אחד, יש לכם יתירות נקודת קצה מסוג מסוים ומוגבל. ייתכן שזה בדיוק מה שהדרישה מבקשת, ויש לומר זאת כך במקום לתאר זאת כחיבור יתיר.
תחום כשל 2: הנתיב המקומי והספק
מתחת להצפנה יושבת מציאות פיזית ומסחרית: התקן קצה של הלקוח, חיבור צולב, רשת ספק ומיקום peering. ההנחיות לזמינות של ExpressRoute מפורשות שיתירות מקצה לקצה כוללת את מקטעי הלקוח וספק השירות, ולא רק את צד Microsoft. שני נתיבים לוגיים שחולקים נתב, מקור מתח או חיבור מייל ראשון עדיין חולקים את התלות הזו.
כאן תכנון בדרך כלל נכשל בסקירה כנה. שני מעגלים מאותו ספק, שמסתיימים באותו בניין, על ציוד מאותה הזמנת רכש, אינם שני תחומי כשל. הם תחום כשל אחד עם שתי חשבוניות.
שאלו את הספק בכתב: אילו מהנתיבים האלה מתפצלים, היכן, ומה ההתנהגות המתועדת כשהמקטע המשותף נכשל? הבטחה בעל פה בשיחת תכנון לא שורדת את התקלה שאתם מתכננים לקראתה.
תחום כשל 3: המסלול ששורד בלי IPsec
peering פרטי ו-IPsec יכולים להציע מסלולים מתחרים לאותו קידומת יישום. אם המסלול המוגן נעלם, ייתכן שמסלול ExpressRoute ישיר שנותר עדיין שמיש, בלי שכבת ההצפנה שהמנהרה סיפקה. אם זה מקובל זו החלטת מדיניות, והיא ההחלטה שנשארת לרוב מרומזת.
דרישות הצפנה ודרישות זמינות יכולות כאן להתנגש באמת. «כל מסלול ששורד נחשב להצלחה» היא אמירת זמינות שעונה בשקט לשאלת ההצפנה ב«לא». כתבו מי מנצח, לאילו קידומות, ומי אישר זאת.
az network vnet-gateway list-advertised-routes -g rg-connectivity -n gw-hub --peer 10.0.0.1
az network vnet-gateway list-learned-routes -g rg-connectivity -n gw-hub -o tableהשוו את המסלולים הנלמדים לקידומות שציפיתם להן. מסלול גיבוי שנושא עומס ניהולי קטן עשוי להיות מתאים לחלוטין לעומס הזה ורחוק מאוד מהקיבולת שהביקוש הייצורי צריך, אז רשמו את הנחת הקיבולת לצד המסלול.
רשמו שלוש שורות נפרדות, לא פסק דין אחד
החזיקו יתירות נקודת קצה, יתירות תעבורה והתאוששות מאסון כרשומות נפרדות ברישום התכנון, כל אחת עם המנגנון שלה, האימות שלה והבעלים שלה. כשסקירת תקלה שואלת למה החיבור שרד הפעלה מחדש של שער אבל לא חיתוך סיב, שלוש שורות עונות במשפט אחד; תיבת סימון אחת של «יתיר» לא יכולה.
אחר כך בדקו את השורות שאפשר לבדוק בזול. הפילו מנהרה אחת וודאו שהתעבורה עוברת ומוצפנת מחדש. הסירו מסלול אחד וודאו שהנתיב ששורד הוא זה שהתכוונתם אליו, ואז ודאו אם הוא עדיין מוצפן. תעדו את הכשלים שלא הצלחתם לדמות, כי שורה שלא נבדקה היא הנחה ויש לסמן אותה ככזו.
הפלט השימושי הוא טבלה קצרה ועוד משפט לכל שורה. אם לשורה אין מנגנון, זהו הממצא, והרבה יותר זול לגלות אותו בסקירת תכנון מאשר בזמן תקלת ספק ששתי המנהרות לעולם לא היו שורדות.