פתרון בעיות בבדיקות קישוריות

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

מידע נוסף על בדיקות קישוריות זמין בסקירה הכללית.

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

בעיות כלליות

משך הזמן לקבלת תוצאות הבדיקה ארוך מדי

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

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

ניתוח ההגדרה של הבדיקה שלי לא מזהה את שינוי ההגדרה שביצעתי

אחרי שמבצעים שינוי בהגדרות של משאבי Google Cloud נתיב הבדיקה, כדאי להשתמש בניתוח ההגדרות של הבדיקה כדי לאמת את השינוי. עם זאת, לוקח בין 20 ל-120 שניות עד שבדיקות קישוריות מקבלות עדכון של ההגדרות ומשלבות אותו בניתוח. למשאבי Google Kubernetes Engine‏ (GKE), התהליך הזה יכול להימשך עד 15 דקות. חשוב להמתין את הזמן הנוסף הזה לפני שמריצים את הבדיקות.

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

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

בדיקת בעיות במצב

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

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

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

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

הבדיקה שלי מראה מצב ניתוח סופי של ההגדרה Deliver, אבל הקישוריות לא תקינה

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

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

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

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

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

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

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

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

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

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

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

בבדיקה שלי התקבלה תוצאת ניתוח כללית של ההגדרה Abort עם ההודעה Invalid Argument

אלה כמה סיבות נפוצות להודעה Invalid Argument:

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

כשמשתמשים ב-Network Management API, ההודעה Invalid Argument מוחזרת בדרך כלל בגלל אחת מהסיבות הבאות:

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

תוצאת ניתוח ההגדרה היא Packet could not be delivered, אבל ניתוח של מישור הנתונים בזמן אמת מצביע על כך שכל החבילות נמסרו

יכולות להיות כמה סיבות לכך שאין התאמה בין הנתונים. אלה הסיבות האפשריות והפתרונות:

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

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

תוצאת ניתוח ההגדרה היא Packet could be delivered, אבל ניתוח של מישור הנתונים בזמן אמת מצביע על אובדן חלקי של מנות

יכולות להיות כמה סיבות לכך שאין התאמה בין הנתונים. סיבות אפשריות ופתרונות:

  • הגבלת קצב העברת הנתונים (throttling) מופעלת במכונה הווירטואלית של המקור או היעד, כי היא חורגת מרוחב הפס המותר לתעבורת נתונים יוצאת או לתעבורת נתונים נכנסת. כדי לנתח את נפח התנועה של המכונה הווירטואלית, נכנסים לדף VM instance details (פרטי המכונה הווירטואלית) ובודקים את הפרטים בכרטיסייה Monitoring (מעקב). בודקים את המדד Network Bytes ומשווים אותו למגבלות רוחב הפס שמתוארות עבור סוג המכונה בקטע רוחב פס ברשת.

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

תוצאת ניתוח ההגדרה היא Packet could be delivered וניתוח מישור הנתונים בזמן אמת מראה מסירה מלאה, אבל יש אובדן באפליקציה שלי

יכולות להיות כמה סיבות לכך שאין התאמה בין הנתונים. סיבות אפשריות ופתרונות:

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

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

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

ה-Network Management API החזיר את הערך INTERNAL_ERROR

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

סיבות ספציפיות לביטול

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

אין טווחי כתובות IP ללא שרת

הבדיקה בוטלה כי לא הוקצו כתובות יציאה של Direct VPC לגרסה או לעבודה.

סיבה אפשרית

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

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

המלצות

  1. צופים בכתובות ה-IP שהוקצו לתיקון או לעבודה, כמו שמתואר במאמר הצגת כתובות IP שהוקצו.
  2. מוודאים שכתובות ה-IP נמצאות בשימוש על ידי Serverless ומשויכות לתת-הרשת שהוגדרה לגרסה או לעבודה של Cloud Run. אם אין כתובות IP כאלה, צריך לשלוח תנועה לגרסה של Cloud Run או להריץ את העבודה כדי להפעיל את ההקצאה.

Google Cloud בעיות במסוף

המסוף Google Cloud לבדיקות קישוריות קרס

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

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