ניתוב תעבורה בין שני סניפים דרך שער VPN של Azure
שני חיבורי Site-to-Site על שער VPN אחד של Azure יכולים להעביר תעבורת סניפים, אבל רק כאשר שני הקצוות לומדים את הקידומת וקיים נתיב חזרה ב-LAN.
שני סניפים יכולים להחליף תעבורה דרך שער VPN של Azure בלי שום מנהרה ישירה ביניהם. כל סניף פותח חיבור Site-to-Site לאותו שער, והשער מעביר את הקידומות הנלמדות בין שני החיבורים. מה שגורם לזה לעבוד אינו המנהרה השנייה אלא החלפת המסלולים: סניף A חייב ללמוד את הקידומת של סניף B, ו-B את זו של A. עברו על הבדיקות שלהלן לפי הסדר ועצרו בראשונה שנכשלת, כי כל שלב מאוחר יותר תלוי בה.
תנאים מוקדמים, לפני שמגדירים משהו
ארבעה תנאים קובעים אם התכנון הזה יכול לעבוד בכלל. השער חייב להיות מבוסס מסלולים וב-SKU שתומך ב-BGP, בשני החיבורים חייב להיות BGP מופעל, מרחבי הכתובות של הסניפים לא יכולים לחפוף, ואף צד לא רשאי להסתמך על NAT כדי להסתיר את הקידומת האמיתית שלו.
תכננו את ה-ASN בכוונה. ברירת המחדל המתועדת של Azure היא 65515, וכל נתב סניף זקוק ל-ASN פרטי משלו שאינו מתנגש בשער או בסניף השני. שימוש חוזר בברירת מחדל בלי לבדוק תצורת שער קיימת הוא הדרך שבה מסלול AS נדחה מאוחר יותר.
ודאו גם שאינכם מצפים להתנהגות peering של VNet. השער מחליף מסלולים בין שני החיבורים שהגדרתם; הוא לא הופך peerings שרירותיים לטרנזיטיביים. אם רשת שלישית צריכה להגיע לשני הסניפים, היא זקוקה לחיבור משלה או לנתיב משלה, לא להנחה שהשער יפזר את התעבורה. רשמו את הגבול הזה לפני חלון השינוי הראשון, כי זו החלטת התכנון שאליה אנשים חוזרים כשמוסיפים אתר מאוחר יותר.
הגדירו לפי הסדר הזה
לכל שלב יש תוצאה ניתנת לצפייה, אז אל תמשיכו עד שהיא תופיע.
- הפעילו BGP בשער הרשת הווירטואלית ורשמו את ה-ASN ואת כתובת ה-peer שלו.
- צרו שער רשת מקומי לכל סניף עם מרחב הכתובות האמיתי של אותו סניף, ה-ASN שלו וכתובת ה-peer שלו ל-BGP.
- צרו כל חיבור Site-to-Site והפעילו BGP על החיבור עצמו.
- הגדירו את נתב הסניף לעשות peering עם כתובת השער ש-Azure הקצה, ולא עם נקודת הקצה הציבורית של IKE של השער לפי הנחה.
השלב הרביעי הוא המקום שבו רוב הניסיונות נתקעים. כתובת ה-peer של BGP ש-Azure מדווחת היא זו שנתב הסניף חייב להשתמש בה כשכן, והיא לא תמיד הכתובת שאנשים מצפים לה מתרשים המנהרה.
פרסמו את קידומת הסניף עצמה, למשל 10.10.0.0/16 מ-A ו-10.20.0.0/16 מ-B. אל תפרסמו מסלול ברירת מחדל או אגרגט רחב כדי לכסות רשת ספציפית חסרה; הפער חוזר מאוחר יותר כחור שחור שקט.
אמתו את החלפת המסלולים בשני הקצוות
מצב החיבור אינו הבדיקה. IPsec יכול להיות פעיל בשני החיבורים בעוד שאף קידומת לא עוברת ביניהם. קראו את ה-peers של BGP בשער ואת המסלולים הנלמדים שלו, ואז אשרו שהמסלול לעבר הסניף השני מופיע כנתיב שמיש.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
קידומת שנמצאת בטבלת BGP עדיין יכולה להפסיד את החלטת ההעברה למסלול סטטי או לקידומת ספציפית יותר. בדקו את המסלול הנבחר, לא רק את זה שהתקבל.
עקבו אחר נתיב החזרה בצד ה-LAN
זה החלק שנראה נכון ב-Azure ונכשל בשטח. מארח בסניף A שולח את החבילה שלו לנתב ה-VPN של A רק אם הנתב הזה הוא שער ברירת המחדל שלו, או אם למארח או לשער שלו יש מסלול לקידומת של B. אותו דבר חייב להיות נכון גם בכיוון ההפוך.
אם מתג ליבה נפרד הוא שער ברירת המחדל של ה-LAN, הוא זקוק למסלול לעבר הסניף השני שמצביע על נתב ה-VPN. בלעדיו הבקשה מגיעה והתשובה יוצאת דרך נתיב האינטרנט, והמשתמש רואה חיבור שנפתח ואז נתקע.
אל תפנו לקבוצת אבטחת רשת בתת-הרשת של השער כדי לתקן זאת. לתת-הרשת הזו יש דרישות משלה ו-NSG שם אינו תחליף נתמך למדיניות בצד הסניף. הסינון שייך לחומות האש של הסניפים ולעומסי העבודה עצמם, שם בעלי הכללים יכולים לסקור אותם. העברת הכללים האלה ל-NSG של תת-רשת גם מסתירה אותם מהצוות שיאבחן את התקלה הבאה.
אשרו את הפעולה, ואז הוכיחו אותה בבדיקה שנדחתה
מסלול נלמד אינו הרשאה. אשרו את המקור, היעד והשירות שבהם אתם באמת צריכים להשתמש דרך חומות האש של הסניפים ומדיניות נקודת הקצה, והשאירו את השאר אסורים.
בדקו מעומס עבודה רגיל בסניף A לשירות אמיתי בסניף B, אשרו את התשובה, ואז נסו פעולה שאמורה להישאר אסורה. תעבורה שנוצרת על ידי מכשיר ה-VPN עצמו יכולה להשתמש בכתובת מקור אחרת ולדלג על שלב הניתוב ב-LAN, ולכן ping מוצלח מהנתב מוכיח פחות ממה שהוא נראה.
סיימו בכתיבת ארבע עובדות: הקידומות שהוחלפו, ה-ASN שבשימוש, נתיב החזרה ב-LAN לכל צד, והמדיניות שמתירה את השירות. אם אחד מהם חסר, התצורה עובדת עד השינוי הראשון, ואז אף אחד לא יכול להסביר למה.