קישור בין רשתות VPC שכנות (peering)

Google Cloud קישור בין רשתות שכנות (peering) של VPC מחבר בין שתי רשתות VPC, כך שמשאבים בכל רשת יכולים לתקשר זה עם זה. רשתות VPC מקושרות יכולות להיות באותו פרויקט, בפרויקטים שונים של אותו ארגון או בפרויקטים שונים של ארגונים שונים.

מפרטים

קישור בין רשתות VPC שכנות (peering) מאפשר לכם:

קישוריות

  • קישור בין רשתות VPC שכנות (peering) תומך בחיבור של רשתות VPC, ולא ברשתות מדור קודם.
  • קישור בין רשתות VPC שכנות (peering) מספק קישוריות פנימית של IPv4 ו-IPv6 בין זוגות של רשתות VPC. לתעבורת נתונים בין רשתות שכנות (peering) יש את אותם ערכים של זמן אחזור, קצב העברת נתונים וזמינות כמו לתעבורת נתונים בתוך אותה רשת VPC.
    • קישור בין רשתות VPC שכנות (peering) לא מספק ניתוב מעבר. לדוגמה, אם רשתות ה-VPC‏ net-a ו-net-b מקושרות באמצעות קישור בין רשתות שכנות (peering), ורשתות ה-VPC‏ net-a ו-net-c מקושרות גם הן באמצעות קישור בין רשתות שכנות (peering), הקישור בין רשתות שכנות (peering) לא מספק קישוריות בין net-b ל-net-c.
    • אי אפשר לקשר בין שתי רשתות VPC במצב אוטומטי באמצעות קישור בין רשתות VPC שכנות (peering). הסיבה לכך היא שרשתות VPC שכנות תמיד מחליפות מסלולי תת-רשת שמשתמשים בכתובות IPv4 פנימיות פרטיות, וכל תת-רשת ברשת VPC במצב אוטומטי משתמשת בטווח כתובות IP של תת-רשת שמתאים לבלוק ה-CIDR של 10.128.0.0/9.
    • אפשר לקשר רשת VPC במצב מותאם אישית לרשת VPC במצב אוטומטי, כל עוד לרשת ה-VPC במצב מותאם אישית אין טווחי כתובות IP של רשתות משנה שמתאימים לטווח 10.128.0.0/9.
  • קישור בין רשתות VPC שכנות (peering) מספק גם קישוריות חיצונית של IPv6 לטווחי כתובות IPv6 חיצוניות של המשאבים הבאים, כשהנתיבים לכתובות IPv6 החיצוניות האלה מוחלפים באמצעות קישור בין רשתות VPC שכנות (peering):
    • ממשקי רשת של מכונות וירטואליות (VM) עם כתובות IPv4 ו-IPv6 (dual-stack) ועם כתובות IPv6 בלבד
    • כללי העברה להעברת פרוטוקולים חיצוניים
    • כללי העברה למאזנים חיצוניים של עומסי רשת להעברת סיגנל ללא שינוי
  • קישור בין רשתות VPC שכנות (peering) תומך בקישוריות IPv4 ו-IPv6. אפשר להגדיר קישור בין רשתות VPC (VPC Network Peering) ברשת VPC שמכילה רשתות משנה עם טווחי כתובות IPv6.

ניהול

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

אבטחת רשת

רשתות VPC שמחוברות באמצעות קישור בין רשתות שכנות (peering) של VPC מחליפות רק נתיבים, על סמך אפשרויות החלפת הנתיבים שהוגדרו על ידי אדמין רשת של כל רשת VPC.

קישור בין רשתות VPC שכנות לא מתבצעת החלפה של כללי חומת אש של VPC או של מדיניות חומת אש.

לכללי חומת אש של VPC:

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

  • כללי חומת אש שהיעדים שלהם מוגדרים באמצעות חשבונות שירות, נפתרים רק למופעים ברשת ה-VPC של כלל חומת האש. בכפוף להרשאות IAM, יכול להיות שמנהל אבטחה של רשת VPC מקושרת יוכל להשתמש באותו חשבון שירות כדי להגדיר יעדים של כללי חומת אש ברשת VPC מקושרת, אבל היעדים של כללי חומת האש ברשת ה-VPC המקושרת לא כוללים מופעים ברשת ה-VPC שלכם. באופן דומה, כללי חומת אש של תעבורת נתונים נכנסת (ingress) שהמקורות שלהם מוגדרים באמצעות חשבונות שירות, נפתרים רק למופעים ברשת ה-VPC של כלל חומת האש.

כללים במדיניות של חומת אש בין רשתות יכולים להשתמש בתגים מאובטחים, ששונים מתגים ברשת, כדי לזהות יעדים ומקורות:

  • כשמשתמשים בתג כדי לציין יעד לכלל תעבורת נתונים נכנסת (ingress) או תעבורת נתונים יוצאת (egress) במדיניות חומת אש ברשת, התג יכול לזהות רק יעדים ברשת ה-VPC שהתג מוגבל אליה.

  • כשמשתמשים בתג כדי לציין מקור לכלל תעבורת נתונים נכנסת (ingress) במדיניות חומת אש בין רשתות, התג יכול לזהות מקורות גם ברשת ה-VPC שהתג מוגדר בה וגם בכל רשת VPC מקושרת שמחוברת לרשת ה-VPC שהתג מוגדר בה. מידע נוסף זמין במאמר בנושא תגים לחומות אש.

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

בגלל כללי חומת האש המשתמעים שמאפשרים תעבורת נתונים יוצאת (egress), לא צריך ליצור כללי חומת אש שמאפשרים תעבורת נתונים יוצאת (egress) או כללים במדיניות חומת האש כדי לאפשר לחבילות להגיע ליעדים ברשת ה-VPC המקבילה, אלא אם הרשתות כוללות כללים שמונעים תעבורת נתונים יוצאת (egress).

תמיכה ב-DNS

משאבים ברשת VPC מקושרת לא יכולים להשתמש בשמות DNS פנימיים של Compute Engine שנוצרו על ידי רשת VPC מקומית.

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

תמיכה במאזן עומסים פנימי

לקוחות ברשת VPC מקומית יכולים לגשת למאזני עומסים פנימיים ברשת VPC שכנה. מידע נוסף זמין בקטע שימוש ב-VPC Network Peering במאמרי העזרה הבאים בנושא מאזני עומסים:

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

קבוצת קישור בין רשתות שכנות (peering) ומכסות

המכסות של VPC peering מבוססות על מושג שנקרא קבוצת peering. לכל רשת VPC יש קבוצת peering משלה, שכוללת את הרשת עצמה ואת כל רשתות ה-VPC האחרות שמחוברות אליה באמצעות קישור בין רשתות VPC שכנות. בתרחיש הפשוט ביותר, אם שתי רשתות VPC‏, net-a ו-net-b, מקושרות זו לזו, יש שתי קבוצות של קישור בין רשתות שכנות (peering): אחת מנקודת המבט של net-a והשנייה מנקודת המבט של net-b.

מידע נוסף על מכסות של VPC Network Peering זמין במאמרים הבאים:

מגבלות

יש מגבלות על קישור בין רשתות VPC שכנות (peering).

אי אפשר שיהיה חפיפה בין טווחי כתובות ה-IP של רשתות משנה ברשתות VPC מקושרות

אף טווח כתובות IP של רשת משנה לא יכול להיות זהה לטווח כתובות IP של רשת משנה אחרת ברשת VPC מקושרת, או להכיל אותו או להיות מוכל בו. בזמן הקישור בין רשתות שכנות (peering),‏Google Cloud בודק אם קיימות רשתות משנה עם טווחי כתובות IP חופפים. אם הן קיימות, הקישור בין רשתות שכנות (peering) נכשל. ברשתות שכבר בוצע בהן שיוך, אם מבצעים פעולה שגורמת ליצירה של נתיב חדש ברשת משנה,Google Cloud צריך שלנתיב החדש ברשת המשנה יהיה טווח כתובות IP ייחודי ליעד.

לפני שיוצרים רשתות משנה חדשות, אפשר לרשום את המסלולים מחיבורי ה-Peering כדי לוודא שטווח כתובות ה-IPv4 של רשת המשנה החדשה לא נמצא כבר בשימוש.

ההגבלה הזו והבדיקות התואמות לה חלות גם על תרחישים כמו הבאים: Google Cloud

  • רשת ה-VPC, ‏ network-1, מקושרת לרשת VPC שנייה, ‏ network-2.
  • ‫network-2 מקושרת גם לרשת VPC שלישית, network-3.
  • אין שיוך של network-3 ל-network-1.

במקרה כזה, צריך לתאם עם אדמין ברשת כדי להגדיר את network-2. מבקשים ממנהל הרשת network-2 להציג רשימה של מסלולי ניתוב של רשתות VPC מקושרות ברשת ה-VPC שלו.

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

שמות DNS פנימיים לא נפתרים ברשתות מקושרות

אי אפשר לגשת לשמות של DNS פנימי של Compute Engine שנוצרו ברשת מרשתות מקושרות. כדי להגיע למכונות הווירטואליות ברשת המקושרת, משתמשים בכתובת ה-IP של המכונה הווירטואלית.

אי אפשר להשתמש בתגים ובחשבונות שירות ברשתות מקושרות

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

אפשרויות להחלפת מסלולים

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

ההגדרה של קישור בין רשתות VPC שכנות (peering) מאפשרת לכם לשלוט בדברים הבאים:

  • אם מתבצעת החלפה של נתיבי IPv6. הגדרת חיבור קישור בין רשתות שכנות (peering) עם פרוטוקול כפול מאפשרת להחליף מסלולי IPv6 מרשתות משנה עם פרוטוקול כפול ומרשתות משנה עם IPv6 בלבד.
  • אם מייצאים או מייבאים נתיבים של תת-רשתות שמשתמשות בכתובות IPv4 ציבוריות לשימוש פרטי.
  • אם מסלולים סטטיים ודינמיים מיוצאים או מיובאים.

אפשר לעדכן את ההגדרה לפני שהקישור בין רשתות שכנות (peering) נוצר או בזמן שקישוריות הקישור בין רשתות שכנות (peering) פעילה.

קישור בין רשתות VPC שכנות (peering) לא מספק:

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

אפשרויות להחלפת נתיבי רשתות משנה

בטבלה הבאה מפורטות האפשרויות להחלפת נתיבים של נתיבי רשת משנה:

סוג מסלול תנאים לייצוא נתיבים תנאי ייבוא נתיבים
נתיבי תת-רשת IPv4 (טווחי תת-רשת IPv4 ראשיים ומשניים) באמצעות טווחי כתובות IPv4 פרטיות תמיד מיוצא

אי אפשר להשבית		 תמיד מיובא

אי אפשר להשבית
נתיבי תת-רשת IPv4 (טווחי תת-רשת IPv4 ראשיים ומשניים) באמצעות טווחי כתובות IPv4 ציבוריות לשימוש פרטי מיוצא כברירת מחדל

הייצוא נשלט באמצעות הדגל --export-subnet-routes-with-public-ip 		לא מיובא כברירת מחדל

הייבוא נשלט באמצעות הדגל --import-subnet-routes-with-public-ip
Internal IPv6 subnet ranges
(ipv6-access-type=INTERNAL) 		לא מיוצא כברירת מחדל

הייצוא מופעל על ידי הגדרת --stack-type=IPV4_IPV6 		לא מיובא כברירת מחדל

הייבוא מופעל על ידי הגדרת --stack-type=IPV4_IPV6
טווחים של רשתות משנה חיצוניות של IPv6
(ipv6-access-type=EXTERNAL) 		לא מיוצא כברירת מחדל

הייצוא מופעל על ידי הגדרת --stack-type=IPV4_IPV6 		לא מיובא כברירת מחדל

הייבוא מופעל על ידי הגדרת --stack-type=IPV4_IPV6

אפשרויות להחלפת מסלולים סטטיים

בטבלה הבאה מתוארות האפשרויות להחלפת מסלולים עבור מסלולים סטטיים.

סוג מסלול תנאים לייצוא נתיבים תנאי ייבוא נתיבים
נתיבים סטטיים עם תגי רשת (כל סוגי הקפיצה הבאה) אי אפשר לייצא לא ניתן לייבא
מסלולים סטטיים שמשתמשים בניתוב קפיצה הבא של שער ברירת המחדל באינטרנט אי אפשר לייצא לא ניתן לייבא
מסלולים סטטיים של IPv4 – ללא תגי רשת – שמשתמשים בנקודת קפיצה הבאה ששונה משער ברירת המחדל לאינטרנט לא מיוצא כברירת מחדל

הייצוא נשלט באמצעות הדגל --export-custom-routes 		לא מיובא כברירת מחדל

הייבוא נשלט באמצעות הדגל --import-custom-routes
מסלולים סטטיים של IPv6 – ללא תגי רשת – שמשתמשים במופע של מכונה וירטואלית כנקודת הניתוב הבאה לא מיוצא כברירת מחדל

הייצוא נשלט באמצעות הדגל --export-custom-routes כאשר סוג הסטאק של הקישור בין רשתות שכנות (peering) מוגדר ל---stack-type=IPV4_IPV6 		לא מיובא כברירת מחדל

הייבוא נשלט באמצעות הדגל --import-custom-routes כאשר סוג ה-stack של הקישור בין רשתות שכנות (peering) מוגדר ל---stack-type=IPV4_IPV6

אפשרויות להחלפת מסלולים דינמיים

בטבלה הבאה מפורטות האפשרויות להחלפת נתיבים עבור נתיבים דינמיים.

סוג מסלול תנאים לייצוא נתיבים תנאי ייבוא נתיבים
מסלולי IPv4 דינמיים לא מיוצא כברירת מחדל

הייצוא נשלט באמצעות הדגל --export-custom-routes 		לא מיובא כברירת מחדל

הייבוא נשלט באמצעות הדגל --import-custom-routes
מסלולי IPv6 דינמיים לא מיוצא כברירת מחדל

הייצוא נשלט באמצעות הדגל --export-custom-routes כאשר סוג הסטאק של הקישור בין רשתות שכנות (peering) מוגדר ל---stack-type=IPV4_IPV6 		לא מיובא כברירת מחדל

הייבוא נשלט באמצעות הדגל --import-custom-routes כאשר סוג ה-stack של הקישור בין רשתות שכנות (peering) מוגדר ל---stack-type=IPV4_IPV6

היתרונות של החלפת מסלולים סטטיים ודינמיים

כשמייצאים מסלולים סטטיים ודינמיים מרשת VPC אחת ומייבאים אותם לרשת VPC אחרת, הרשת המייבאת יכולה לשלוח חבילות ישירות לניתור הבא של כל מסלול סטטי או דינמי שיובא, אם הניתור הבא שלו נמצא ברשת ה-VPC השכנה.

מנהל רשת של רשת VPC מקומית שולט בייצוא של המסלולים הסטטיים והדינמיים של הרשת הזו – ביחד – באמצעות הדגל --export-custom-routes. אדמין ברשת ה-VPC המקבילה שולט בייבוא של המסלולים הסטטיים והדינמיים האלה באמצעות הדגל --import-custom-routes. מידע נוסף מופיע במאמרים בנושא נתיבים שהמערכת מתעלמת מהם, אינטראקציות בין נתיבי תת-רשתות ונתיבי תת-רשתות מקושרות ואינטראקציות בין נתיבי תת-רשתות ונתיבים סטטיים.

ייבוא של מסלולים סטטיים ודינמיים מרשת VPC מקושרת יכול להיות שימושי בתרחישים הבאים:

  • אם רשת ה-VPC המקבילה מכילה אשכולות GKE מבוססי-ניתוב, ואתם צריכים לשלוח חבילות ל-Pods באשכולות האלה. כתובות ה-IP של הפודים מיושמות כטווחים של יעדים עבור מסלולים סטטיים שנמצאים ברשת ה-VPC המקושרת.

  • אם אתם צריכים לספק קישוריות בין רשת מקומית לבין רשת VPC שכנה. נניח שרשת VPC מקומית מכילה מסלולים דינמיים עם מנהרת Cloud VPN, צירוף ל-Cloud Interconnect ‏ (VLAN) או נתב וירטואלי, שמשמשים כנקודת הניתוב הבאה ומחברים לרשת מקומית. כדי לספק נתיב מרשת ה-VPC המקושרת לרשת השכנה לרשת המקומית, אדמין רשת ברשת ה-VPC המקומית מפעיל ייצוא של מסלולים מותאמים אישית, ואדמין רשת ברשת ה-VPC המקושרת לרשת השכנה מפעיל ייבוא של מסלולים מותאמים אישית. כדי לספק נתיב מהרשת המקומית לרשת ה-VPC המקושרת, מנהל רשת ברשת ה-VPC המקומית צריך להגדיר מצב פרסום מותאם אישית של Cloud Router ב-Cloud Router שמנהל את סשן ה-BGP עבור מנהרת Cloud VPN, צירוף ל-Cloud Interconnect ‏ (VLAN) או נתב וירטואלי שמתחבר לרשת המקומית. התוכן של הנתיבים המותאמים אישית האלה חייב לכלול את טווחי כתובות ה-IP של תת-הרשתות ברשת ה-VPC המקושרת.

מסלולים שהמערכת התעלמה מהם

גם כשמייבאים מסלול לרשת VPC, יכול להיות שהמערכת תתעלם מהמסלול המיובא במצבים כמו הבאים:

  • כאשר לרשת ה-VPC המקומית יש מסלול עם יעד זהה או ספציפי יותר (מסכה של רשת משנה ארוכה יותר), רשת ה-VPC המקומית תמיד משתמשת במסלול המקומי שלה.

  • אם רשת ה-VPC המקומית לא מכילה את המסלול הכי ספציפי ליעד של חבילת נתונים, אבל שתי רשתות VPC או יותר שמקושרות באמצעות Peering מכילות את אותו יעד הכי ספציפי לחבילת הנתונים,Google Cloud משתמשת באלגוריתם פנימי כדי לבחור את הצעד הבא מתוך אחת מרשתות ה-VPC שמקושרות באמצעות Peering. הבחירה הזו מתבצעת לפני שמתייחסים לעדיפות המסלול, ואי אפשר להגדיר את ההתנהגות. מומלץ להימנע מהגדרה כזו, כי הוספה או הסרה של רשתות VPC מקושרות יכולות לגרום לשינויים לא מכוונים בסדר הניתוב.

פרטים נוספים על המצבים שצוינו למעלה מופיעים במאמר בנושא סדר הניתוב.

בקישורים בין רשתות שכנות עם תמיכה ב-IPv4 ו-IPv6, אם ברשת VPC מקומית שמייבאת מסלולי IPv6 אין רשתות משנה עם תמיכה ב-IPv4 ו-IPv6 או רשתות משנה עם תמיכה ב-IPv6 בלבד, אי אפשר להשתמש באף אחד ממסלולי ה-IPv6 שהיא מקבלת מרשתות VPC שכנות. בנוסף, אם הוגדר אילוץ של מדיניות הארגון constraints/compute.disableAllIpv6, יכול להיות שמנהל רשת לא יוכל ליצור רשתות משנה עם טווחי כתובות IPv6.

אינטראקציות בין נתיבי תת-רשתות ונתיבי תת-רשתות של קישור

לא יכולה להיות חפיפה בין נתיבי תת-רשת IPv4 ברשתות VPC מקושרות:

  • ב-Peering אסורות כתובות זהות של מסלולי רשת משנה ב-IPv4. לדוגמה, בשתי רשתות VPC מקושרות לא יכול להיות מסלול של תת-רשת IPv4 שכתובת היעד שלו היא 100.64.0.0/10.
  • ב-Peering אסור שיהיה כלול מסלול של רשת משנה בתוך מסלול של רשת משנה ב-Peering. לדוגמה, אם ברשת ה-VPC המקומית יש נתיב של תת-רשת שהיעד שלו הוא 100.64.0.0/24, אז באף אחת מרשתות ה-VPC המקושרות לא יכול להיות נתיב של תת-רשת שהיעד שלו הוא 100.64.0.0/10.

Google Cloud אוכף את התנאים הקודמים לגבי נתיבי תת-רשת IPv4 במקרים הבאים:

  • כשמחברים רשתות VPC בפעם הראשונה באמצעות קישור בין רשתות VPC שכנות (peering).
  • בזמן שהרשתות מקושרות.
  • כשמבצעים שינוי בהגדרת ה-peering – למשל, הפעלת ייבוא של מסלולי IPv4 של רשתות משנה עם כתובות IP ציבוריות לשימוש פרטי.

במהלך יצירת קשר בין רשתות שכנות (peering), Google Cloud מוחזרת שגיאה אם אחת מהפעולות הבאות גורמת לחפיפה:

נתיבי תת-רשת של IPv6 (פנימיים וחיצוניים) הם ייחודיים בהגדרה. אי אפשר להשתמש באותם טווחי רשתות משנה פנימיות או חיצוניות של IPv6 בשתי רשתות VPC. לדוגמה, אם רשת VPC אחת משתמשת ב-fc:1000:1000:1000::/64 כטווח של תת-רשת IPv6, אף רשת VPC אחרת ב- Google Cloud לא יכולה להשתמש ב-fc:1000:1000:1000::/64, בלי קשר לשאלה אם רשתות ה-VPC מקושרות באמצעות קישור בין רשתות שכנות (peering).

אינטראקציות של רשתות משנה ונתיבים סטטיים

‫Google Cloud נדרש שיהיו לתת-רשתות ולתת-רשתות של קישור בין רשתות שכנות (peering) טווחי כתובות IPv4 או IPv6 ספציפיים ביותר. בכל רשת VPC, מסלול סטטי מקומי לא יכול להיות יעד שתואם בדיוק למסלול של רשת משנה מקומית או נכלל בו. לדיון מפורט יותר על התרחיש הזה, אפשר לעיין במאמר בנושא אינטראקציות עם מסלולים סטטיים.

המושג הזה מורחב לקישור בין רשתות VPC שכנות (peering) באמצעות שני הכללים הבאים:

  • למסלול סטטי מקומי לא יכול להיות יעד שתואם בדיוק למסלול של רשת משנה בקישור בין רשתות שכנות (peering) או שנכלל בו. אם קיים נתיב סטטי מקומי, המערכתGoogle Cloud מבצעת את הפעולות הבאות:

    • אי אפשר ליצור חיבור חדש של קישור (peering) לרשת VPC שכבר מכילה נתיב של רשת משנה שתואם בדיוק ליעד של הנתיב הסטטי המקומי או מכיל אותו, אם הגדרת הקישור גורמת לייבוא של נתיב רשת המשנה שמתנגש עם הנתיב הסטטי המקומי. לדוגמה:

      • אם קיים נתיב סטטי מקומי עם היעד 10.0.0.0/24, אי אפשר ליצור חיבור חדש של קישור בין רשתות שכנות (peering) לרשת VPC שמכילה נתיב של רשת משנה IPv4 שהיעד שלה זהה בדיוק ל-10.0.0.0/24 או מכיל את 10.0.0.0/24 (לדוגמה, 10.0.0.0/8).

      • אם סוג הערימה המיועדת של ה-Peering הוא IPV4_IPV6, ואם קיים נתיב סטטי מקומי עם יעד 2001:0db8:0a0b:0c0d::/96, אי אפשר ליצור חיבור Peering חדש לרשת VPC שמכילה נתיב של רשת משנה IPv6 שהיעד שלו זהה ל-2001:0db8:0a0b:0c0d::/96 או מכיל אותו. במצב הזה, טווח כתובות ה-IPv6 של רשת המשנה האפשרי היחיד הוא 2001:0db8:0a0b:0c0d::/64 כי בטווחים של כתובות IPv6 של רשתות משנה ב- Google Cloud חובה להשתמש באורכים של מסכות רשת משנה של 64 ביט.

    • אי אפשר לעדכן חיבור קישור בין רשתות שכנות (peering) קיים אם עדכון הגדרות הקישור בין רשתות שכנות (peering) גורם לייבוא של נתיב רשת משנה שמתנגש עם נתיב קיים. לדוגמה:

      • נניח ששתי רשתות VPC כבר מקושרות, אבל הן לא מייצאות ומייבאות מסלולי רשת משנה של IPv4 באמצעות טווחי כתובות IPv4 ציבוריות שמשמשות לשימוש פרטי. ברשת ה-VPC הראשונה קיימת נתיב סטטי מקומי עם היעד 11.0.0.0/24, וברשת ה-VPC המקושרת קיימת נתיב של רשת משנה עם היעד 11.0.0.0/8. אי אפשר להגדיר בו-זמנית את רשת ה-VPC המקבילה לייצוא של מסלולי רשתות משנה באמצעות כתובות IPv4 ציבוריות לשימוש פרטי וגם להגדיר את רשת ה-VPC הראשונה לייבוא של מסלולי רשתות משנה באמצעות כתובות IPv4 ציבוריות לשימוש פרטי.

      • נניח ששתי רשתות VPC כבר נמצאות בקישור בין רשתות שכנות (peering), וסוג הקישור בין רשתות שכנות (peering) הוא IPv4 בלבד. נתיב סטטי מקומי עם היעד 2001:0db8:0a0b:0c0d::/96 קיים ברשת ה-VPC הראשונה, ונתיב של רשת משנה מסוג IPv6 עם היעד 2001:0db8:0a0b:0c0d::/64 קיים ברשת ה-VPC המקושרת. אי אפשר לשנות את סוג ערימת ה-Peering ל-IPV4_IPV6.

    • לעומת זאת, אם רשתות ה-VPC כבר מקושרות באמצעות קישור בין רשתות VPC שכנות, אי אפשר לבצע את הפעולות הבאות:

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

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

  • למסלול סטטי של שירותי peering לא יכול להיות יעד שתואם בדיוק למסלול של רשת משנה מקומית או שנכלל בו. אם קיים מסלול מקומי ברשת משנה, Google Cloud הפעולות הבאות אסורות:

    • אי אפשר ליצור חיבור חדש של קישור בין רשתות שכנות (peering) לרשת VPC שכבר מכילה נתיב סטטי שתואם בדיוק ליעד של נתיב רשת המשנה של רשת ה-VPC המקומית, או שנכלל בו, אם הגדרת הקישור גורמת לייבוא של הנתיב הסטטי מהרשת השכנה. לדוגמה:

      • אם קיים מסלול של רשת משנה מקומית ל-10.0.0.0/8, אי אפשר ליצור קישור בין רשתות שכנות (peering) לרשת VPC עם מסלול סטטי שהיעד שלו זהה בדיוק ל-10.0.0.0/8 או נמצא בטווח של 10.0.0.0/8 (לדוגמה, 10.0.0.0/24).

      • כשסוג ערימת הקישוריות המיועד הוא IPV4_IPV6, אם קיים נתיב של רשת משנה מקומית ל-2001:0db8:0a0b:0c0d::/64, אי אפשר ליצור חיבור קישור בין רשתות שכנות (peering) לרשת VPC עם נתיב סטטי שהיעד שלו תואם בדיוק ל-2001:0db8:0a0b:0c0d::/64 או מתאים ל-2001:0db8:0a0b:0c0d::/64 (לדוגמה, 2001:0db8:0a0b:0c0d::/96).

    • אי אפשר לעדכן חיבור קישור בין רשתות שכנות (peering) קיים אם עדכון הגדרות הקישור בין רשתות שכנות (peering) גורם לייבוא של נתיב סטטי שמתנגש עם נתיב אחר.

    • לעומת זאת, אם רשתות ה-VPC כבר מקושרות באמצעות קישור בין רשתות VPC שכנות, אי אפשר לבצע את הפעולות הבאות:

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

ההשפעות של מצב הניתוב הדינמי

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

המושג הזה רלוונטי גם לקישור בין רשתות VPC שכנות (peering). מצב הניתוב הדינמי של רשת ה-VPC המייצאת – הרשת שמכילה את נתבי Cloud Router שלמדו את הקידומות של המסלולים הדינמיים האלה – קובע את האזורים שבהם אפשר לתכנת את המסלולים הדינמיים של ה-peering ברשתות ה-peering:

  • אם מצב הניתוב הדינמי של רשת ה-VPC שממנה מייצאים הוא אזורי, הרשת הזו מייצאת נתיבים דינמיים רק באותו אזור כמו ה-Cloud Routers שלה, שלמדו את הקידומות.

  • אם מצב הניתוב הדינמי של רשת ה-VPC שממנה מתבצע הייצוא הוא גלובלי, הרשת הזו מייצאת מסלולי ניתוב דינמיים בכל האזורים.

בשני המקרים, מצב הניתוב הדינמי של רשת ה-VPC המייבאת לא רלוונטי.

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

אינטראקציות של תת-רשתות ומסלולים דינמיים

קונפליקטים בין מסלולים של רשתות משנה מקומיות או מסלולים של רשתות משנה עם קישור בין רשתות שכנות (peering) לבין מסלולים דינמיים נפתרים כמו שמתואר במאמר אינטראקציות עם מסלולים דינמיים.

דוגמאות לקישור בין רשתות VPC שכנות (peering)

בדוגמאות הבאות מוצגים שני תרחישים נפוצים של קישור בין רשתות VPC שכנות (peering).

רשת VPC מקומית ורשת VPC שכנה עם קישוריות מקומית

בדוגמה הזו, מוגדרת הצמדת הרשת הבאה:

  • network-a הוא עמית של network-b, ו-network-b הוא עמית של network-a.
  • ‫network-a מכיל שתי רשתות משנה, וכל אחת מהן נמצאת באזור נפרד. ‫network-b מכיל תת-רשת אחת.
  • ‫network-b מחובר לרשת מקומית עם מנהרות Cloud VPN באמצעות ניתוב דינמי. (אותם עקרונות חלים אם המנהרות מוחלפות בחיבורי VLAN של Cloud Interconnect).
  • חיבור ה-Peering של network-b מוגדר עם הדגל --export-custom-routes, וחיבור ה-Peering של network-a מוגדר עם הדגל --import-custom-routes.
רשתות מקושרות עם ניתוב דינמי גלובלי.
רשת עם קישור באמצעות Peering עם גישה לרשת המקומית עם ניתוב דינמי גלובלי (לחצו כדי להגדיל).

כדי לספק קישוריות ממיקום מקומי לתת-רשתות ב-network-a וב-network-b, צריך להגדיר את Cloud Router ב-network-b לשימוש במצב פרסום מותאם אישית. לדוגמה, Cloud Router מפרסם רק את הקידומת המותאמת אישית, custom-prefix-1, שכוללת את טווחי רשתות המשנה מ-network-b ואת טווחי רשתות המשנה מ-network-a.

‫Cloud Router ב-us-west1 לומד את on-premises-prefix מנתב מקומי. ‫on-premises-prefix לא יוצר אף קונפליקט כי הוא רחב יותר מרשת המשנה ומנתיבי רשת המשנה של ה-Peering. במילים אחרות, on-premises-prefix לא תואם בדיוק ולא מתאים בתוך אף רשת משנה או נתיב של רשת משנה בקישור בין רשתות שכנות (peering).

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

שם הרשת רכיב רשת טווח IPv4 טווח IPv6 אזור

network-a

subnet-a

10.0.0.0/24

fc:1000:1000:1000::/64

us-west1

network-a

subnet-b

10.0.1.0/24

fc:1000:1000:1001::/64

‫europe-north 1

network-b

subnet-c

10.0.2.0/23

fc:1000:1000:1002::/64

us-west1

network-b

Cloud Router

10.0.0.0/22

fc:1000:1000:1000::/64

us-west1

רשת מקומית

נתב מקומי

10.0.0.0/8

fc:1000:1000:1000::/56

לא רלוונטי

לא משנה מה מצב הניתוב הדינמי של network-a, מאפייני הניתוב הבאים חלים:

  • כשמצב הניתוב הדינמי של network-b הוא גלובלי, נתיבים שנלמדו על ידי Cloud Router ב-network-b מתווספים כנתיבים דינמיים בכל האזורים של network-b וכנתיבים דינמיים של שותפות בכל האזורים של network-a.On-premises prefix אם כללי חומת האש מוגדרים בצורה נכונה, vm-a1,‏ vm-a2 ו-vm-b יכולים לתקשר עם משאב מקומי עם כתובת IPv4‏ 10.5.6.7 (או כתובת IPv6‏ fc:1000:1000:10a0:29b::).

  • אם משנים את מצב הניתוב הדינמי של network-b לאזורי, נתיבים שנלמדו על ידי Cloud Router ב-network-b נוספים רק כנתיבים דינמיים באזור us-west1 של network-b וכנתיבים דינמיים של שותפות (peering) באזור us-west1 של network-a.On-premises prefix אם כללי חומת האש מוגדרים בצורה נכונה, רק vm-a1 ו-vm-b יכולים לתקשר עם משאב מקומי עם כתובת IPv4‏ 10.5.6.7 (או כתובת IPv6‏ fc:1000:1000:10a0:29b::), כי זו המכונה הווירטואלית היחידה באותו אזור כמו Cloud Router.

רשת תחבורה ציבורית עם כמה חיבורי Peering

נניח ש-network-b מחובר לרשת מקומית ומשמש כרשת מעבר לשתי רשתות אחרות, network-a ו-network-c. כדי לאפשר למכונות וירטואליות בשתי הרשתות האלה לגשת אל network-b ואל הרשת המקומית שמחוברת אליו באמצעות כתובות IP פנימיות בלבד, צריך להגדיר את ההגדרה הבאה:

  • network-a הוא עמית של network-b, ו-network-b הוא עמית של network-a.
  • network-c הוא עמית של network-b, ו-network-b הוא עמית של network-c.
  • ‫network-b מחובר לרשת מקומית עם מנהרות Cloud VPN באמצעות ניתוב דינמי. אותם עקרונות חלים אם המנהרות הוחלפו בחיבורי VLAN של Cloud Interconnect.
    • כדי לספק קישוריות משרתים מקומיים לרשתות משנה באזורים network-a, ‏network-b ו-network-c, הנתב Cloud Router באזור network-b מוגדר לשימוש במצב פרסום מותאם אישית. לדוגמה, Cloud Router מפרסם נתיבי תת-רשת מ-network-b וקידומות בהתאמה אישית שכוללות נתיבי תת-רשת ב-network-a וב-network-c.
    • בכפוף לאינטראקציות של רשתות משנה ומסלולים דינמיים,‏ Cloud Router ב-network-b לומד קידומות מקומיות ויוצר מסלולים דינמיים ב-network-b.
  • חיבורי ה-Peering מ-network-b אל network-a ומ-network-b אל network-c מוגדרים עם הדגל --export-custom-routes. חיבורי ה-Peering מ-network-a אל network-b ומ-network-c אל network-b מוגדרים עם הדגל --import-custom-routes.
רשת VPC למעבר, שמכילה מנהרת VPN, שמקושרת לשתי רשתות VPC אחרות.
רשת מעבר של VPC (לחצו כדי להגדיל).

אם חומות האש מוגדרות בצורה נכונה, יכולים להיות תרחישי הקישוריות הבאים:

  • מכונות וירטואליות ב-network-a יכולות להגיע למכונות וירטואליות אחרות ב-network-b ולמערכות מקומיות.
  • מכונות וירטואליות ב-network-c יכולות להגיע למכונות וירטואליות אחרות ב-network-b ולמערכות מקומיות.
  • מכונות וירטואליות ב-network-b יכולות להגיע למכונות וירטואליות אחרות ב-network-a וב-network-c, וגם למערכות ברשת המקומית.

מכיוון שקישור בין רשתות VPC שכנות הוא לא טרנזיטיבי, מכונות וירטואליות ברשתות network-a ו-network-c לא יכולות לתקשר ביניהן, אלא אם מקשרים גם בין הרשתות network-a ו-network-c באמצעות קישור בין רשתות VPC שכנות.

תמחור

התמחור הרגיל של הרשת חל על קישור בין רשתות VPC שכנות (peering).

המאמרים הבאים