סיבות לאובדן מנות בדיקה

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

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

כתובת IP זרה לא מורשית

החבילה נמחקת כי מכונה של Compute Engine יכולה לשלוח או לקבל חבילות עם כתובת IP חיצונית רק אם העברת ה-IP מופעלת.

סיבה אפשרית

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

המלצות

יוצרים מכונה של Compute Engine עם הפעלת העברת IP, או מגדירים את המאפיין המתאים למכונה הקיימת. מידע נוסף זמין במאמר בנושא הפעלת העברת כתובות IP למופעים.

השיחה נותקה בגלל כלל בחומת האש

יכול להיות שהמנה תבוטל בגלל כלל חומת אש, אלא אם המנה מותרת בגלל מעקב אחר חיבורים.

סיבה אפשרית

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

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

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

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

המלצות

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

השיחה נותקה כי לא נמצא מסלול תואם

המנה נפסלת כי אין מסלולים תואמים.

סיבה אפשרית

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

המלצות

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

אם מנסים לגשת לנקודת הקצה של היעד באמצעות כתובת ה-IP הפנימית שלה, צריך לוודא שהרשתות של המקור והיעד מחוברות (לדוגמה, באמצעות קישור בין רשתות VPC שכנות, Network Connectivity Center או פתרון קישוריות היברידי כמו Cloud VPN).

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

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

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

מידע נוסף מופיע במאמרים בנושא מסלולים ושימוש במסלולים.

החבילה נשלחת לרשת שגויה

החבילה נשלחת לרשת לא מיועדת. לדוגמה, אתם מריצים בדיקה ממכונה של Compute Engine ברשת network-1 למכונה של Compute Engine ברשת network-2, אבל המנה נשלחת לרשת network-3.

סיבה אפשרית

לרשת network-1 יש מסלול עם טווח יעד שכולל את כתובת ה-IP של מכונת היעד, כשהצעד הבא הוא ברשת אחרת (network-3 בדוגמה שלמעלה).

המלצות

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

כתובת ה-IP של הצעד הבא במסלול לא נפתרה

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

סיבה אפשרית

אם מדובר במסלול עם next-hop-address, כתובת ה-Hop הבא חייבת להיות כתובת IPv4 פנימית ראשית או כתובת IPv6 של מכונת Compute Engine ברשת ה-VPC של המסלול. אין תמיכה בכתובות ברשתות שבוצע בהן שיתוף פעולה.

אם מדובר במסלול עם next-hop-ilb, כתובת הניתוב הבאה חייבת להיות כתובת של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי (לא נתמכות העברות פרוטוקול או נקודות קצה של Private Service Connect, וגם לא כללי העברה שמשמשים מאזני עומסים אחרים). כתובת ה-IP צריכה להיות מוקצית למשאב ברשת ה-VPC של המסלול, או ברשת שמקושרת אליה באמצעות קישור בין רשתות VPC שכנות (peering).

המלצות

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

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

החבילה נשלחת ליעד באמצעות מסלול לא תקין, והמכונה הבאה במסלול (next hop) ב-Compute Engine לא כוללת בקר ממשק רשת (NIC) ברשת של המסלול.

סיבה אפשרית

למכונת Compute Engine שמשמשת כצעד הבא במסלול חייב להיות כרטיס רשת (NIC) ברשת של המסלול (לא ברשת VPC שנוצרה באמצעות שותפות).

המלצות

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

כתובת ה-IP של הצעד הבא במסלול היא לא כתובת ה-IP הראשית של מכונה וירטואלית

החבילה נשלחת ליעד באמצעות מסלול לא תקין, וכתובת ה-IP של הצעד הבא (next-hop-address) היא לא כתובת IP ראשית של מכונת Compute Engine.

סיבה אפשרית

כתובת ה-IP של הצעד הבא במסלול (next-hop-address) חייבת להיות כתובת IPv4 פנימית ראשית של מכונת Compute Engine. אין תמיכה בטווחים של כתובות IP של כינויים.

המלצות

מוודאים שכתובת ה-IP של הצעד הבא היא כתובת IPv4 פנימית ראשית של מכונת Compute Engine. מידע נוסף זמין במאמר שיקולים לגבי מופעים של הניתוב הבא.

הסוג של כלל ההעברה של הניתוב לקפיצה הבאה לא תקין

החבילה נשלחת ליעד באמצעות מסלול לא תקין, וכלל ההעברה של הצעד הבא (next-hop-ilb) הוא לא כלל העברה של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי.

סיבה אפשרית

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

המלצות

יוצרים מסלול לכלל העברה נתמך במקום למסלול לא תקין.

תנועה פרטית לאינטרנט

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

סיבה אפשרית

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

המלצות

אם רוצים לגשת ליעד דרך האינטרנט, צריך לוודא שלמכונה המקורית ב-Compute Engine יש קישוריות לאינטרנט – למשל, יש לה כתובת IP חיצונית או שהיא משתמשת ב-Cloud NAT – ולהשתמש בכתובת ה-IP החיצונית של נקודת הקצה של היעד בבדיקה.

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

  1. אם נקודת היעד נמצאת ברשת מקומית, צריך להשתמש בפתרון NCC או בפתרון קישוריות היברידי, כמו Cloud VPN או Cloud Interconnect.
  2. אם נקודת הקצה של היעד נמצאת בתוך Google Cloud:
    1. הגדרת קישור בין רשתות VPC שכנות (peering) בין רשתות VPC.
    2. הגדרת Cloud VPN בין רשתות VPC.
    3. הגדרת קישוריות לרשת באמצעות Network Connectivity Center VPC spokes.

  3. אם כבר יש לכם חיבור לרשת היעד:

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

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

    קישור מעבר בין רשתות VPC שכנות (peering) לא אפשרי. אפשר להשתמש ב-VPN או בקישור בין רשתות שכנות (peering) עבור שתי רשתות ה-VPC האלה.

הגישה הפרטית ל-Google אסורה

מכונת VM ב-Compute Engine שיש לה רק כתובת IP פנימית מנסה להגיע לכתובת ה-IP החיצונית של שירותים וממשקי Google API, אבל הגישה הפרטית ל-Google לא מופעלת ברשת המשנה של המכונה.

המלצות

אפשר לאפשר למכונה וירטואלית ב-Compute Engine להגיע לכתובת ה-IP החיצונית של ממשקי ה-API והשירותים של Google באחת מהדרכים הבאות:

  1. מפעילים את הגישה הפרטית ל-Google עבור רשת המשנה של המופע.
  2. מקצים כתובת IP חיצונית ל-NIC של Compute Engine.
  3. מפעילים את Cloud NAT עבור רשת המשנה של מופע ה-VM.

אין תמיכה בגישה פרטית ל-Google דרך מנהרת VPN

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

סיבה אפשרית

המנות מנקודת הקצה של המקור לכתובת ה-IP החיצונית של ממשקי ה-API והשירותים של Google מנותבות דרך מנהרת Cloud VPN, אבל הגדרה כזו לא נתמכת.

המלצות

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

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

כתובת פנימית לא ידועה

אי אפשר לפתור את כתובת ה-IP הפנימית של היעד לטירגוט מוכר.

המלצות

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

אי התאמה של כלל העברה

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

סיבה אפשרית

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

המלצות

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

חוסר התאמה באזור של כלל העברה

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

סיבה אפשרית

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

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

המלצות

אם אתם מתחברים למאזן העומסים מנקודת קצה של Google Cloud , כמו מכונה וירטואלית ב-Compute Engine, ודאו שהיא ממוקמת באותו אזור שבו נמצא כלל ההעברה.

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

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

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

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

סיבה אפשרית

כדי שבדיקות התקינות יפעלו, צריך ליצור כללי חומת אש שמאפשרים תעבורת נתונים נכנסת (ingress) מ Google Cloud הבודקים לשרתים העורפיים (backend) שלכם. אחרת, הקצוות העורפיים נחשבים לא תקינים.

המלצות

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

אין כתובת חיצונית זמינה

מכונה וירטואלית עם כתובת IP פנימית בלבד ניסתה לגשת למארחים חיצוניים דרך מסלול שהצעד הבא שלו הוא שער האינטרנט שמוגדר כברירת מחדל. התנהגות צפויה כש-Cloud NAT לא מופעל ברשת המשנה או כשאין נתיב ברירת מחדל אחר שמשתמש בסוג אחר של קפיצה הבאה (כמו מכונת proxy וירטואלית).

סיבה אפשרית

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

המלצות

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

כלל העברה ללא מקרים

כלל ההעברה לא משויך לאף שרת קצה עורפי.

סיבה אפשרית

הירידה הזו מתרחשת מהסיבות הבאות:

  • לא מצורפים קצוות עורפיים לשירות הקצה העורפי של מאזן העומסים.
  • כלל ההעברה מפנה לשרת proxy ליעד, ושרת ה-proxy ליעד הזה חסרה הגדרת הניתוב שלו:
    • מאזני עומסים של אפליקציות (ALB): שרת proxy לחלוקת העומס לא משויך למפת URL.
    • מאזני עומסים של רשתות proxy שמשתמשים בניתוב של Server Name Indication‏ (SNI): proxy היעד לא משויך לנתיב TLS.

המלצות

בודקים את ההגדרות של מאזן העומסים באופן הבא:

  • מוודאים שיש קצה עורפי שמצורף לשירות הקצה העורפי שמוגדר כברירת מחדל.
  • במאזני עומסים של אפליקציות, צריך לוודא ששרת proxy לחלוקת העומס מפנה אל מפת URL וששירותי הקצה העורפי שמוגדרים במפת ה-URL כוללים בק-אנד מצורף.
  • במקרה של איזון עומסים בשרת proxy ברשת שמשתמש בניתוב SNI, צריך לוודא ששרת ה-proxy של היעד מופיע לפחות בנתיב TLS אחד, וששירות ה-backend או השירותים שמוגדרים בנתיב ה-TLS מחוברים ל-backend.

סוג התנועה חסום

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

סיבה אפשרית

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

  1. שליחת תעבורת נתונים יוצאת (egress) ליעד חיצוני עם יציאת TCP ‏25 ‏(SMTP). פרטים נוספים זמינים במאמר בנושא תנועה שנחסמת תמיד.
  2. שליחת תנועה ליציאה לא נתמכת במכונת Cloud SQL. לדוגמה, שליחת תנועה ליציאת TCP ‏3310 למכונת MySQL Cloud SQL עם יציאה 3306 פתוחה.
  3. שליחת תעבורת נתונים יוצאת מגרסה של סביבת ברירת המחדל ב-App Engine, מפונקציית Cloud Run, מגרסת Cloud Run או מעבודת Cloud Run שמשתמשת בפרוטוקול שאינו TCP או UDP.

המלצות

לגבי תעבורת SMTP יוצאת (תעבורת נתונים יוצאת ליעד חיצוני עם יציאת TCP ‏25), אפשר לעיין במאמר בנושא שליחת אימייל ממופע.

בפרוטוקול DHCP, כולל חבילות UDP IPv4 ליעד יציאה 68 (תגובות DHCPv4) וחבילות UDP IPv6 ליעד יציאה 546 (תגובות DHCPv6), תנועת DHCP מותרת רק משרת המטא-נתונים (169.254.169.254).

לגבי קישוריות ל-Cloud SQL, צריך לוודא שהיציאה שבה נעשה שימוש נכונה.

אין הרשאה לגשת למישור הבקרה של אשכול GKE

הגישה למישור הבקרה של אשכול GKE מכתובת ה-IP של המקור לא מורשית.

סיבה אפשרית

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

המלצות

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

הגישה למכונת Cloud SQL לא מורשית

הגישה למכונת Cloud SQL מכתובת ה-IP של המקור לא מורשית.

סיבה אפשרית

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

המלצות

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

אין תמיכה בתגי רשת ביציאה ישירה מ-VPC בכללי חומת אש לכניסה

המערכת מפסיקה את החבילה כי Direct VPC egress לא תומך בתגי רשת מקור בכללי חומת אש של תעבורת כניסה.

סיבה אפשרית

אין תמיכה בהתאמה של כללי חומת אש לתעבורת נתונים נכנסת (ingress) לפי תגי רשת של מקור עבור חיבורי Cloud Run דרך Direct VPC. מידע נוסף מופיע בקטע מגבלות.

המלצות

מעדכנים את כללי חומת האש כך שישתמשו בטווחי כתובות IP של המקור במקום בתגי רשת של המקור, כדי להתאים לתעבורת נתונים מחיבורי Cloud Run דרך Direct VPC egress.

חיבור לרשת VPC מאפליקציית serverless לא מוגדר

המערכת הפסיקה את העברת המנה כי לא הוגדר מחבר Serverless VPC Access בגרסה של סביבת App Engine Standard, בפונקציית Cloud Run, בגרסת Cloud Run או במשימה של Cloud Run.

סיבה אפשרית

כתובת ה-IP של היעד היא כתובת IP פרטית, שלא ניתן להגיע אליה דרך האינטרנט. החבילה יוצאת מהמקור, אבל לא מוגדר מחבר Serverless VPC Access לגרסה של סביבת App Engine רגילה, לפונקציית Cloud Run, לגרסת Cloud Run או למשימת Cloud Run.

המלצות

אם מנסים לגשת לנקודת הקצה של היעד באמצעות כתובת ה-IP הפרטית שלה, צריך לוודא שהגדרתם מחבר של חיבור לרשת (VPC) מאפליקציית serverless לגרסה של סביבת ברירת המחדל ב-App Engine, לפונקציית Cloud Run או לגרסה או למשימה של Cloud Run.

מחבר הגישה לרשת VPC של serverless לא פועל

המערכת הפסיקה את העברת החבילה כי מחבר הגישה ל-VPC ללא שרת לא פועל.

סיבה אפשרית

המנות נמחקו כי כל המכונות של מחבר Serverless VPC Access הופסקו.

המלצות

רשימת השלבים לפתרון בעיות מופיעה במאמר פתרון בעיות.

חיבור Private Service Connect לא מתקבל

המנה הושמטה כי החיבור ל-Private Service Connect לא אושר.

סיבה אפשרית

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

המלצות

מוודאים שנקודת הקצה של Private Service Connect נמצאת בפרויקט שאושר להתחבר לשירות המנוהל.

גישה לנקודת קצה של Private Service Connect מרשת מקושרת

החבילה נשלחת לנקודת הקצה של Private Service Connect ברשת המקבילה, אבל הגדרה כזו לא נתמכת.

המלצות

מומלץ לעבור לארכיטקטורת רכזת וחישורים שמשתמשת ב-Network Connectivity Center כדי להפעיל הפצה של חיבור Private Service Connect.

אפשר גם להשתמש באחד מדפוסי הקישוריות הבאים:

לקבלת עזרה נוספת, אפשר לפנות לתמיכה של בעלים של שירות מנוהל או Google Cloud לנציג.

אין מסלול תקין מרשת שמנוהלת על ידי Google ליעד

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

סיבת ההשמטה הזו רלוונטית לכל שירות שמנוהל על ידי Google ונתמך על ידי בדיקות קישוריות, כולל Cloud SQL ו-GKE.

המלצות

בודקים אם השירות שמנוהל על ידי Google מוגדר לשליחת תנועה ליעד.

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

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

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

  • אם היעד אמור להיות נגיש דרך מסלולים דינמיים שיובאו לרשת של השירות שמנוהל על ידי Google דרך VPC Network Peering, יכול להיות שתגיעו למגבלה Dynamic routes per region per peering group של רשת השירות. אם לדעתכם הגעתם למגבלה הזו, אתם יכולים לפתוח בקשת תמיכה.