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

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

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

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

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

  1. פותחים חלון פרטי חדש בדפדפן.

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

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

  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.

למה קיבלתי 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 האלה לא יכולות להגיע לקצה העורפי, לא תהיה גישה לאפליקציות.

בחיבורי IAP TCP למכונות וירטואליות ספציפיות, צריך לוודא שהמכונה הווירטואלית מקבלת חיבורים מהטווח 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.

    כניסה לדף IAP

  2. לוחצים על הכרטיסייה Applications.

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

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

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

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

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

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

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

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

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

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

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

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

  • לפזר אפליקציות עם תנועה גבוהה בין כמה פרויקטים.

  • באפליקציות שמבוססות על API, השתמשו ב-Apigee או בפתרונות דומים של API Gateway.

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

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

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

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

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

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

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

למה מופיעה לי שגיאת HTTP 502 עם ההודעה "מזהה הלקוח או הסוד של לקוח OAuth בחשבון Google ריקים"?

אם אתם ניגשים לאפליקציה שמאובטחת באמצעות IAP ומופיעה השגיאה HTTP 502 Bad Gateway עם ההודעה Empty Google Account OAuth client ID(s)/secret(s)., סימן ש-IAP לא מוצא את פרטי הכניסה ל-OAuth של האפליקציה.

השגיאה הזו מתרחשת בדרך כלל בתרחישים הבאים:

קודי שגיאה

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

קוד שגיאה תיאור פתרון בעיות
‫7, HTTP 502 מזהה הלקוח או הסוד של OAuth ריק (Empty Google Account OAuth client ID(s)/secret(s).) אם הפרויקט לא שייך לארגון, מגדירים פרטי כניסה בהתאמה אישית ל-OAuth. אחרת, נכנסים לדף Credentials כדי לאמת את מזהה הלקוח והסוד, או בודקים את ההגדרות באמצעות שיטות API (GET ל-Compute Engine,‏ GET ל-App Engine) ומאפסים אותן באמצעות PATCH. מידע נוסף זמין במאמר שגיאת HTTP 502.
9 ההפניה האוטומטית של OAuth נכשלה זו שגיאה פנימית שנרשמה ביומן באופן אוטומטי. לא נדרשת כל פעולה מצידך.
‫9 (עם כללים לשכתוב נתיבים) ההפניה האוטומטית של OAuth נכשלה כללי השכתוב של הנתיב של מאזן העומסים מונעים את השלמת ה-OAuth. חשוב לוודא שבכל הקצוות העורפיים שמאחורי מאזן העומסים נעשה שימוש במזהי לקוח זהים של OAuth. אפשר לעדכן את זה באמצעות הפקודה gcloud compute backend-services update.
‫9 (עם כללי ניתוב של נתיבים) ההפניה האוטומטית של OAuth נכשלה יוצרים וריאנטים של כללי נתיב לשתי הגרסאות של כל נתיב (עם ובלי לוכסנים בסוף) ומפנים אותם לאותו קצה עורפי. לדוגמה, צריך לכלול כללים גם ל-/path/ וגם ל-/path.
11 מזהה לקוח OAuth שהוגדר באופן שגוי בודקים את מזהה הלקוח והסוד בדף Credentials. אם הן נראות נכונות אבל לא פועלות, משתמשים בשיטות 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 מופעל בכמה מקומות אי אפשר להפעיל את IAP גם בכלל העברה וגם בשירות לקצה העורפי. משביתים אותו במיקום אחד לפי ההנחיות שבקטע הפעלה ב-Compute Engine.
700, 701 בעיות בספקים של מאגרי כוח עבודה מגדירים ספק אחד בדיוק למאגר כוח העבודה. כדי לראות את הדרישות המפורטות, קראו את המגבלות של מאגרי כוח עבודה.
705 חסר מזהה לקוח OAuth לאימות זהות של כוח עבודה כדי להגדיר את IAP, קודם יוצרים מזהה לקוח ב-OAuth ואז מעדכנים את הגדרות ה-IAP.
708 שם לא חוקי של מאגר כוח עבודה מוודאים שמאגר כוח העבודה קיים ושהוא בפורמט הנכון: locations/global/workforcePools/WORKFORCE_POOL_ID.
4003 בעיה בחיבור או בחומת האש מוודאים שהתהליך של המכונה הווירטואלית פועל ומאזין ליציאה הצפויה. צריך גם לוודא שהכללים של חומת האש מאפשרים חיבורים ביציאה הזו.
4010 החיבור נסגר על ידי היעד מאפסים את ה-VM. אם הבעיות נמשכות, צריך לבדוק את auth.log (בדרך כלל ב-/var/log/) או להשתמש בקונסולה טורית כדי לקבל אבחון מפורט יותר.
4033 בעיה בהרשאה, בקיום או במצב של ה-VM מוודאים שהוקצה לכם התפקיד "משתמש מנהרה" במשאב דרך דף ה-IAP, ומוודאים שהמכונה הווירטואלית קיימת ופועלת.
4047 המכונה לא קיימת או שהיא הופסקה מוודאים שהמכונה הווירטואלית מופעלת ושהיא סיימה את רצף ההפעלה.

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