למה סשן ה-BGP שלכם לא מופיע בטבלת הניתוב של ה-VPC

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

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

המיתוס: העלו את BGP וה-VPC ילמד את הקידומות

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

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

Route Server הוא מישור בקרה, לא מנהרה

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

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

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

ההפצה היא לפי טבלת ניתוב, לא לפי VPC

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

בדקו את הטבלה האפקטיבית של תת-הרשת הספציפית ולא את רשימת הקידומות שהמכשיר מכריז עליהן. ה-API עונה על השאלה הזו ישירות: aws ec2 associate-route-server ו-aws ec2 enable-route-server-propagation --route-table-id <id> הם שני השלבים שאנשים שוכחים, ו-aws ec2 describe-route-tables --route-table-ids <id> מראה אם הקידומת הגיעה בכלל כרשומת route server.

המכשיר עדיין נושא כל מקטע

להכריז על נגישות זה לא אותו דבר כמו להחזיק בה. סשן BGP יכול להישאר מבוסס בזמן שה-VPN של המכשיר למטה, והכרזה סטטית שלא משתנה לעולם ממשיכה למשוך תעבורה אל מסלול מת. Route Server תומך בזיהוי כשלים כמו BFD, אבל זה בודק את החיות של העמית, לא את הבריאות של כל מה שמאחוריו.

קשרו את ההכרזה למסלול המרוחק האמיתי: הכריזו על הקידומת כשהמנהרה והרשת המרוחקת למעלה, ומשכו אותה כשהן לא.

משכו קידומת וראו מה קורה

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

העברת מסלול למכשיר שני לא מעבירה את הסשנים שהוא נשא, כי מצב NAT וחומת האש נשאר במכשיר הראשון.

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