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

במאמר הזה מוסבר איך לפתור בעיות ב-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. לוחצים על הכרטיסייה אפליקציות.

    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. חשוב לוודא שבכל ה-backends שמאחורי מאזן העומסים נעשה שימוש במזהי לקוח זהים של 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 לאימות זהות של כוח עבודה כדי להשלים את תהליך ההגדרה, קודם יוצרים מזהה לקוח ב-OAuth ואז מעדכנים את הגדרות ה-IAP.
    708 שם לא חוקי של מאגר כוח עבודה מוודאים שמאגר כוח העבודה קיים ושהוא בפורמט הנכון: locations/global/workforcePools/WORKFORCE_POOL_ID.
    4003 בעיה בחיבור או בחומת האש מוודאים שתהליך המכונה הווירטואלית פועל ומאזין ליציאה הצפויה. צריך גם לוודא שכללי חומת האש מאפשרים חיבורים ביציאה הזו.
    4010 החיבור נסגר על ידי היעד מאפסים את ה-VM. אם הבעיות נמשכות, צריך לבדוק את auth.log (בדרך כלל ב-/var/log/) או להשתמש בקונסולה טורית כדי לקבל אבחון מפורט יותר.
    4033 בעיה בהרשאה, בקיום או במצב של המכונה הווירטואלית מוודאים שמוקצה לכם התפקיד "משתמש מנהרה" במשאב דרך דף ה-IAP, ומוודאים שהמכונה הווירטואלית קיימת ופועלת.
    4047 המכונה לא קיימת או שהיא הופסקה מוודאים שהמכונה הווירטואלית מופעלת ושהיא סיימה את רצף ההפעלה.

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