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

שלב 1: כתבו את שתי הזרימות

היעד המיידי של הדפדפן הוא מאזין ה-proxy, ולא כל אתר שהמשתמש מבקר בו בסופו של דבר. המשפט האחד הזה פותר את רוב הבלבול בתכנון הזה.

branch browser -> site VPN -> central proxy listener
central proxy -> approved egress policy -> website

מקורות שונים, מסלולים שונים, הרשאות שונות. שמרו את השרטוט ברשומת השינוי, כי כל בדיקה מאוחרת מתייחסת לאחד משני החצאים שלו.

שלב 2: תנו לדפדפן נתיב אל המאזין

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

החילו כלל רשת צר עבור השירות המיועד במקום לפרסם proxy ללא הגבלה באינטרנט. ה-proxy יכול להישאר ברשת פנימית כאשר ללקוחות המיועדים שלו יש נתיב נתמך אליו.

שלב 3: הגדירו את הדפדפן, לא רק את טבלת המסלולים

השתמשו בהגדרת ה-proxy של הדפדפן, בקובץ PAC או במנגנון הגילוי המנוהל של הארגון. שליחת חבילות אתר רגילות לעבר כתובת ה-proxy עם מסלול לא גורמת לדפדפן לדבר בפרוטוקול ה-proxy; זו יירוט שקוף והוא שייך לתכנון שער אחר.

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

שלב 4: הוכיחו את החיבור היוצא של ה-proxy

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

ב-HTTPS, CONNECT פותח מנהרה אל היעד המבוקש. העברה רגילה לא מוסרת ל-proxy את הדף המפוענח, וביטול אימות התעודה כדי לאלתר בדיקה אינו פתרון.

שלב 5: הבחינו בין ארבעה כשלים

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

דווחו על הגבול שצפיתם בו, לא על הסיכום שה-VPN נכשל.

שלב 6: הגדירו את ההיקף ותכננו את החלופה

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

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

מאמרים קשורים