למה BGP מעל VPN לא שולט בנתיב שכבת התשתית שלך
BGP מעל VPN מחליף נגישות ומיישם מדיניות נתיבים, אבל שכבת התשתית עדיין בוחרת את הנתיב החיצוני. מה הסשן באמת שולט בו.
שני אתרים עושים peering של BGP דרך מנהרת IPsec, לומדים את הקידומות זה של זה, והתרשים מתויג מחדש כשליטה בנתיב. התווית הזו היא מקום שבו מתחילה הבלבול. הסשן אכן מחליף נגישות ואכן מיישם מדיניות, אבל אין לו אומר לגבי איזה ספק, כבל או נתב נושא את החבילות המוצפנות. ראיתי צוות בונה מחדש מנהרה עובדת כי הם ציפו ששינוי נתיב BGP יעביר את התעבורה לנתיב סיב אחר שהסשן לא יכול היה להשפיע עליו לעולם.
מה אנשים מניחים שסשן קונה
רוב הציפייה נובעת מאיך שנראה שינוי נתיב במעבדה. אתה מפרסם קידומת דרך המנהרה, הצד הרחוק מתקין אותה, והתעבורה זזה. אותו רצף קורה בנתב שבאמת יש לו ידיות הנדסת תעבורה, ולכן השניים מתבלבלים. במעבדה שני האתרים בדרך כלל חולקים קישור גישה אחד, וזו בדיוק הסיבה שההבדל לא מופיע שם לעולם.
BGP הוא פרוטוקול נגישות. הוא אומר לעמית שאתה יכול לספק חבילות לקידומת ומאפשר לכל צד לדרג את ההצעות שהוא מקבל. זה באמת שימושי דרך מנהרה: קידומות מופיעות ונעלמות כשאתרים באים והולכים, ואתה יכול לסרב לטווח בלי לכתוב נתיב סטטי בכל התקן קצה. מה שהוא לא עושה זה להעמיד את הנתבים של ספק תחת השליטה שלך.
שכבת התשתית נושאת את הכותרת החיצונית. נקודת הקצה של המנהרה שלך שולחת חבילות מוצפנות לכתובת עמית, והרשת בין שתי הכתובות האלה מעבירה אותן לפי הנתיבים שהמפעילים שלה התקינו. שום דבר בסשן BGP לא משנה את ההחלטה הזו, אלא אם אותו ספק מציג שירות נתמך שעושה זאת.
מה הסשן באמת נושא
דובר BGP פותח חיבור TCP לפורט 179 אצל העמית שלו, תוך שימוש בפורמטי ההודעות ובמאפייני הנתיב המוגדרים ב-RFC 4271. כשכתובת העמית נמצאת בתוך המנהרה, המנהרה חייבת להיות למעלה והכתובת חייבת להיות נגישה לפני שהסשן בכלל יכול להתחיל. החלפת IKE שהושלמה אינה שכן BGP. מימושי IPsec מבוססי נתיב מעבירים תעבורה רק כשקיים נתיב מנהרה תואם, וזה מבוסס המדיניות צריך את כתובת העמית בתוך הסלקטור המוגן. הפיכת הסדר הזה יוצרת את המצב הקלאסי שבו המנהרה ירוקה והסשן יושב בטל.
ברגע שהסשן למעלה, המדיניות מחליטה מה חוצה אותו. רשימות קידומות, מסנני AS-path, תקרת מספר קידומות מקסימלי והחלטה מפורשת לגבי נתיבי ברירת מחדל הם המינימום, והם חלים בשני הכיוונים. עמית שמקבל כל מה שהוא מקבל יכול לתת לך נתיב ברירת מחדל שמחליף בשקט גישה מקומית לאינטרנט. שני הכיוונים צריכים רשימות נפרדות, כי מה שאתה מקבל מעמית ומה שאתה מפרסם לו הם החלטות שונות.
router bgp 65010
neighbor 10.255.0.2 remote-as 65020
address-family ipv4 unicast
neighbor 10.255.0.2 prefix-list SITE-B-IN in
neighbor 10.255.0.2 prefix-list SITE-B-OUT out
neighbor 10.255.0.2 maximum-prefix 50
הבא בתור נושך ה-MTU. ההצפנה מקטינה את המטען השמיש, כך שעדכון גדול יכול לתקוע סשן שנראה מבוסס לחלוטין: העמית נשאר למעלה, קידומות לא מגיעות לעולם, ושום דבר ברור לא נרשם ביומן. הגבל את TCP MSS בממשק המנהרה, או קבע MTU למנהרה עם מקום לתקורה, לפני שאתה מאשים את המסננים.
לאן החבילות החיצוניות עדיין הולכות
חבילות מוצפנות מאתר אחד לאחר יוצאות דרך מה שהנתב המקומי בוחר לכתובת הציבורית של העמית. אם שני האתרים קונים טרנזיט מאותו ספק, חוצים את אותו מתקן מטרו, או שצד אחד יושב מאחורי NAT ברמת ספק, המנהרה שורדת כשל ספק רק במקרה. ספירת סמלי מנהרות בכלי ניטור לא אומרת לך דבר על זה.
בחירת נתיב והתקנת העברה הם גם אירועים נפרדים. קידומת יכולה לשבת בטבלת BGP כטובה ביותר ועדיין להיות חסרה בטבלת ההעברה, כי הקפיצה הבאה אינה ניתנת לפתרון או שנתיב ספציפי יותר מנצח. כשמישהו מדווח ש-BGP למד את הקידומת אבל התעבורה לא זורמת, השאלה המועילה היא אם היא מותקנת ולאיזו קפיצה הבאה היא מצביעה.
התשובה הכנה לסקירת תכנון היא רשימה של תלויות משותפות: מעגל גישה, ספק במעלה הזרם, מתקן וכל התקן עם מצב בנתיב החזרה. סשן דרך המנהרה לא יכול להסיר תלות שהוא לא יושב מעליה.
שלוש החלטות ששווה להפריד
כשתכנון מערבב את אלה, כל שיחה על תקלה הולכת במעגלים. הפרידו אותם קודם על הנייר, ואז מפו כל אחד להתקן שבאמת אוכף אותו.
| Decision | Who controls it | Typical failure |
|---|---|---|
| Which prefixes may cross the relationship? | Both sides, through prefix and AS-path policy you configure deliberately | A default route accepted by mistake, or a vague aggregate |
| Which overlay next hop wins? | Local BGP selection plus next-hop resolution on your own routers | Prefix learned, never installed in the forwarding table |
| Where do the encrypted packets travel? | The underlay operators, unless a supported service adds real control | Path diversity that was never there |
לכל שורה יש בעלים אחר. הראשונה היא משא ומתן, השנייה היא תצורה בהתקנים שלך, השלישית היא בעיקר הרשת של מישהו אחר. בקשת שינוי שמציינת את השורה שהיא נוגעת בה קלה הרבה יותר לאישור מזו שאומרת בעיית BGP.
מצבי כשל ששווה לתכנן לקראתם
קבלת נתיב סיכום של עמית היא הפצע העצמי הנפוץ ביותר. מישהו מפרסם אגרגט קצר כדי לפשט את ההחלפה, הצד הרחוק מקבל אותו, ותעבורה לטווחים שאינם מאחורי המנהרה עוקבת אחרי המנהרה ומתה. סנן לפי הקידומות המדויקות הצפויות, או השתמש ברשימת קידומות עם הגבולות הנכונים, ולעולם אל תקבל אגרגט חשוף כי הוא גורם לסשן להיראות מסודר.
תזמון הנסיגה הוא השני. הזיהוי תלוי בטיימרי החזקה, ב-BFD אם הפעלת אותו, בזיהוי עמית מת של המנהרה ובכמה מהר הצד הרחוק מפסיק לפרסם. סשנים קיימים הם בעיה נפרדת: נתיב חדש עשוי לשחזר חיבורים חדשים בעוד שסשני TCP מבוססים ממשיכים להשתמש בכתובות מיושנות, וחומות אש עם מצב או NAT בנתיב עשויים להחזיק רשומות שכבר לא תואמות. שים את התאוששות היישום בקריטריוני הקבלה במקום להניח ששינוי נתיב מסדר הכול.
השלישי הוא אסימטריית נתיב החזרה. תעבורה יכולה להגיע דרך המנהרה ולחזור דרך קישור ספק שמעולם לא נועד לשאת אותה, מה שמתבטא באודיו חד-כיווני, לחיצות ידיים כושלות או חומת אש שמפילה תגובות. בדוק את שני הכיוונים בנפרד.
מה לכתוב בחוזה, ואיך לאמת אותו
בקש את הקידומות המותרות בכתב: מי מורשה ליצור כל טווח, אם נתיב ברירת מחדל מותר, ואילו משפחות כתובות שירות המנהרה תומך בהן. RFC 8212 הפך מדיניות ייבוא וייצוא מפורשת לציפייה עבור eBGP במימושים שעוקבים אחריו, ולכן עמית שעדיין מסתמך על התנהגות מרומזת של קבלת הכול ראוי לשאלה.
ואז אמת מההתקן ולא מהתרשים. פקודות שימושיות בנתבים בסגנון FRR:
show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16
הוסף שתי תצפיות שטבלת הניתוב לא יכולה לתת לך. תפוס בממשק החיצוני כדי לאשר לאיזו כתובת החבילות המוצפנות באמת מכוונות, למשל tcpdump -ni eth0 udp port 51820 למנהרת WireGuard, או מסנן ESP ל-IPsec. ואז עקוב אל הכתובת הציבורית של העמית והשווה בין הקפיצות לבין מסלול מעקב בתוך המנהרה; אם שניהם עוקבים אחרי אותה שרשרת ספק, היתירות שלך חיה במדיניות הניתוב ולא ברשת.
לבסוף, בדוק נסיגה בכוונה. הורד את המנהרה במהלך חלון תחזוקה, רשום כמה זמן הקידומת נשארת מותקנת, מה קורה לסשנים קיימים והאם הצד הרחוק נופל חזרה לנתיב שבאמת היית מקבל. התרגיל הזה אומר יותר על התכנון מכל תרשים.
נתיב אינו הרשאה. הקידומות שאתם מסכימים להחליף לא אומרות דבר על אילו משתמשים רשאים להגיע לאיזה שירות מאחורי המנהרה, אז השאר אימות, שירותים מותרים וחומות אש של מארחים בדיוק במקום שבו היו. עמית נגיש גם אינו הרשאה לטרנזיט בלתי מוגבל או ליצירת כתובות שרירותיות, וסוג כזה של סמכות שייך לחוזה כשאלה מסחרית, לא לשורת מדיניות BGP.
- נקוב בשמות הקידומות שכל צד רשאי ליצור, ואלה שאסור לו לקבל לעולם.
- הגבל את MSS במנהרה ואשר שעדכונים גדולים באמת מגיעים.
- פרט את התלויות המשותפות של שכבת התשתית, לא את מספר המנהרות.
- מדוד נסיגה אמיתית ורשום מה היישום עושה.