ה-VPN פועל, אבל אפליקציה אחת בלי אינטרנט? בדקו את הפרוקסי שלה

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

איזו שכבה מחזיקה בהגדרת הפרוקסי

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

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

קראו את הערך שכל כלי באמת משתמש בו

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

env | grep -i -E 'http_proxy|https_proxy|all_proxy|no_proxy'
scutil --proxy
gsettings get org.gnome.system.proxy mode
netsh winhttp show proxy

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

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

נקו את העקיפה ובדקו שוב את אותה בקשה

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

unset http_proxy https_proxy all_proxy
curl -v --max-time 10 https://example.com 2>&1 | grep -i -E 'uses proxy|connected to|http/'

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

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

ודאו שהתיקון שורד הפעלה מחדש

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

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

env -i /usr/bin/curl -sS -o /dev/null -w '%{http_code} %{remote_ip}
' https://example.com
networksetup -getwebproxy "Wi-Fi"

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