פרסומי BGP של VGW מול טבלת המסלולים של VPC: מה משנה מה

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

תנו שם לצירוף לפני שאתם קוראים טבלה כלשהי

VPN מאתר לאתר מסתיים או בשער פרטי וירטואלי או בשער מעבר, ומזהי המשאבים קובעים איזו מודל ניתוב חל. קראו אותם קודם: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. התשובה אומרת לכם אם הטבלה הבאה שיש לבדוק היא טבלת מסלולים של VPC או טבלת מסלולים של שער מעבר.

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

הכיוון מ-AWS למשרד הוא פרסום

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

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

הכיוון מהמשרד ל-AWS הוא הפצה ועוד בחירה

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

קראו את המקור במקום להניח אותו: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. רשומה שמקורה EnableVgwRoutePropagation הגיעה מ-BGP; רשומה שמקורה CreateRoute הוקלדה בידי אדם ותמשיך לנצח עד שמישהו ימחק אותה.

Runbook שמחזיק את שני הכיוונים בנפרד

רשמו ארבע עובדות בצד AWS לפני שתשנו משהו: סוג הצירוף, בלוקי ה-CIDR המשויכים של ה-VPC, מקור מסלול תת-הרשת לקידומת הנדונה, ומצב המנהרה וה-BGP. אותה קריאת describe מחזירה VgwTelemetry עם ספירת מסלולים שהתקבלו לכל מנהרה, מה שאומר לכם אם AWS קיבל בכלל מסלולים. לאחר מכן השוו זאת למה שהתקן הלקוח התקין בפועל. קידומת שנמצאת ב-BGP אך חסרה בטבלת ההעברה היא בעיית ייבוא מקומית או מסלול מיטבי, לא בעיה של טבלת מסלולים ב-AWS.

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

מה לא לשנות בזמן שאתם שם

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

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

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