UDR ב-Azure אל שער VPN: יעד אחד, לא כל התעבורה היוצאת

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

הקפיצה הבאה היא שער, לא כתובת IP של מכשיר

UDR שולח קידומת תואמת לסוג קפיצה הבאה, ו-VirtualNetworkGateway הוא סוג ולא כתובת. אנשים מדביקים את כתובת ה-IP הפרטית של השער במסלול VirtualAppliance ואז תוהים מדוע דבר לא תואם, כי הסוג הזה מצפה ל-NIC או למאזן עומסים פנימי במקום. התיעוד של Microsoft לניתוב גם מגביל את קפיצת השער הבאה לרשת וירטואלית שהשער שלה הוא שער VPN. ExpressRoute, Route Server ורכזת Virtual WAN אינם מטופלים באפשרות הזו.

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

קראו את המסלול האפקטיבי לפני שאתם משנים משהו

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

הסתכלו קודם על הטבלה האפקטיבית, ואז החליטו אם אתם מוסיפים מסלול או מחליפים אחד:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

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

כתבו את המסלול מול הקידומת והתת-רשת האמיתיות

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

צרו את המסלול, ואז קשרו את הטבלה לתת-הרשת שמארחת את העומס:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

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

השלימו את החצי המקומי או שהזרימה תמות שם

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

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

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

אמתו לפי המקור שהיעד רואה

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

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