בדיקת NVA ב-Azure: מדוע התשובה עוברת דרך חומת אש אחרת

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

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

הפער הזה הוא כל הנושא כאן: התכנסות ניתוב ובעלות על מצב הסשן הן בעיות שונות שנראות זהות בתרשים.

מה Route Server באמת מתכנת

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

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

קרא את שני הכיוונים לפני שאתה מתכנן

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

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

היכן המצב חי

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

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

מודלי HA נתמכים ומה כל אחד מבטיח

Microsoft's guidance on כוונת הניתוב של Virtual WAN מתארת התנהגות מוגבלת לקישוריות דו-תפקידית ול-NVA של חומת אש, שבה ניתוב ישיר יכול לעקוף את האכיפה הסימטרית הרגילה של ה-hub. קרא את ההערות האלה כמגבלות על הטופולוגיה שבחרת, לא כאיסור על תכנונים פעילים-פעילים. זוג ספק שמסנכרן מצב, או מוביל לפי זרימה, יכול להיות נתמך. זוג בעלות שווה שאינו עושה אף אחד מהשניים אינו נתמך.

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

מה לבדוק לפני שסומכים על זה

Test with inspection enabled and מדיניות הגישה של עומס העבודה במקומה, מפני שכל אחד מהם יכול להסתיר את אי-הסימטריה. שלח זרימה מורשית חדשה בשני הכיוונים ואשר שאותו התקן ראה את שני החצאים. לאחר מכן הרץ תעבורה מתמשכת והפעל את המעבר המאושר, ותצפה אם הסשנים הקיימים שורדים או מתחברים מחדש.

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

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