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

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

לא הוגדר מסלול ברירת מחדל

כשמגדירים את הניתוב למופע של Secure Web Proxy באמצעות ניתוב סטטי או ניתוב מבוסס-מדיניות, צריך להגדיר נתיב ברירת מחדל (0.0.0.0/0).

אם לא מגדירים נתיב ברירת מחדל, ה-proxy לא יכול להעביר תעבורה ליעדים חיצוניים, ויכול להיות שיוצגו השגיאות הבאות:

  • תם הזמן הקצוב לחיבור – 504 Gateway Timeout
  • אין נתיב למארח – 502 Bad Gateway

לנתיב סטטי שמוגדר כברירת מחדל אין תג רשת

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

כדי לוודא שהתעבורה מנותבת לשרת ה-proxy, צריך גם לצרף את התג למכונות הווירטואליות (VM) של הלקוח.

תנועה שאינה HTTP או HTTPS נחסמת

Secure Web Proxy מותאם לתעבורת נתונים מבוססת-אינטרנט. תעבורת נתונים של פרוטוקול העברת נתונים מבוקרת (TCP) נחסמת אם היא מנותבת ל-Secure Web Proxy ולא מוגדרים כללים לשרת ה-Proxy של TCP לטיפול בה. חוסר התאמה כזה בדרך כלל מוביל לשגיאות Connection Refused או 400 Bad Request בפרוטוקולים כמו Secure Shell‏ (SSH) ו-File Transfer Protocol‏ (FTP).

כדי לפתור שגיאות כאלה, צריך ליצור כללי proxy ספציפיים ל-TCP לניהול התעבורה או לעדכן את הנתיבים שמבוססים על מדיניות כך שיעבירו רק יציאות כמו 80 או 443. אם תפעלו לפי אחד מהתהליכים האלה, תוכלו לוודא שתעבורת ה-TCP תעקוף את מופע ה-Secure Web Proxy ותפעל לפי הניתוב הרגיל של הענן הווירטואלי הפרטי (VPC).

פריסה של Secure Web Proxy כשער של הצעד הבא נכשלת

כדי לפתור את הבעיה:

  1. בודקים אם מופעלת מכונה וירטואלית קיימת של Secure Web Proxy כ-next hop באותו אזור. ברשת בענן וירטואלי פרטי באזור מסוים, אפשר לפרוס רק מופע אחד של Secure Web Proxy כנקודת מעבר הבאה.

  2. כדאי לבדוק את יומני הביקורת של הארגון כדי לראות אם יש כללי מדיניות שמונעים את היצירה של שערים של Cloud NAT.

  3. ודאו שאין ברשת משאבים יתומים שנוצרו באופן אוטומטי, כמו swg-autogen-router או swp-autogen-nat. אם יש כאלה, מחקו את הנתב שנוצר באופן אוטומטי ולאחר מכן פרסו מחדש את Secure Web Proxy.

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