GCP Classic VPN ב-Terraform: הפכו את המנהרה למבוססת נתיב

ב-Classic VPN התווית לא קובעת את ההתנהגות. מבוסס נתיב פירושו בורר מקומי 0.0.0.0/0, בוררים מרוחקים תואמים ונתיב מפורש.

התוכנית מיושמת נקי, המנהרה עולה, והקונסולה מכנה אותה מבוססת מדיניות. התעבורה עדיין לא עוברת, והחיפוש אחר מתג מבוסס נתיב במשאב Terraform לא מוביל לשום מקום כי שדה כזה לא קיים. ב-Classic VPN, התנהגות מבוססת נתיב אינה מצב שבוחרים. זה מה שמקבלים כאשר בורר התעבורה המקומי הוא 0.0.0.0/0, הבוררים המרוחקים מפרטים את הרשתות שבאמת רוצים, ונתיב מצביע אל המנהרה. שלושה דברים, והתווית אחריהם.

המיתוס: שדה מצב מנהרה

התווית בקונסולה משקפת את מה שה-API רואה בבוררים. שום דבר במשאב לא אומר מבוסס נתיב, ולכן אין מה להגדיר לערך אמת.

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

מה משמעות מבוסס נתיב כאן

Google מתעדת מנהרות Classic VPN מבוססות נתיב כמנהרות מבוססות מדיניות שהבורר המקומי שלהן הוא 0.0.0.0/0. רק הטווחים המרוחקים נקראים בשמם, והצד המקומי מטופל ככל כתובת. לכן הסמן בתצורה שלכם הוא ערך ולא מצב. כתבו את שני הבוררים במפורש וקראו אותם בפלט התוכנית:

local_traffic_selector  = ["0.0.0.0/0"]
remote_traffic_selector = ["10.20.0.0/16"]

קידומת העמית בקטע הזה היא להמחשה; הצורה היא החלק החשוב.

הנתיב הוא אובייקט נפרד

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

resource "google_compute_route" "office" {
  name                = "office-via-vpn"
  dest_range          = "10.20.0.0/16"
  network             = google_compute_network.vpc.name
  next_hop_vpn_tunnel = google_compute_vpn_tunnel.to_office.id
  priority            = 1000
}

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

שקפו את הבוררים בעמית

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

הדפיסו את הבוררים של שני הצדדים זה לצד זה בסקירת השינוי.

פצלו את הכתובת הסטטית לשתי הפעלות

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

שתי הפעלות עכשיו זולות יותר משינוי עמית בכל גרסה.

אמתו את המשא ומתן, לא את התווית

לאחר ההפעלה בדקו שלוש עובדות נפרדות: המנהרה מדווחת שמחוברת, הנתיב קיים עם הקפיצה הבאה המיועדת, והעמית מדווח ששלב 1 ושלב 2 פעילים.

מנהרה שעולה כששלב 2 למטה פירושה ששני הצדדים לא מסכימים על הבוררים:

  • צד אחד מפרט תת-רשת שהצד השני לא מפרט.
  • צד אחד משתמש בצבירה שהצד השני צמצם.
  • הנתיב קיים אבל מצביע למנהרה אחרת.

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

מאמרים קשורים