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

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

לפני שמתחילים

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

הרשאות IAM

צריך לוודא שיש לכם את אחד מהתפקידים הבאים בפרויקט:

• התפקיד Compute Network Admin (roles/compute.networkAdmin)
• תפקיד בהתאמה אישית שכולל את ההרשאות הבאות:
  • compute.networks.addPeering
  • compute.networks.updatePeering
  • compute.networks.removePeering
  • compute.networks.listPeeringRoutes

יצירת הגדרת קישור בין רשתות שכנות (peering)

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

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

Google Cloud מאפשרת רק פעולת peering אחת בכל פעם ברשתות שכנות. לדוגמה, אם הגדרתם שירות Peering עם רשת אחת ואתם מנסים להגדיר שירות Peering עם רשת אחרת מיד לאחר מכן, הפעולה תיכשל ותופיע השגיאה הבאה: Error: There is a peering operation in progress on the local or peer network. Try again later.

המסוף

מבצעים את השלבים הבאים בכל צד של קישור ה-Peering.

1. נכנסים לדף VPC Network Peering במסוף Google Cloud .

   מעבר ל-VPC Network Peering

2. לוחצים על יצירת קישור.

3. לוחצים על Continue.

4. בשדה Peering connection name (שם חיבור ה-Peering), מזינים שם להגדרת ה-Peering.

5. בשדה Your VPC network (רשת ה-VPC שלכם), בוחרים את הרשת שרוצים ליצור איתה שותפות.

6. בקטע Peered VPC network (רשת VPC עם שותפות), בוחרים את הרשת שאיתה רוצים ליצור שותפות:

   • אם הרשת שרוצים ליצור איתה שותפות נמצאת באותו פרויקט, בוחרים באפשרות In project [name-of-your-project] (בפרויקט [שם הפרויקט]) ואז בוחרים את הרשת שרוצים ליצור איתה שותפות.
   • אם הרשת שרוצים ליצור איתה קישור בין רשתות שכנות (peering) נמצאת בפרויקט אחר, בוחרים באפשרות בפרויקט אחר. מציינים את מזהה הפרויקט שכולל את הרשת שאליה רוצים ליצור קישור בין רשתות שכנות (peering) ואת השם של רשת ה-VPC.

7. בוחרים את גרסת ה-IP של המסלולים שרוצים להחליף בין הרשתות המקושרות:

   • ‫IPv4 (single-stack): החלפת מסלולי IPv4 בלבד.
   • ‫IPv4 ו-IPv6 (dual-stack): החלפת נתיבים של IPv4 ו-IPv6.

8. כדי להחליף מסלולים מותאמים אישית של IPv4, בקטע Exchange IPv4 custom routes (החלפת מסלולים מותאמים אישית של IPv4), בוחרים אחת מהאפשרויות הבאות או את שתיהן:

   • ייבוא של נתיבים מותאמים אישית: ייבוא של נתיבים מותאמים אישית מרשת ה-Peering. כדי לייבא נתיבים, הרשת העמיתה צריכה לאפשר ייצוא של נתיבים מותאמים אישית.
   • ייצוא של נתיבים מותאמים אישית: ייצוא של נתיבים מותאמים אישית לרשת העמיתים. כדי לייצא נתיבים, צריך להפעיל ברשת העמיתים ייבוא של נתיבים מותאמים אישית.

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

   כדי לייבא נתיבי תת-רשת של IPv4 ציבורי שמשמשים באופן פרטי, בקטע Exchange subnet routes with privately used public IPv4 addresses (החלפת נתיבי תת-רשת עם כתובות IPv4 ציבוריות שמשמשות באופן פרטי), בוחרים באפשרות Import subnet routes with public IP (ייבוא נתיבי תת-רשת עם IP גלוי).

10. בקטע Advanced options (אפשרויות מתקדמות), בוחרים את אסטרטגיית העדכון של חיבור ה-Peering:

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

11. לוחצים על יצירה.

gcloud

משתמשים בפקודה gcloud compute networks peerings create.

אפשר ליצור הגדרת Peering באמצעות הגדרת ברירת המחדל, או להתאים אישית את ההגדרה.

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

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

gcloud compute networks peerings create PEERING_NAME \
    --network=NETWORK \
    --peer-project=PEER_PROJECT_ID \
    --peer-network=PEER_NETWORK_NAME

מחליפים את מה שכתוב בשדות הבאים:

• ‫PEERING_NAME: השם של הגדרות הקישור בין רשתות שכנות (peering).
• ‫NETWORK: השם של הרשת בפרויקט שרוצים ליצור איתה קישור בין רשתות שכנות (peering).
• PEER_PROJECT_ID: מזהה הפרויקט שמכיל את הרשת שרוצים ליצור איתה קישור בין רשתות שכנות (peering). אם רשת ה-peer נמצאת באותו פרויקט כמו הרשת שלכם, הדגל הזה הוא אופציונלי.
• ‫PEER_NETWORK_NAME: השם של הרשת שרוצים ליצור איתה קישור בין רשתות שכנות (peering).

לדוגמה, כדי ליצור קשר בין network-a ב-project-a לבין network-b ב-project-b, מבצעים את הפעולות הבאות:

1. יוצרים הגדרת peering עבור network-a. בדרך כלל מנהל הרשת של network-a מבצע את השלב הזה.

   gcloud compute networks peerings create peering-a \
       --network=network-a \
       --peer-project=project-b \
       --peer-network=network-b
   

2. יוצרים הגדרת peering עבור network-b. בדרך כלל מנהל הרשת של network-b מבצע את השלב הזה.

   gcloud compute networks peerings create peering-b \
       --network=network-b \
       --peer-project=project-a \
       --peer-network=network-a
   

מצב ה-peering משתנה ל-ACTIVE בשתי הרשתות.

התאמה אישית של הגדרת שירותי Peering

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

• ‫--stack-type מגדיר את סוג המערך לחיבור הקישור בין רשתות שכנות (peering). כברירת מחדל, רק נתיבי IPv4 מוחלפים, וסוג הערימה מוגדר כ-IPV4_ONLY. כדי להחליף מסלולים של IPv4 ו-IPv6, מציינים IPV4_IPV6.
• ‫--import-custom-routes אומר לרשת לקבל מסלולים מותאמים אישית מהרשת המקושרת. קודם צריך לייצא את המסלולים מהרשת המקבילה.
• ‫--export-custom-routes אומר לרשת לייצא נתיבים מותאמים אישית לרשת שעוברת תהליך של שיתוף פעולה. צריך להגדיר את הרשת המקבילה כך שהיא תייבא את המסלולים.
• ‫--import-subnet-routes-with-public-ip אומר לרשת לקבל נתיבי תת-רשת מהרשת המקבילה אם ברשת הזו יש כתובות IPv4 ציבוריות שנמצאות בשימוש פרטי בתת-הרשתות שלה. קודם צריך לייצא את המסלולים מהרשת המקבילה.
• ‫--export-subnet-routes-with-public-ip אומר לרשת לייצא נתיבי תת-רשת שמכילים כתובות IPv4 ציבוריות שמשמשות לשימוש פרטי. צריך להגדיר את הרשת המקבילה כך שתייבא את המסלולים.
• ‫--update-strategy מגדיר את אסטרטגיית העדכון לחיבור הקישור בין רשתות שכנות (peering). כברירת מחדל, אסטרטגיית העדכון מוגדרת לערך INDEPENDENT. כדי להגדיר את החיבור לשימוש במצב קונצנזוס, מציינים את CONSENSUS. אסטרטגיית העדכון צריכה להיות זהה בשני הצדדים של החיבור. מידע נוסף זמין במאמר בנושא מצב חיבור.

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

כדי להפעיל את network-a ב-project-a ואת network-b ב-project-b כדי להחליף מסלולים בהתאמה אישית, צריך לבצע את הפעולות הבאות כשיוצרים את חיבור ה-Peering:

1. יוצרים הגדרת peering עבור network-a. בדרך כלל מנהל הרשת של network-a מבצע את השלב הזה.

   gcloud compute networks peerings create peering-a \
       --network=network-a \
       --peer-project=project-b \
       --peer-network=network-b \
       --import-custom-routes \
       --export-custom-routes
   

2. יוצרים הגדרת peering עבור network-b. בדרך כלל מנהל הרשת של network-b מבצע את השלב הזה.

   gcloud compute networks peerings create peering-b \
       --network=network-b \
       --peer-project=project-a \
       --peer-network=network-a \
       --import-custom-routes \
       --export-custom-routes
   

מצב ה-peering משתנה ל-ACTIVE בשתי הרשתות. מידע נוסף על הדוגמה הזו זמין במאמר מדריך למתחילים: קישור בין שתי רשתות VPC.

דוגמה: יצירת חיבור פירינג במצב קונצנזוס

כדי ליצור חיבור קישור בין רשתות שכנות (peering) במצב קונצנזוס, מגדירים את אסטרטגיית העדכון ל-CONSENSUS. בדוגמה הזו, מגדירים את network-a ב-project-a כקישור בין רשתות שכנות (peering) ל-network-b ב-project-b.

1. יוצרים הגדרת peering עבור network-a. בדרך כלל מנהל הרשת של network-a מבצע את השלב הזה.

   gcloud compute networks peerings create peering-a \
       --network=network-a \
       --peer-project=project-b \
       --peer-network=network-b \
       --update-strategy=CONSENSUS
   

2. יוצרים הגדרת peering עבור network-b. בדרך כלל מנהל הרשת של network-b מבצע את השלב הזה.

   gcloud compute networks peerings create peering-b \
       --network=network-b \
       --peer-project=project-a \
       --peer-network=network-a \
       --update-strategy=CONSENSUS
   

מצב ה-peering משתנה ל-ACTIVE בשתי הרשתות.

Terraform

אתם יכולים להשתמש במודול של Terraform כדי ליצור הגדרת Peering.

module "peering1" {
  source        = "terraform-google-modules/network/google//modules/network-peering"
  version       = "~> 13.0"
  local_network = var.local_network # Replace with self link to VPC network "foobar" in quotes
  peer_network  = var.peer_network  # Replace with self link to VPC network "other" in quotes
}

לשתי רשתות ה-VPC המקושרות, כל קישור עצמי כולל מזהה פרויקט ואת השם של רשת ה-VPC. כדי לקבל את הקישור העצמי של רשת VPC, אפשר להשתמש בפקודה gcloud compute networks describe או בשיטה networks.get בכל פרויקט של רשת VPC.

כשיוצרים peering מ-local_network אל peer_network, יחסי ה-peering הם דו-כיווניים. הקישור בין peer_network ל-local_network נוצר באופן אוטומטי.

כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform.

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

אפשר להשתמש ב-VPC Flow Logs כדי לראות את תעבורת הרשת שנשלחת ממכונות וירטואליות ומתקבלת בהן. אפשר גם להשתמש בניהול כללי חומת אש כדי לוודא שהתנועה עוברת בין הרשתות. יוצרים כללי חומת אש ב-VPC שמאפשרים (או מונעים) תעבורת נתונים בין הרשתות המקושרות, ומפעילים את ניהול כללי חומת אש עבור הכללים האלה. אחר כך תוכלו לראות אילו כללים בחומת האש הופעלו באמצעות Cloud Logging.

עדכון של חיבור Peering

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

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

הרשת שלכם מייבאת מסלולים רק אם רשת הקישור בין רשתות שכנות (peering) מייצאת גם את המסלולים, ורשת הקישור בין רשתות שכנות (peering) מקבלת מסלולים רק אם היא מייבאת אותם.

חשוב: גם אם מצב הניתוב הדינמי של רשת ה-VPC מוגדר כגלובלי, מסלולי IPv6 שנלמדים מ-Cloud Router הם אזוריים. מידע נוסף מופיע בקטע מגבלות.

עדכון חיבור (מצב עצמאי)

המסוף

1. נכנסים לדף VPC Network Peering במסוף Google Cloud .

   מעבר ל-VPC Network Peering

2. בוחרים את חיבור ה-peering שרוצים לעדכן.

3. לוחצים על Edit.

4. כדי לעדכן את גרסת ה-IP של המסלולים שרוצים להחליף בין הרשתות המקושרות, בוחרים באחת מהאפשרויות הבאות:

   • ‫IPv4 (single-stack): עצירה של חילופי נתונים קיימים של מסלולי IPv6 והמשך חילופי נתונים של מסלולי IPv4 בלבד.
   • ‫IPv4 ו-IPv6 (dual-stack): מתחילים להחליף מסלולים של IPv4 ו-IPv6, בתנאי שהאפשרות הזו מופעלת גם בתצורת ה-peering התואמת.

5. כדי להחליף מסלולים מותאמים אישית של IPv4, בקטע Exchange IPv4 custom routes (החלפת מסלולים מותאמים אישית של IPv4), בוחרים אחת מהאפשרויות הבאות או את שתיהן:

   • ייבוא של נתיבים מותאמים אישית: ייבוא של נתיבים מותאמים אישית מרשת ה-Peering. כדי לייבא נתיבים, הרשת העמיתה צריכה לאפשר ייצוא של נתיבים מותאמים אישית.
   • ייצוא של נתיבים מותאמים אישית: ייצוא של נתיבים מותאמים אישית לרשת העמיתים. כדי לייצא נתיבים, צריך להפעיל ברשת העמיתים ייבוא של נתיבים מותאמים אישית.

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

   כדי לייבא נתיבי תת-רשת של IPv4 ציבורי שמשמשים באופן פרטי, בקטע Exchange subnet routes with privately used public IPv4 addresses (החלפת נתיבי תת-רשת עם כתובות IPv4 ציבוריות שמשמשות באופן פרטי), בוחרים באפשרות Import subnet routes with public IP (ייבוא נתיבי תת-רשת עם IP גלוי).

7. לוחצים על Save.

gcloud

משתמשים בפקודה gcloud compute networks peerings update. הסוגריים המרובעים [] בפקודה הבאה מציינים דגלים אופציונליים:

• ‫--stack-type מגדיר את סוג המערך לחיבור הקישור בין רשתות שכנות (peering). כברירת מחדל, רק נתיבי IPv4 מוחלפים, וסוג הערימה מוגדר כ-IPV4_ONLY. כדי להחליף מסלולים של IPv4 ו-IPv6, מציינים IPV4_IPV6.
• ‫--import-custom-routes אומר לרשת לקבל מסלולים מותאמים אישית מהרשת המקושרת. קודם צריך לייצא את המסלולים מהרשת המקבילה.
• ‫--export-custom-routes אומר לרשת לייצא נתיבים מותאמים אישית לרשת שעוברת תהליך של שיתוף פעולה. צריך להגדיר את הרשת המקבילה כך שהיא תייבא את המסלולים.
• ‫--import-subnet-routes-with-public-ip אומר לרשת לקבל מסלולי תת-רשת מהרשת המקבילה אם הרשת הזו משתמשת בכתובות IPv4 ציבוריות לשימוש פרטי בתת-הרשתות שלה. קודם צריך לייצא את המסלולים מהרשת המקבילה.
• ‫--export-subnet-routes-with-public-ip אומר לרשת לייצא נתיבי תת-רשת שמכילים כתובות IPv4 ציבוריות שמשמשות לשימוש פרטי. צריך להגדיר את הרשת המקבילה כך שתייבא את המסלולים.
• ‫--update-strategy מגדיר את אסטרטגיית העדכון לחיבור הקישור בין רשתות שכנות (peering). כברירת מחדל, אסטרטגיית העדכון מוגדרת לערך INDEPENDENT. כדי להגדיר את החיבור לשימוש במצב קונצנזוס, מציינים את CONSENSUS. אסטרטגיית העדכון צריכה להיות זהה בשני הצדדים של החיבור. מידע נוסף זמין במאמר בנושא מצב חיבור.

gcloud compute networks peerings update PEERING_NAME \
    --network=NETWORK \
    [--stack-type=STACK_TYPE] \
    [--import-custom-routes] \
    [--export-custom-routes] \
    [--export-subnet-routes-with-public-ip] \
    [--import-subnet-routes-with-public-ip] \
    [--update-strategy=UPDATE_STRATEGY]

מחליפים את מה שכתוב בשדות הבאים:

• ‫PEERING_NAME: השם של תצורת ה-Peering הקיימת.
• ‫NETWORK: השם של הרשת בפרויקט שלכם שמקושרת לרשת אחרת.
• STACK_TYPE: סוג המערך של חיבור הקישור בין רשתות שכנות (peering).
  • מציינים IPV4_ONLY כדי להפסיק את חילופי המסלולים הקיימים של IPv6 ולהמשיך להחליף רק מסלולים של IPv4.
  • מציינים IPV4_IPV6 כדי להתחיל להחליף מסלולי IPv4 ו-IPv6, בתנאי שגם לחיבור הקישור בין רשתות שכנות (peering) התואם מוגדר stack_type עם הערך IPV4_IPV6.
• ‫UPDATE_STRATEGY: אסטרטגיית העדכון של חיבור ה-Peering –‏ INDEPENDENT (ברירת מחדל) או CONSENSUS. כדי להשתמש באפשרות הזו, אפשר לעיין במאמר עדכון חיבור למצב קונצנזוס .

עדכון חיבור למצב קונצנזוס

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

המסוף

1. נכנסים לדף VPC Network Peering במסוף Google Cloud .

   מעבר ל-VPC Network Peering

2. לוחצים על חיבור ה-peering שרוצים לעדכן.

3. לוחצים על Edit.

4. בקטע אפשרויות מתקדמות, בוחרים באפשרות קונצנזוס.

5. לוחצים על Save.

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

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

gcloud

משתמשים בפקודה gcloud compute networks peerings update.

1. מעדכנים את הגדרת ה-peering המקומי:

   gcloud compute networks peerings update PEERING_NAME \
       --network=NETWORK \
       --update-strategy=CONSENSUS
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫PEERING_NAME: השם של תצורת ה-peering הקיימת.
   • ‫NETWORK: השם של הרשת בפרויקט שלכם שמקושרת באמצעות Peering.

2. כדי לראות את הסטטוס של בקשת העדכון:

   gcloud compute networks describe NETWORK
   

   מחליפים את NETWORK בשם הרשת בפרויקט שלכם שמקושרת.

   בפלט, בשדה consensusState צריך להופיע הסטטוס הבא:

   • בהגדרות של הרשת המקומית, PENDING_PEER_ACKNOWLEDGMENT
   • בהגדרת ההתאמה של רשת העמיתים, PENDING_LOCAL_ACKNOWLEDGMENT

3. כדי לאשר את בקשת העדכון, מריצים את הפקודה משלב 1 בצד העמית של החיבור.

   בדרך כלל, מנהל הרשת מבצע את השלב הזה עבור רשת ה-Peering. אחרי שהבקשה תושלם, השדה consensusState ישתנה ל-IN_SYNC בשני ההגדרות.

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

הצגת רשימה של חיבורי Peering

מציגים רשימה של חיבורי ה-Peering הקיימים כדי לראות את הסטטוס שלהם ואם הם מייבאים או מייצאים מסלולים מותאמים אישית.

המסוף

1. נכנסים לדף VPC Network Peering במסוף Google Cloud .

   מעבר ל-VPC Network Peering

2. בוחרים את חיבור ה-Peering כדי לראות את הפרטים שלו.

gcloud

gcloud compute networks peerings list

הצגת חיבור של שירותי עמיתים

המסוף

1. נכנסים לדף VPC Network Peering במסוף Google Cloud .

   מעבר ל-VPC Network Peering

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

gcloud

משתמשים בפקודה gcloud compute networks describe.

gcloud compute networks describe NETWORK

מחליפים את NETWORK בשם הרשת בפרויקט שלכם שמקושרת.

בפלט, השדה peerings.connectionStatus מתאר את הסטטוס האפקטיבי של חיבור הקישור בין רשתות שכנות (peering). מידע נוסף מופיע במאמר בנושא סטטוס החיבור.

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

המסוף

בכרטיסייה Effective routes (מסלולים אפקטיביים) אפשר לראות את כל סוגי המסלולים הרלוונטיים ברשת VPC, כולל מסלולים סטטיים של רשת משנה בקישור בין רשתות שכנות, מסלולים סטטיים של קישור בין רשתות שכנות ומסלולים דינמיים של קישור בין רשתות שכנות.

1. נכנסים לדף Routes במסוף Google Cloud .

   לדף Routes

2. בכרטיסייה Effective routes (מסלולים אפקטיביים), מבצעים את הפעולות הבאות:

   • בוחרים רשת VPC.
   • בוחרים Region.

3. לוחצים על תצוגה.

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

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

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

gcloud

משתמשים בפקודה הבאה של Google Cloud CLI כדי:

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

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

gcloud compute networks peerings list-routes PEERING_NAME \
    --network=NETWORK \
    --region=REGION \
    --direction=DIRECTION

מחליפים את מה שכתוב בשדות הבאים:

• ‫PEERING_NAME: השם של חיבור ה-peering הקיים.
• ‫NETWORK: השם של הרשת בפרויקט שלכם שמקושרת לרשת אחרת.
• ‫REGION: האזור שבו רוצים להציג את כל המסלולים הדינמיים. רשתות משנה ומסלולים סטטיים הם גלובליים ומוצגים לכל האזורים.
• ‫DIRECTION: מציין אם להציג רשימה של מסלולים שיובאו (incoming) או יוצאו (outgoing).

מחיקת חיבור של רשתות וירטואליות מקבילות

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

התהליך למחיקת חיבור קישור בין רשתות שכנות (peering) תלוי באסטרטגיית העדכון שהוגדרה לחיבור:

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

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

• אם מוחקים חיבור Peering שמשמש לגישה לשירותים פרטיים, אי אפשר ליצור חיבורים פרטיים חדשים לגישה לשירותים פרטיים. מידע נוסף זמין במאמר אי אפשר ליצור חיבור פרטי חדש.
• אם מוחקים חיבור peering שנעשה בו שימוש ב-Google Kubernetes Engine‏ (GKE), האשכול עובר למצב תיקון וכל הצמתים מציגים סטטוס UNKNOWN. מידע נוסף זמין במאמר חיבור VPC Network Peering נמחק בטעות.

מחיקת חיבור (מצב עצמאי)

כדי למחוק חיבור קישור בין רשתות שכנות (peering) במצב עצמאי (ברירת מחדל):

המסוף

1. נכנסים לדף VPC Network Peering במסוף Google Cloud .

   מעבר ל-VPC Network Peering

2. מסמנים את התיבה לצד חיבור ה-peering שרוצים להסיר.

3. לוחצים על Delete.

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

gcloud

משתמשים בפקודה gcloud compute networks peerings delete.

gcloud compute networks peerings delete PEERING_NAME \
    --network=NETWORK

מחליפים את מה שכתוב בשדות הבאים:

• ‫PEERING_NAME: השם של הגדרת ה-peering שרוצים למחוק.
• ‫NETWORK: השם של הרשת בפרויקט שלכם שמקושרת לרשת אחרת.

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

מחיקת חיבור (מצב קונצנזוס)

כדי למחוק חיבור קישור בין רשתות שכנות (peering) במצב קונצנזוס:

המסוף

1. נכנסים לדף VPC Network Peering במסוף Google Cloud .

   מעבר ל-VPC Network Peering

2. לוחצים על חיבור ה-Peering שרוצים להסיר.

3. בדף Peering connection details (פרטי חיבור ה-Peering), לוחצים על Request delete (בקשת מחיקה) ואז על Confirm (אישור).

4. כדי לאשר את בקשת המחיקה, מבצעים את שלבים 1-3 בצד העמית של החיבור.

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

5. בוחרים את חיבור ה-Peering שרוצים להסיר ולוחצים על מחיקה.

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

gcloud

משתמשים בפקודות gcloud compute networks peerings request-delete ו-gcloud compute networks peerings delete.

1. שליחת בקשת מחיקה:

   gcloud compute networks peerings request-delete PEERING_NAME \
       --network=NETWORK
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫PEERING_NAME: השם של חיבור ה-Peering שרוצים למחוק.
   • ‫NETWORK: השם של הרשת בפרויקט שלכם שמקושרת באמצעות Peering.

2. כדי לראות את הסטטוס של בקשת המחיקה:

   gcloud compute networks describe NETWORK
   

   מחליפים את NETWORK בשם הרשת בפרויקט שלכם שמקושרת.

   בפלט, בשדה deleteStatus צריך להופיע הסטטוס הבא:

   • בהגדרה של הרשת המקומית, LOCAL_DELETE_REQUESTED
   • בהגדרת ההתאמה של רשת העמיתים, PEER_DELETE_REQUESTED

3. מאשרים את בקשת המחיקה על ידי הפעלת הפקודה משלב 1 בצד העמית של החיבור.

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

4. מחיקת חיבור ה-peering:

   gcloud compute networks peerings delete PEERING_NAME \
       --network=NETWORK
   

   מחליפים את מה שכתוב בשדות הבאים:

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

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

פתרון בעיות

בקטעים הבאים מוסבר איך לפתור בעיות ב-VPC Network Peering.

אין גישה למכונות VM עמיתות

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

נתיבים מותאמים אישית חסרים

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

בדיקת מצב חיבור ה-peering

כדי לבדוק את המצב של חיבור ה-peering:

1. הצגת רשימה של חיבורי Peering.
2. מזהים את חיבור ה-Peering כדי לפתור בעיות, ובודקים את מצב ה-Peering שלו.
   1. אם המצב הוא ACTIVE, פועלים לפי השלבים שמפורטים בקטע הבא.
   2. אם מצב הקישור בין רשתות שכנות (peering) הוא INACTIVE, מנהל רשת ברשת השנייה צריך ליצור הגדרת קישור בין רשתות שכנות (peering) לרשת ה-VPC שלכם.

פתרון בעיות בחיבור ACTIVE

כדי לפתור בעיות שקשורות למסלולים מותאמים אישית שחסרים בחיבור ACTIVE peering:

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

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

   2. לוחצים על המתג הצגת מסלולים שהוסתרו כדי להעביר אותו למצב פעיל, ואז מחפשים את המסלול. כדי לראות את הסיבה להשבתת נתיב, מצביעים על הסמל בעמודה סטטוס. Google Cloud מספק פתרון לקונפליקטים בנתיבים ברשת VPC שמייבאת נתיבים באמצעות VPC Network Peering, לפי אזור.

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

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

   1. בודקים את הגדרת ה-Peering ומעדכנים אותה לפי הצורך כדי לייבא מסלולים מותאמים אישית.

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

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

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

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

   3. צריך לבקש מאדמין של רשת ה-VPC המקושרת לבצע את הפעולות הבאות:

      1. מציגים את המסלולים ברשת ה-VPC ומחפשים את המסלול הרצוי.

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

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

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

התנועה נשלחת לנקודת קפיצה לא צפויה

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

אי אפשר ליצור שותפות עם רשת VPC מסוימת

אם אתם לא מצליחים ליצור הגדרת קישור בין רשתות שכנות (peering) עם רשתות VPC מסוימות, יכול להיות שמדיניות הארגון מגבילה את רשתות ה-VPC שאפשר לקשר לרשת שלכם. במדיניות הארגון, מוסיפים את הרשת לרשימת העמיתים המורשים או פונים לאדמין של הארגון. מידע נוסף זמין במאמר בנושא constraints/compute.restrictVpcPeering.

לא מתבצעת החלפה של מסלולי IPv6

קודם כל, מוודאים שסוגי המערכים של חיבור ה-Peering ושל חיבור ה-Peering של רשת ה-VPC המקושרת מוגדרים ל-IPV4_IPV6. אם צריך:

• מעדכנים את חיבור ה-Peering כדי להגדיר את סוג ה-Stack שלו ל-IPV4_IPV6.
• צריך לבקש מאדמין ברשת ה-VPC המקבילה לעדכן את חיבור ה-Peering ולהגדיר את סוג ה-Stack שלו ל-IPV4_IPV6.

אחרי שסוגי המערכים של שני חיבורי ה-Peering מוגדרים ל-IPV4_IPV6, מתבצעת החלפה של מסלולי משנה של IPv6 (פנימיים וחיצוניים). נתיבי תת-רשת של IPv6 הם ייחודיים בין כל רשתות ה-VPC. Google Cloud

כדי להחליף מסלולים מותאמים אישית של IPv6:

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

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

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