במסמך הזה מפורטות תשובות לשאלות נפוצות בנושא Identity-Aware Proxy (IAP) ומדריכים לפתרון בעיות.
פתרון בעיות בכניסה לחשבון בדפדפן
אם נתקלתם בשגיאות במהלך הכניסה או כשניסיתם לגשת לאפליקציה, בדיקת תעבורת הרשת של הדפדפן יכולה לעזור לכם לאבחן את הבעיה.
בדיקת תנועת הרשת
- פותחים חלון חדש במצב פרטי בדפדפן (ב-Chrome זה נקרא מצב פרטי).
- פותחים את הכלים למפתחים בדפדפן ועוברים לכרטיסייה רשת.
- בוחרים באפשרות Preserve log כדי לתעד את כל הבקשות במהלך ההפניות האוטומטיות.
- משחזרים את הבעיה על ידי מעבר לכתובת ה-URL שבה נתקלתם בבעיות.
- בודקים את בקשות לאחזור מהרשת ביומן כדי לזהות איפה התרחשה השגיאה.
ניתוח תנועת הרשת
כשניגשים לאפליקציה שמוגנת על ידי 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.
למידע על טיפול בשגיאות שקשורות להפעלת תכונות בתוך האפליקציה, אפשר לעיין במאמר בנושא ניהול הפעלת תכונות בתוך האפליקציה.
למה מופיע לי 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:
tunnel.cloudproxy.app-
mtls.tunnel.cloudproxy.app(כאשר מופעלת גישה שמבוססת על אישורים)
למה קיבלתי את ההודעה 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, מבצעים את הפעולות הבאות:
עוברים לדף של הרכישה מתוך האפליקציה.
לוחצים על הכרטיסייה Applications (אפליקציות).
בעמודה משאב, מוצאים את האפליקציה ומסמנים את תיבת הסימון.
בשדה כתובת ה-URL לאימות או כתובת ה-URL להתחברות, מוודאים שכתובת ה-URL נכונה.
במאמר אימות משתמשים עם זהויות חיצוניות מוסבר איך משתמשים בזהויות חיצוניות עם IAP.
איך אפשר לטפל בשגיאות שקשורות לחריגה מהמכסה (קוד שגיאה 429)?
קוד השגיאה 429 מופיע כשהאפליקציה חורגת ממגבלות הבקשות של IAP. השירות אוכף מכסות נפרדות:
- בקשות שמבוססות על דפדפן: 360,000 לדקה לכל פרויקט
- בקשות פרוגרמטיות: 360,000 לדקה לכל פרויקט
בקשה פרוגרמטית היא בקשה שכוללת כותרת AUTHORIZATION או PROXY-AUTHORIZATION ולא קובץ Cookie של IAP. כל הבקשות האחרות (כולל בקשות ללא פרטי כניסה) נחשבות לבקשות מדפדפן.
המגבלות האלה חלות על כל המשאבים שמוגנים על ידי רכישות מתוך האפליקציה בפרויקט.
אם נתקלתם בשגיאות שקשורות למכסת השימוש, כדאי לנסות את הפתרונות הבאים:
- אל תבצעו בדיקות עומס בסביבת הייצור. במקום זאת, צריך להשתמש בנתיבי רשת חלופיים שעוקפים את IAP.
- בתנועה משירות לשירות, כדאי להטמיע השהיה מעריכית לפני ניסיון חוזר (exponential backoff) כדי לטפל בשגיאות 429 בצורה חלקה.
- חלוקת אפליקציות עם תעבורה גבוהה בין כמה פרויקטים.
- שימוש ב-Apigee או בפתרונות דומים של API Gateway לאפליקציות מבוססות API.
- אם הבעיה נגרמת כתוצאה מצמיחה אורגנית, אפשר לפנות אל Google Cloud התמיכה כדי לבקש הגדלה של המכסה.
בעיות בכניסה או התנהגות לא צפויה ב-IAP באמצעות Identity Platform
כשמשתמשים בספק זהויות (IdP) של צד שלישי עם Identity Platform, נתוני הצהרות גדולים בטוקן של מזהה עלולים לגרום לקובץ Cookie זמני של סשן IAP לחרוג ממגבלות הגודל של הדפדפן (בדרך כלל בסביבות 4KB). מודול IAP שומר מידע על הסשן, כולל ההצהרות האלה, בקובצי Cookie בדפדפן.
חריגה ממגבלת הגודל של קובץ Cookie זמני עלולה לגרום לכשלים בכניסה לחשבון או ללולאות אינסופיות של כניסה לחשבון. כדי למנוע את הבעיות האלה, כדאי לבצע את הפעולות הבאות:
צמצום הטענות: מגדירים את ספק הזהויות (IdP) של צד שלישי כך שישלח רק טענות חיוניות ל-Identity Platform. צריך לצמצם את הגודל ואת מספר הטענות שנכללות באסימון.
בדיקת הגודל של קובצי Cookie: אפשר להשתמש בכלים למפתחים בדפדפן כדי לבדוק את הגודל של קובצי ה-Cookie שמוגדרים בדומיין של האפליקציה. מחפשים אזהרות שקשורות לגודל קובץ ה-Cookie, במיוחד קובצי Cookie שקשורים לרכישות מתוך האפליקציה.
בדיקת טענות מינימליות: מגדירים באופן זמני את ספק הזהויות כך שישלח את קבוצת הטענות הקטנה ביותר האפשרית. אם הבעיה נפתרת, זה מאשר שהגבלת גודל קובצי ה-Cookie היא שורש הבעיה.
למה קיבלתי שגיאת HTTP 502 עם ההודעה 'מזהי לקוח/סודות OAuth ריקים של חשבון Google'?
אם אתם ניגשים לאפליקציה שמאובטחת באמצעות IAP ומופיעה השגיאה HTTP 502 Bad Gateway עם ההודעה Empty Google Account OAuth client ID(s)/secret(s)., סימן שמערכת IAP לא מוצאת פרטי כניסה ל-OAuth עבור האפליקציה שלכם.
השגיאה הזו מתרחשת בדרך כלל בתרחישים הבאים:
- הפרויקט לא שייך לארגון: לקוח OAuth שמוגדר כברירת מחדל ומנוהל על ידי Google זמין רק לפרויקטים ששייכים לGoogle Cloud ארגון. אם הפרויקט לא שייך לארגון, צריך להגדיר פרטי כניסה מותאמים אישית ל-OAuth ב-App Engine או בפלטפורמה הרלוונטית.
- פרטי הכניסה של OAuth נמחקו או לא הוגדרו: אם הגדרתם בעבר פרטי כניסה מותאמים אישית של OAuth ולקוח OAuth נמחק, צריך ליצור מחדש את פרטי הכניסה בדף פרטי הכניסה ולעדכן את הגדרות ה-IAP כמו שמתואר במאמר שימוש בלקוחות OAuth בהתאמה אישית עם IAP.
קודי שגיאה
בטבלה הבאה מפורטים קודי שגיאה והודעות שגיאה נפוצים שמוחזרים כשמגדירים ומשתמשים ב-IAP.
| קוד שגיאה | תיאור | פתרון בעיות |
|---|---|---|
| 7, HTTP 502 | מזהה לקוח או סוד לקוח ב-OAuth ריקים (Empty Google Account OAuth client ID(s)/secret(s).) |
אם הפרויקט לא שייך לארגון, מגדירים פרטי כניסה מותאמים אישית ל-OAuth. אחרת, אפשר להיכנס לדף פרטי הכניסה כדי לאמת את מזהה הלקוח ואת הסוד, או לבדוק את ההגדרות באמצעות שיטות 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 שהוגדר בצורה לא נכונה | בודקים את מזהה הלקוח ואת הסוד בדף פרטי הכניסה. אם ההגדרות נראות נכונות אבל לא פועלות, אפשר להשתמש בשיטות 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. חשוב להקפיד להסיר את סוד הלקוח מהתשובה.