פתרון בעיות ושאלות נפוצות

במסמך הזה מפורטות תשובות לשאלות נפוצות בנושא Identity-Aware Proxy ‏ (IAP) ומופיעים בו מדריכים לפתרון בעיות.

פתרון בעיות בכניסה לאתר

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

בדיקת התנועה ברשת

  1. פותחים חלון חדש במצב פרטי (ב-Chrome) או בגלישה פרטית (בדפדפן).
  2. פותחים את הכלים למפתחים בדפדפן ועוברים לכרטיסייה רשת.
  3. בוחרים באפשרות שמירת יומן הרישום כדי לתעד את כל הבקשות במהלך ההפניות האוטומטיות.
  4. משחזרים את הבעיה על ידי מעבר לכתובת ה-URL שבה נתקלתם בבעיות.
  5. בודקים את בקשות הרשת ביומן כדי לזהות איפה אירעה השגיאה.

ניתוח תנועה ברשת

כשניגשים לאפליקציה שמוגנת על ידי IAP, מועברים לדף הכניסה. אחרי אימות מוצלח אצל ספק הזהויות, נשלחת בקשה לדומיין https://iap.googleapis.com להשלמת האימות לפני הנפקת קובץ Cookie של IAP והפניה אוטומטית לאפליקציה.

אפשר לפתור בעיות לפי הדומיין שבו השגיאה מתרחשת:

  • שגיאות ב-iap.googleapis.com: אם מתרחשת שגיאה בדומיין iap.googleapis.com, מוצגת הודעת שגיאה מפורטת בדף. אם השגיאה קשורה להגדרות של IAP, כמו בעיות בלקוח OAuth, צריך לשנות את ההגדרות. אם נתקלתם בשגיאות בצד הלקוח שאתם לא יודעים איך לפתור, או אם מופיעות שגיאות בשרת, אתם יכולים לפתוח Google Cloud כרטיס תמיכה.
  • שגיאות בדומיין האפליקציה: אם מתרחשת שגיאה אחרי שמועברים לדומיין האפליקציה שמוגן על ידי IAP, מוצג קוד שגיאה. פרטים על שגיאות נפוצות מופיעים בקטע קודי שגיאות. אם לא הצלחתם לפתור את הבעיה, אפשר לפתוח כרטיס תמיכה שלGoogle Cloud .

אילו אפליקציות אפשר לאבטח באמצעות IAP?

אפשר להשתמש ב-IAP עם:

  • אפליקציות בסביבה הרגילה של App Engine ובסביבה הגמישה של App Engine
  • מכונות Compute Engine עם שירותים לקצה העורפי של איזון עומסים ב-HTTP(S)
  • קונטיינרים של Google Kubernetes Engine
  • אפליקציות Cloud Run עם שירותים לקצה העורפי של איזון עומסים ב-HTTP(S)
  • Cloud Run בלחיצה אחת ללא שירותי קצה עורפי של איזון עומסים

אי אפשר להשתמש ב-IAP עם Cloud CDN.

למה מופיע # בסוף כתובת ה-URL אחרי שנכנסתי לאפליקציה שלי?

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

למה הבקשות שלי נכשלות ומוחזרת השגיאה 405 Method Not Allowed?

מצב כזה קורה בדרך כלל כשקובצי Cookie לא מצורפים לבקשות. שיטות JavaScript לא מצרפות קובצי Cookie כברירת מחדל.

שיטות שונות לשליחת בקשות דורשות גישות שונות:

  • עבור XMLHttpRequest, מגדירים את withCredentials לערך true.
  • ב-Fetch API, מגדירים את credentials לערך include או same-origin.

למידע על טיפול בשגיאות שקשורות להפעלת IAP, אפשר לעיין במאמר בנושא ניהול הפעלות IAP.

למה מופיע לי HTTP 401 Unauthorized במקום 302 Redirect?

‫IAP שולח 302 Redirect רק אם הלקוח מוגדר לטיפול בהפניות אוטומטיות.

מוסיפים את HTTP Accept="text/html,*/*" לכותרות הבקשה כדי לציין תמיכה בהפניות אוטומטיות.

למה בקשות POST לא מפעילות הפניות אוטומטיות?

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

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

  • אסימון מזהה בכותרת Authorization: Bearer
  • קובצי Cookie תקינים (ראו רענון סשנים)

האם אפשר להשתמש ב-IAP אם השבתתי את ה-API?

כן, אפשר להמשיך לגשת למשאבים שמאובטחים באמצעות IAP גם כשה-API מושבת, אבל לא תוכלו לשנות את הרשאות ה-IAM.

איך אפשר למנוע ממשתמשים עם תפקיד הבעלים להשתמש ב-IAP עבור TCP?

מומלץ להגביל את השימוש בתפקיד 'בעלים' (roles/owner) ולהשתמש בהרשאות מפורטות יותר. הנחיות נוספות זמינות במאמר בנושא שיטות מומלצות לשימוש ב-IAM.

אם זה לא אפשרי, אפשר לחסום את IAP עבור TCP באמצעות כללים של חומת אש.

באיזה דומיין משתמש IAP ל-TCP?

שרת IAP משתמש בדומיינים הבאים שבבעלות Google:

למה קיבלתי Server Error?

אם מופיע:

The server encountered a temporary error and could not complete your request. Please try again in 30 seconds.

יכול להיות שחומת האש חוסמת את כתובות ה-IP של מאזן העומסים.

בודקים שחומת האש מאפשרת תנועה מ-130.211.0.0/22 ומ-35.191.0.0/16. אם כתובות ה-IP האלה לא יכולות להגיע לקצה העורפי שלכם, לא תהיה גישה לאפליקציות שלכם.

בחיבורי TCP של IAP למכונות וירטואליות ספציפיות, צריך לוודא גם שהמכונה הווירטואלית מקבלת חיבורים מהטווח 35.235.240.0/20.

למה אני מקבל שגיאות שרת פנימיות לסירוגין?

הודעות כמו An internal server error occurred while authorizing your request. Error code X מצביעות על כשלים בשרת העורפי.

קודי השגיאה 1, 30, 62, 63, 64 או 703 בדרך כלל משקפים בעיות זמניות. הטמעה של השהיה מעריכית לפני ניסיון חוזר (exponential backoff) לביצוע ניסיונות חוזרים.

איך לתקן שגיאות ב-Identity Platform (קוד שגיאה 38)

קוד השגיאה 38 מציין שכתובת ה-URL לאימות ב-Identity Platform עבור הזהות החיצונית שלכם לא מוגדרת בצורה נכונה ב-IAP.

כדי למצוא את כתובת ה-URL, מבצעים את הפעולות הבאות:

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

    כניסה לדף IAP

  2. לוחצים על הכרטיסייה אפליקציות.

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

  4. בשדה כתובת ה-URL לאימות או כתובת ה-URL להתחברות, מוודאים שכתובת ה-URL נכונה.

במאמר אימות משתמשים עם זהויות חיצוניות מוסבר איך משתמשים בזהויות חיצוניות עם IAP.

איך אפשר לטפל בשגיאות שקשורות לחריגה ממכסה (קוד שגיאה 429)?

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

  • בקשות מבוססות-דפדפן: 360,000 לדקה לכל פרויקט
  • בקשות פרוגרמטיות: 360,000 לדקה לכל פרויקט

בקשה פרוגרמטית היא בקשה שכוללת כותרת AUTHORIZATION או PROXY-AUTHORIZATION ולא כוללת קובץ Cookie של רכישה מתוך האפליקציה. כל הבקשות האחרות (כולל אלה ללא פרטי כניסה) נחשבות לבקשות מדפדפן.

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

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

  • אל תבצעו בדיקות עומס בסביבת הייצור. במקום זאת, צריך להשתמש בנתיבי רשת חלופיים שעוקפים את IAP.
  • בתנועה משירות לשירות, כדאי להטמיע השהיה מעריכית לפני ניסיון חוזר (exponential backoff) כדי לטפל בשגיאות 429 בצורה חלקה.
  • חלוקת אפליקציות עם תעבורה גבוהה בין כמה פרויקטים.
  • משתמשים ב-Apigee או בפתרונות דומים של שער API לאפליקציות מבוססות API.
  • אם הבעיה נגרמת כתוצאה מצמיחה אורגנית, אפשר לפנות אל Google Cloud התמיכה כדי לבקש הגדלה של המכסה.

בעיות בכניסה או התנהגות לא צפויה ב-IAP באמצעות Identity Platform

כשמשתמשים בספק זהויות (IdP) של צד שלישי עם Identity Platform, נתוני טענות גדולים באסימון המזהה עלולים לגרום לקובץ ה-cookie של סשן IAP לחרוג ממגבלות הגודל של הדפדפן (בדרך כלל בסביבות 4KB). ‫IAP שומר מידע על הסשן, כולל הטענות האלה, בקובצי Cookie של הדפדפן.

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

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

  • בדיקת הגודל של קובצי Cookie: אפשר להשתמש בכלים למפתחים בדפדפן כדי לבדוק את הגודל של קובצי ה-Cookie שמוגדרים בדומיין של האפליקציה. מחפשים אזהרות שקשורות לגודל קובץ ה-Cookie, במיוחד קובצי Cookie שקשורים לרכישות מתוך האפליקציה.

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

קודי שגיאה

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

קוד שגיאה תיאור פתרון בעיות
7 מזהה לקוח או סוד לקוח ריקים ב-OAuth כדי לאמת את הסוד ומספר הלקוח, עוברים אל דף פרטי הכניסה. אם ההגדרות נראות תקינות אבל לא פועלות, אפשר להשתמש בשיטות API כדי לבדוק את ההגדרות (GET ל-Compute Engine, ‏ GET ל-App Engine) ולאפס אותן באמצעות PATCH.
9 הפניה אוטומטית של OAuth נכשלה זו שגיאה פנימית שנרשמה אוטומטית ביומן. לא נדרשת כל פעולה מצידך.
‫9 (עם כללי שכתוב נתיבים) הפניה אוטומטית של OAuth נכשלה כללי השכתוב של הנתיבים במאזן העומסים מונעים את השלמת OAuth. מוודאים שכל השרתים העורפיים שמאחורי מאזן העומסים משתמשים באותם מזהי לקוח של OAuth. אפשר לעדכן את ההגדרה הזו באמצעות הפקודה gcloud compute backend-services update.
‫9 (עם כללי ניתוב נתיבים) הפניה אוטומטית של OAuth נכשלה יוצרים וריאציות של כללי נתיב לשתי הגרסאות של כל נתיב (עם לוכסן בסוף ובלי) ומפנים אותן לאותו קצה עורפי. לדוגמה, אפשר לכלול כללים גם ל-/path/ וגם ל-/path.
11 מזהה לקוח ב-OAuth שהוגדר בצורה לא נכונה בודקים את מזהה הלקוח ואת הסוד בדף הפרטים. אם ההגדרות נראות תקינות אבל לא פועלות, אפשר להשתמש בשיטות API כדי לבדוק את ההגדרות (GET ל-Compute Engine, ‏ GET ל-App Engine) ולאפס אותן באמצעות PATCH.
13 טוקן OIDC לא תקין עוברים אל דף פרטי הכניסה כדי לוודא שמזהה הלקוח לא נמחק או שונה בצורה שגויה.
51 בדפדפן אין תמיכה בחיבורים משותפים מבקשים מהמשתמשים לעדכן את הדפדפנים שלהם לגרסאות עדכניות. פרטים נוספים על דרישות החיבור זמינים במאמר בנושא הגבלת הגישה למשאבים.
52 אי התאמה בין שם המארח לבין אישור ה-SSL אדמין המערכת צריך לעדכן את אישור ה-SSL כך שיתאים לשם המארח. הנחיות מפורטות זמינות במאמר הגבלת הגישה למשאבים.
‫52 (עם רשומת מיפוי ראשית לאישורים) אי התאמה בין שם המארח לבין אישור ה-SSL ‫IAP לא תומך בערכים במפת האישורים הראשוניים. צריך להשתמש בערכים נפרדים כדי למפות כל אישור לשם המארח הנכון. הוראות מפורטות זמינות במאמר בנושא יצירת רשומה במפת אישורים.
53 שם המארח לא נמצא בדומיינים המותרים אדמין צריך להוסיף את שם המארח שלכם לרשימת הדומיינים המורשים. הוראות מפורטות זמינות במאמר בנושא הגבלת הגישה למשאבים.
‫253, HTTP 429 חרגת ממכסת הבקשות הגעת למגבלות הבקשות (360,000 לדקה לכל סוג בקשה). כדאי לשקול לפצל את עומסי העבודה בין כמה פרויקטים, להטמיע הגבלת קצב בקשות בצד הלקוח או לפנות אל התמיכה כדי לבקש הגדלה של המכסות אם נדרש גידול לגיטימי.
551 האפשרות 'רכישות מתוך האפליקציה' מופעלת בכמה מקומות אי אפשר להפעיל IAP גם בכלל העברה וגם בשירות קצה עורפי. משביתים אותו במיקום אחד לפי ההנחיות שבמאמר הפעלה ב-Compute Engine.
‫700, 701 בעיות בספקים של מאגרי כוח עבודה מגדירים בדיוק ספק אחד למאגר כוח העבודה. דרישות מפורטות מופיעות במאמר מגבלות של מאגרי כוח עבודה.
705 חסר מזהה לקוח ב-OAuth לזהויות של כוח העבודה מבצעים את תהליך ההגדרה המלא: קודם יוצרים מזהה לקוח ב-OAuth, ואז מעדכנים את הגדרות ה-IAP.
708 שם לא תקין של מאגר כוח עבודה מוודאים שמאגר כוח העבודה קיים ושהוא בפורמט הנכון: locations/global/workforcePools/WORKFORCE_POOL_ID.
4003 בעיה בחיבור או בחומת האש מוודאים שתהליך המכונה הווירטואלית פועל ומאזין ביציאה הצפויה. כדאי גם לוודא שכללי חומת האש מאפשרים חיבורים ביציאה הזו.
4010 החיבור נסגר על ידי היעד מאפסים את ה-VM. אם הבעיות נמשכות, כדאי לבדוק את auth.log (בדרך כלל ב-/var/log/) או להשתמש במסוף הטורי כדי לקבל אבחון מפורט יותר.
4033 בעיה בהרשאה, בקיום או במצב של מכונה וירטואלית מוודאים שהתפקיד 'משתמש מנהרה' הוקצה למשאב דרך דף IAP, ומוודאים שהמכונה הווירטואלית קיימת ופועלת.
4047 המכונה לא קיימת או שהיא מושבתת מוודאים שהמכונה הווירטואלית מופעלת ושהיא השלימה את רצף ההפעלה שלה.

אם לא הצלחתם לפתור את הבעיה או שהשגיאה לא מופיעה בדף הזה, תוכלו לפנות ל-Cloud Customer Care ולתאר את השגיאה ואת התגובה שקיבלתם מקריאה ל-API של GET. חשוב להקפיד להסיר את הסוד של הלקוח מהתשובה.