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

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

מפרטים

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

קישוריות

  • קישור בין רשתות VPC שכנות תומך בחיבור של רשתות VPC, ולא ברשתות מדור קודם.
  • קישור בין רשתות שכנות (peering) של VPC מספק קישוריות פנימית של IPv4 ו-IPv6 בין זוגות של רשתות VPC. תעבורת נתונים בין רשתות שכנות (peering) היא בעלת אותם ערכי חביון, תפוקה וזמינות כמו תעבורת נתונים בתוך אותה רשת VPC.
    • קישור בין רשתות VPC שכנות (peering) לא מספק ניתוב מעבר. לדוגמה, אם רשתות ה-VPC‏ net-a ו-net-b מקושרות באמצעות קישור בין רשתות VPC שכנות, ורשתות ה-VPC‏ net-a ו-net-c מקושרות גם הן באמצעות קישור בין רשתות VPC שכנות, הקישור בין רשתות VPC שכנות לא מספק קישוריות בין 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) עם מחסנית כפולה ועם IPv6 בלבד
    • כללי העברה להעברת פרוטוקולים חיצוניים
    • כללי העברה למאזנים חיצוניים של עומסי רשת להעברת סיגנל ללא שינוי
  • קישור בין רשתות שכנות (peering) של VPC תומך בקישוריות IPv4 ו-IPv6. אפשר להגדיר קישור בין רשתות שכנות (peering) של VPC ברשת VPC שמכילה רשתות משנה עם טווחי כתובות IPv6.

ניהול

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

אבטחת רשת

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

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

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

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

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

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

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

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

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

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

תמיכה ב-DNS

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

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

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

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

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

קבוצת פירינג ומכסות

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

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

מגבלות

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

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

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

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

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

  • רשת ה-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 של המכונה הווירטואלית.

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

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

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

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

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

  • אם מתבצעת החלפה של נתיבי IPv6. הגדרת חיבור פירינג כפול מאפשרת להחליף מסלולי 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
טווחים של רשתות משנה פנימיות של IPv6
(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 כשהגדרתם את סוג ה-stack של הפירינג ל---stack-type=IPV4_IPV6 		לא מיובא כברירת מחדל

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

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

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

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

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

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

הייצוא נשלט באמצעות הדגל --export-custom-routes כשהגדרתם את סוג ה-stack של הפירינג ל---stack-type=IPV4_IPV6 		לא מיובא כברירת מחדל

הייבוא נשלט באמצעות הדגל --import-custom-routes כאשר סוג הערימה של הפירינג מוגדר ל---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) או מכשיר נתב של Cloud Router, שמשמשים כנקודת מעבר לחיבור לרשת מקומית. כדי לספק נתיב מרשת ה-VPC המקושרת לרשת המקומית, אדמין רשת ברשת ה-VPC המקומית מפעיל ייצוא של מסלולים מותאמים אישית, ואדמין רשת ברשת ה-VPC המקושרת מפעיל ייבוא של מסלולים מותאמים אישית. כדי לספק נתיב מהרשת המקומית לרשת ה-VPC המקושרת, אדמין רשת ברשת ה-VPC המקומית צריך להגדיר מצב פרסום מותאם אישית של Cloud Router ב-Cloud Router שמנהל את סשן ה-BGP עבור מנהרת Cloud VPN, חיבור Cloud Interconnect ‏ (VLAN) או מכשיר נתב שמתחבר לרשת המקומית. התוכן של המסלולים המותאמים אישית האלה צריך לכלול את טווחי כתובות ה-IP של תת-הרשתות ברשת ה-VPC המקושרת.

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

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

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

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

  • אם רשת ה-VPC המקומית לא מכילה את הנתיב הספציפי ביותר ליעד של חבילת נתונים, אבל שתי רשתות VPC או יותר שמקושרות באמצעות Peering מכילות את אותו יעד ספציפי ביותר לחבילת הנתונים,Cloud de Confiance by S3NS משתמשת באלגוריתם פנימי כדי לבחור את הצעד הבא מתוך אחת מרשתות ה-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.

‫Cloud de Confiance by S3NS אוכף את התנאים הקודמים לנתיבי תת-רשת של IPv4 במקרים הבאים:

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

במהלך יצירת רשתות משותפות, Cloud de Confiance by S3NS מחזירה שגיאה אם אחת מהפעולות הבאות גורמת לחפיפה:

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

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

‫Cloud de Confiance by S3NS מחייב שלמסלולי תת-רשת ולמסלולי תת-רשת של קישור בין רשתות שכנות יהיו טווחי כתובות IPv4 או IPv6 הכי ספציפיים. ברשת VPC, מסלול סטטי מקומי לא יכול להיות יעד שתואם בדיוק למסלול של תת-רשת מקומית או נכלל בו. לדיון מפורט יותר על התרחיש הזה, אפשר לעיין במאמר בנושא אינטראקציות עם מסלולים סטטיים.

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

  • למסלול מקומי סטטי לא יכול להיות יעד שתואם בדיוק למסלול של רשת משנה בפירינג או שנכלל בו. אם קיים מסלול סטטי מקומי, Cloud de Confiance by S3NS מבצע את הפעולות הבאות:

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

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

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

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

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

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

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

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

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

  • למסלול סטטי של פירינג לא יכול להיות יעד שתואם בדיוק למסלול של רשת משנה מקומית או שנכלל בו. אם קיים מסלול מקומי ברשת משנה, Cloud de Confiance by S3NS הפעולות הבאות אסורות:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • ‫network-a הוא peering ל-network-b, ו-network-b הוא peering ל-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 לא תואם בדיוק ולא מתאים בתוך אף רשת משנה או מסלול של רשת משנה מקושרת.

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

שם הרשת רכיב Networking טווח 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 הוא גלובלי, נתיבי On-premises prefix שנלמדו על ידי Cloud Router ב-network-b מתווספים כנתיבים דינמיים בכל האזורים של network-b וכנתיבים דינמיים של שותפות בכל האזורים של network-a. אם כללי חומת האש מוגדרים בצורה נכונה, 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 וכנתיבים דינמיים של שותפות באזור 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 שכנות.

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