מסלול GCP VPN עובד רק באזור אחד: בדקו ניתוב דינמי
VPC גלובלי לא הופך מסלולים שנלמדו ב-BGP לגלובליים. קראו את מצב הניתוב, שנו אותו פעם אחת ובדקו מה הצד המרוחק מכריז.
עומס העבודה בארצות הברית מגיע לקידומת המשרד דרך ה-HA VPN בלי בעיה, בעוד שעומס העבודה האירופי באותו VPC לא מקבל דבר. טבלת הניתוב שלו אינה מכילה רשומה עבור הקידומת, שום מנהרה לא נפלה, ואף כלל חומת אש לא השתנה. המנהרה והפעלת ה-BGP שלה תקינות בשני הכיוונים. VPC שמשתרע על פני אזורים אינו אותו דבר כמו המסלולים הנלמדים שלו שמשתרעים על פני אזורים, והפער הזה מסביר את כל הסימפטום.
שני מאפיינים מתבלבלים כאן: היכן נמצאות תת-הרשתות, והיכן מותר להשתמש בקפיצה הבאה שנלמדה.
מאין מגיע ההיקף האזורי
Cloud Router מתקין מסלולים נלמדים בהיקף שעוקב אחר מצב הניתוב הדינמי של ה-VPC. במצב אזורי, מסלול שנלמד באזור אחד שמיש רק למשאבים של אותו אזור, ולכן הטבלה האירופית ריקה במקום להציג קפיצה הבאה שבורה. במצב גלובלי, מסלולים נלמדים כשירים נעשים זמינים למשאבים בכל אזור של ה-VPC. קראו את הערך הנוכחי לפני שינוי כלשהו, מפני שהאזורי הוא ברירת המחדל. ההגדרה נמצאת ברשת, לא במנהרה ולא בנתב.
פקודת המלאי היא לקריאה בלבד ועונה על כך בשורה אחת:
gcloud compute networks describe VPC_NAME --format='value(routingConfig.routingMode)'
הריצו אותה בפרויקט המארח כאשר ה-VPC משותף. הרשת שייכת לאותו פרויקט, ותפקיד צופה בפרויקט עומס העבודה אולי אפילו לא יציג את תצורת הניתוב. תשובה מהירה מהפרויקט הלא נכון גרועה מאין תשובה.
השינוי הוא פקודה אחת וכיוון אחד
ההחלפה היא עריכה של מישור הבקרה בכל ה-VPC, ולא מעקף לכל VM: gcloud compute networks update VPC_NAME --routing-mode=GLOBAL. היא גם חד-כיוונית, מפני שרשת שהוגדרה כגלובלית אינה יכולה לחזור לאזורית. בדקו שוב את שם הפרויקט והרשת לפני ההרצה, מפני שהפקודה אינה מבקשת אישור. השינוי ראוי להערת תחזוקה ולאישור של בעל הרשת, ולא לניסוי מהיר על VPC משותף.
כל חיבור Cloud Router, VPN ו-Interconnect באותה רשת יורש את ההיקף החדש בבת אחת. זה כולל את החיבורים שאיש לא הזכיר בבקשת השינוי. אזורים שמעולם לא היו להם המסלול מתחילים לקבל אותו ברגע השינוי נכנס לתוקף, ולכן אין פריסה מדורגת להחלפה הזו.
גלובלי הוא היקף, לא הבטחה
כשירות והעדפה נפרדות מההיקף. מסלול שמתנגש בקידומת ספציפית יותר, מפסיד בבחירת המסלול הטוב ביותר או מסונן על ידי מדיניות מתנהג בדיוק כמו קודם. המצב הגלובלי מרחיב היכן מותר להשתמש במסלול, אך אינו קובע איזה מסלול ינצח. מסלול נלמד יכול להיות בתוך ההיקף ובכל זאת להפסיד למסלול סטטי או ספציפי יותר באותו VPC.
ההבחנה הזו חשובה מפני שקל להאשים את שינוי המצב מאוחר יותר. אם תת-הרשת האירופית עדיין ללא מסלול לאחר ההחלפה, השאלה היא אם המסלול קיים וכשיר, ולא אם ההיקף נכנס לתוקף. התנגשויות קידומת ובריאות הקפיצה הבאה הן שני הדברים הבאים לקרוא.
הצד המרוחק מכריז גם אחרת
התנהגות ההכרזה עוקבת אחר אותה הגדרה. בהתנהגות ברירת המחדל, נתב במצב אזורי מכריז את תת-הרשתות של האזור שלו, בעוד שהמצב הגלובלי מכריז על תת-הרשתות של ה-VPC באופן רחב יותר. לכן שינוי המצב משנה לא רק מה שהאזורים שלכם רשאים להשתמש בו, אלא גם מה שהצד המרוחק מתקין.
רשימת הכרזה מותאמת אינה מתרחבת כאשר המצב משתנה. אם הנתב המקומי מחזיק רשימה כתובה ביד של טווחים, הקידומת האירופית נשארת חסרה בה. נתיב החזרה נשאר שבור במקרה הזה למרות שמסלול היציאה קיים כעת. בדקו מה הצד המרוחק התקין ולא מה ייצאתם.
מה המצב לעולם לא יתקן
ניתוב גלובלי אינו מעניק גישה לאינטרנט הציבורי, מעבר בין VPC לא קשורים או מסלולים סטטיים חסרים. הוא אינו משנה כללי חומת אש או IAM, ולכן חיבור שנדחה על ידי מדיניות נשאר נדחה.
הכשלים האלה נראים אותו דבר מבפנים של עומס עבודה ואין להם שום קשר להיקף המסלולים.
בדקו מהאזור המרוחק אל השירות האמיתי, ואז אשרו שהתשובה חוזרת דרך המנהרה המיועדת. תעדו את המצב, את תצורת ההכרזה ואת היעד שבדקתם. אם הבדיקה עדיין נכשלת, השוו את טבלת ה-BGP של הנתב המרוחק לרשימת המסלולים של ה-VPC לפני שנוגעים שוב במצב. אז הדוח הבא בין אזורים מתחיל מעובדות ולא משינוי מצב.