פרוקסי הניפוי מתעוור כשהרשת הפרטית הארגונית מתחברת

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

Windows שומר פרוקסי לכל חיבור

באפשרויות האינטרנט יש שתי שכבות שנראות זהות בתיבה. הגדרות הרשת המקומית חלות על החיבור המקומי הרגיל, ואילו רשומת חיבור חיוג או VPN שומרת עותק משלה תחת HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections, מאוחסן כערך בינארי. כתיבת ערכי הרישום הגלובליים המוכרים אינה מעדכנת את העותק הזה.

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

הדרך הנתמכת לשנות רשומה אחת היא ה-API של אפשרויות חיבור WinINET: מלאו INTERNET_PER_CONN_OPTION_LIST בשם החיבור, בדגלים, בשרת הפרוקסי וברשימת עקיפות, הפעילו ואז רעננו. לבדיקה מהירה, פתחו את תיבת ההגדרות של רשומת המנהרה והשוו את לוח הפרוקסי שלה ללוח הרשת המקומית; ההבדל בדרך כלל ברור ברגע שיודעים לאן להסתכל.

PAC מנוהל יכול להפעיל את עצמו מחדש

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

בדקו ואם יש לכם הרשאה, כבו את שני המתגים האלה עבור השירות שנושא את התעבורה:

networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy

השתמשו בשם השירות האמיתי ולא בניחוש. מחשב נייד עם גם Wi-Fi וגם מתאם Ethernet מסוג USB כולל שניים כאלה, ורק אחד נושא את התעבורה שלכם. scutil --proxy מדפיס את הערכים של השירות הראשי הנוכחי. השוו את הפלט הזה למה שערכתם לפני שתסיקו שהפרופיל ניצח.

כוונו את הכלי לזרם העליון האמיתי

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

זה המהלך שמשאיר אתכם בניפוי ולא בהגדרה מחדש.

דחפו את הפרוקסי לתוך המנהרה

לקוח המבוסס על OpenVPN יכול לקבל אפשרויות פרוקסי שחלות לאחר שהמנהרה עולה, מה שנוח כשהלקוח הוא הבעלים של המסלולים:

dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888

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

חלק מהלקוחות לא קוראים לעולם את פרוקסי המערכת

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

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

קראו את התצורה, לא את המתג

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

כל מקרה כאן הוא בעיית קדימות תצורה. אף אחד מהם אינו המנהרה ששוברת את הכלי שלכם.