אישור פרוקסי דפדפן ללא ראש אינו נתיב VPN

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

שתי שיחות, שתי אישורים

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

HTTP 407 הוא האות שהלקוח חייב לאמת עבור בקשת ה-proxy, הנישאת ב-Proxy-Authenticate עם התשובה הצפויה ב-Proxy-Authorization. זו לא הכניסה של אתר היעד, ושילוב בין השניים הוא המקור הנפוץ ביותר לבלבול כאן.

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

בדוק את 1: איזה פרוקסי נבחר בפועל

התחל עם בחירה, כי דפדפן שמתעלם מהגדרת ה-proxy שלך אף פעם לא מגיע לאתגר בכלל. בכרום הדגל הוא --proxy-server=proxy.example:3128 , עם --proxy-bypass-list להחרגות, וסלניום חושף את אותו הדבר דרך אפשרויות הדפדפן שלו. קובץ PAC הוא מנגנון שונה עם מצבי כשל משלו.

לאחר מכן אשר מתוך הסביבה של הדפדפן הפועל במקום מהמעטפת שלך. בדיקה עצמאית עם אותו פרוקסי הוא curl -x http://proxy.example:3128 -v https://example.com , והפלט המילולי שלו מראה אם ה-CONNECT הצליח, איזה Proxy-Authenticate חזר והאם 407 הוחזר. אם תלתל מקבל 407 והדפדפן נתקע, נתיב האישור הוא הבעיה ולא הרשת. אם התלתל מצליח והדפדפן לא, הדפדפן אינו משתמש בפרוקסי שאתה חושב שהוא.

בדוק את 2: מי עונה ל-407

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

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

בדוק את 3: נתיב האישור

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

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

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

בדוק את 4: הקשר הרשת של תהליך הדפדפן עצמו

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

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

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