VPN אתר לאתר בין AWS ל-Azure: כתבו קודם את נתיב החזרה
מנהרה מחוברת בין עננים לא מוכיחה דבר עד שכל תת-רשת עומס מנתבת אל הקידומת המרוחקת. עברו על התוכנית לפי הסדר ואז בדקו את השירות.
המנהרה תעלה. כך קורה בדרך כלל, כי IKE זקוק רק להצעות תואמות ולכתובת עמית נגישה. מה שנכשל אחר כך הוא נתיב החזרה: עומס העבודה ב-AWS שולח מנות לתוך מנהרה, אבל דבר בצד Azure לא יודע איך להשיב ל-10.10.0.0/16, או שהנתיב ב-Azure נמצא בטבלה שתת-הרשת של העומס לא משתמשת בה. כתבו את תוכנית הנתיבים לפני שנוגעים בכל קונסולה, והמנהרה תהפוך לחלק הכי פחות מעניין בעבודה.
שלב 1: הקפיאו את תוכנית הכתובות
עבדו עם ערכים קונקרטיים. עומס עבודה ב-AWS יושב על 10.10.1.20 בתוך 10.10.0.0/16 וזקוק ל-TCP 443 אל שירות Azure על 10.20.1.30 בתוך 10.20.0.0/16. שני הטווחים לא יכולים לחפוף, ומבחן הקבלה הוא זוג השירותים, לא המנהרה.
רשמו את ארבע העובדות האלה לפני כל דבר אחר, כי כל שלב מאוחר יותר נבדק מולן.
שלב 2: תנו שם לשער ששולט בכל קצה
AWS Site-to-Site VPN יכול להסתיים בשער פרטי וירטואלי או בשער מעבר, ואלה בעלי ניתוב שונים. Azure מציע את ה-VPN Gateway המנוהל שלו, ובנפרד מכשירים מבוססי VM שהלקוחות מריצים בעצמם. רשמו איזה זוג יש לכם, כי הקפיצה הבאה שונה בכל שילוב.
עבור שער מנוהל, אל תעתיקו נתיב שמצביע לכתובת מכשיר פרטי משוערת. עבור מכשיר, אל תניחו שהפצת נתיבים בענן מגדירה את מערכת ההפעלה האורחת, כי היא לא עושה זאת.
טעות כאן מייצרת תוכנית שנראית שלמה ומפנה מנות לכתובת שלעולם לא משיבה.
שלב 3: כתבו את הנתיב שכל עומס באמת משתמש בו
כל גבול למטה הוא חיפוש נפרד, ונתיב באחד מהם אינו נתיב עבור המנה. מלאו את הטבלה בערכים שלכם לפני שהמנהרה עולה לאוויר.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
ב-AWS, טבלת הנתיבים של תת-רשת העומס היא שלכם לעדכון גם אחרי ש-BGP או מנהרה תקינים; סקירת הניתוב רואה בכך חלק מהחיבור. ב-Azure, טבלת נתיבים מוגדרת על ידי המשתמש משויכת לתת-רשת ולא לרשת הווירטואלית, לכן בדקו את הנתיב האפקטיבי ב-NIC של העומס ולא בלהב ה-VNet.
שער Azure מנוהל יכול ללמוד את הקידומת המרוחקת דרך הפצת שער, ו-UDR יכול לעקוף את ההחלטה הזו. הוסיפו UDR כשיש לכם סיבה, לא מתוך הרגל. אם הוספתם, כוונו אותו לקפיצה הבאה שהשער מפרסם עבור נתיב ה-VPN במקום להמציא כתובת מכשיר. לאחר מכן קראו שוב את הנתיבים האפקטיביים ב-NIC, כי שם ההחלטה מתקבלת באמת.
שלב 4: יישרו את ההיקף
ב-BGP, השוו את מה שכל צד מכריז עם מה שהצד השני למד בפועל, קידומת מול קידומת. בניתוב סטטי, השוו את הטווחים המרוחקים שהוגדרו עם נתיבי העומס שכתבתם בשלב 3.
יחסי IKE שמסכימים על קריפטוגרפיה אינם הוכחה שצד כלשהו למד את 10.10.0.0/16 או 10.20.0.0/16. שתי מנהרות יכולות להיות למעלה בעוד צד אחד מכריז /24 בודד במקום ה-/16 שתיכננתם. בדקו את הקידומת בטבלת הניתוב, לא במצב המנהרה. אי-ההתאמה מתגלה מאוחר יותר כתת-רשת אחת שעובדת ואחת שלעולם לא משיבה.
שלב 5: בדקו את השירות מהמקור האמיתי
אפשרו את הזרימה המיועדת בקבוצות האבטחה וב-ACL של הרשת ב-AWS, ב-NSG של Azure ובכל מסנן מכשיר בנתיב. לאחר מכן פתחו חיבור אחד מ-10.10.1.20 לכתובת השירות והפורט המאושרים וודאו שהתשובה חוזרת לאותו מקור.
גם קבוצות האבטחה בענן וגם ה-NSG הם stateful, כך שמנה חוזרת שנדחתה היא סימפטום ניתוב, לא כלל ששכחתם לכתוב בכיוון ההפוך.
ping מכל שער לא מכריע דבר. ICMP לכתובת שער מתרגל את נתיב מישור הבקרה, לא את שירות ה-TCP המועבר שהעומס זקוק לו.
חזרה לאחור ותיעוד
רשמו את בעלי הנתיבים לצד מזהי המנהרה ושמרו את טבלאות הנתיבים מלפני השינוי. אם השינוי חייב לצאת, הסירו את נתיבי העומס לפני פירוק המנהרה, כדי שאף תת-רשת לא תישאר מפנה לקפיצה הבאה שכבר אינה קיימת.
אז העברה מאוחרת של תת-רשת או חיבור spoke יש לה מקום מוגדר אחד לעדכון, במקום מנהרה עובדת שנושאת את האשמה על נתיב שמעולם לא היה שלה.