GCP HA VPN: סשן BGP נתקע ב-Waiting for peer, החלפת זוג הכתובות
סשן BGP של Cloud VPN שנתקע ב-Waiting for peer בדרך כלל החליף בין כתובת המנהרה לכתובת העמית. בדקו את הזוג לפני שאתם בונים משהו מחדש.
סשן BGP שלעולם אינו מגיע ל-Established במנהרת Cloud VPN הוא בדרך כלל לא בעיית ניתוב. זו בעיית חיווט: שתי כתובות שאמורות לשקף זו את זו הוזנו בסדר הפוך, או שהזוג של המנהרה הראשונה שימש שוב בשנייה. המנהרה עצמה יכולה להיות תקינה לחלוטין בזמן שהסשן עומד ב-Waiting for peer, כי IPsec ו-BGP הם משאים ומתנים נפרדים בין אותן שתי נקודות קצה. החליטו איזה משתי אלה שבור לפני שאתם בונים משהו מחדש.
שאלה אחת מכריעה את רוב המקרים: האם התקן העמית רואה בכלל את הכתובת של Cloud Router?
מצב המנהרה ומצב הסשן הם בדיקות שונות
קודם באים IKE ו-ESP. אם המנהרה אינה מוקמת, שום דבר בתוכה לא חשוב והדיון בכתובת BGP מוקדם מדי. קראו את המצב ואת המצב המפורט של המנהרה, ואחר כך את מצב עמית ה-BGP של הנתב עבור אותה מנהרה.
מנהרה שעובדת בזמן שעמית ה-BGP שלה מושבת מצמצמת את התקלה לסשן: כתובת העמית, ASN או TCP 179 שמגיע לכתובת הפנימית. מנהרה עובדת, סשן עובד ועדיין אין נתיבים ב-VPC זהו מקרה שלישי. שינוי כתובות לא יעזור שם, כי הסשן כבר עובד והקידומת פשוט אינה מוכרזת או אינה מועדפת. שמירה על שלושת המקרים בנפרד היא רוב העבודה.
כל מנהרה זקוקה ל-/30 משלה, עם שני הקצוות מלאים
כל מנהרת HA VPN מקבלת /30 link-local מתוך 169.254.0.0/16, כתובת אחת על ממשק ה-Cloud Router והשנייה על העמית שלכם. שדה העמית חייב לנקוב בקצה המרוחק, ולעולם לא בכתובת של הנתב עצמו.
שתי מנהרות פירושן שני ממשקים ב-Cloud Router, כל אחד עם /30 אחר. שימוש חוזר בזוג של מנהרה 0 במנהרה 1 הוא הטעות שנראית מסודרת בטבלת סיכום ומתה במנות OPEN.
| Tunnel | Router interface | Peer address | What a swap produces |
|---|---|---|---|
| tunnel 0 | 169.254.1.1/30 | 169.254.1.2 | OPEN sent to itself or to nothing; session waits |
| tunnel 1 | 169.254.1.5/30 | 169.254.1.6 | same failure on the second session |
| both | one pair reused | one address reused | one session up, the other never leaves waiting |
קראו את הזוג ממשאב הנתב ולא מסיכום המסוף. הסיכום מציג את כתובת העמית בעמודה שקל לקרוא בטעות, וה-ipRange של הממשק יחד עם ה-peerIpAddress של העמית חייבים לתאר קצוות מנוגדים של /30 אחד.
ההחלפה מתרחשת בדרך כלל בזמן בנייה מחדש
בזמן בנייה מחדש של מנהרה הזוגות מצטלבים. כתובת העמית של המנהרה הישנה מועתקת לשדה הממשק של החדשה, או שהסשן החדש מופנה לעמית של הסשן הקודם. כך או כך, Cloud Router שולח מנות OPEN לכתובת שכעת היא הוא עצמו או לכתובת שאין מאחוריה מנהרה.
רשמו את הזוגות לפני פתיחת המסוף: שם המנהרה, ממשק, כתובת הנתב, כתובת העמית, ASN של העמית. אחר כך צרו את שתי המנהרות במעבר אחד, כדי שהשנייה לא תימלא משאריות הראשונה.
שלוש סיבות נוספות לכך שהסשן ממתין
ה-ASN של העמית הוא הראשון: כל צד חייב להיות מוגדר עם ה-ASN של הצד השני, וחוסר התאמה מגיע לעמית אך אינו מתבסס לעולם. השנייה היא חומת האש של העמית עצמו, שחייבת לאפשר TCP 179 בממשק המנהרה; כלל IKE או ESP אינו מכסה זאת. השלישית היא עמית שמשיב מכתובת מקור אחרת מזו שהוגדרה כשכן שלו.
היומן של העמית עצמו הוא המבחין. אם סיכום ה-BGP שלו אינו מפרט שכן לכתובת הזו, המנות אינן מגיעות והזוג או הנתיב שגויים. אם השכן נמצא ב-Active או ב-Connect, המנות מגיעות ופרמטרי הסשן אינם תואמים.
בדקו לפי הסדר שבו המנות עוברות
עבדו החוצה: מצב המנהרה, אחר כך מצב עמית ה-BGP של הנתב, אחר כך סיכום ה-BGP של העמית, אחר כך הנתיבים. אם הראשון והשני תקינים, הפסיקו לערוך את צד Cloud VPN ועבדו על התקן העמית. אם הנתב מדווח שהעמית מושבת ובהתקן שלכם אין שכן, הזוג שגוי או שפורט BGP מסונן. לכידת מנות בממשק המנהרה של העמית מכריעה את זה במבט אחד, כי מנות OPEN או מגיעות לשם או שאינן מגיעות לעולם.
הפקודה gcloud compute routers get-status ROUTER --region=REGION מדפיסה את מצב העמית לצד הכתובת שהוא משתמש בה, וזה בדיוק הזוג שעליכם להשוות.
לאחר שהסשן מתבסס, ודאו שהקידומת שנלמדה מופיעה בטבלת הנתיבים של VPC ושמארח אחד בכל צד משיב. אחר כך רשמו את הזוגות הסופיים לצד שמות המנהרות, כדי שהבנייה מחדש הבאה תתחיל מטבלה שנבדקה ולא מסיכום המסוף.