פתרון בעיות שקשורות למדיניות ולכללים

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

לשער Secure Web Proxy אין מדיניות משויכת

אם שער Secure Web Proxy לא משויך למדיניות, כל התנועה היוצאת של HTTP ו-HTTPS נחסמת, מה שמוביל לשגיאות 403 Forbidden או לאיפוס חיבורים. הסיבה לכך היא ש-Secure Web Proxy פועל לפי מצב אבטחה deny-all כברירת מחדל, ולשער אין כללים משויכים להערכה או לאישור של בקשות. כתוצאה מכך, כל התנועה היוצאת חסומה עד ליצירת כלל מפורש של allow.

כדי לפתור את הבעיה, צריך ליצור מדיניות אבטחה עם הכללים המתאימים ולשייך אותם לשער של Secure Web Proxy.

כשלים ביצירת כללים במקביל

אין תמיכה ביצירה של כללים ל-Secure Web Proxy במקביל (הוספה של כמה כללים בו-זמנית), והפעולה הזו עלולה לגרום לשגיאות 409 Conflict או Resource busy. כדי לוודא שפריסת המופע של Secure Web Proxy בוצעה בהצלחה, צריך ליצור את הכללים ברצף (אחד אחרי השני).

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

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

ב-Secure Web Proxy מוגדר כברירת מחדל זמן קצוב לתפוגה של חוסר פעילות בסטרימינג (stream_idle_timeout) של חמש דקות (300 שניות), ואי אפשר לשנות אותו. אם הלקוח והיעד לא מחליפים נתונים במשך חמש דקות, Secure Web Proxy מאפס או סוגר את החיבור.

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

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