Charles נסגר, אבל ה-Mac שלך עדיין מצביע ל-127.0.0.1

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

הקפיצה הראשונה היא ה-Mac הזה, לא השרת

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

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

שלב 1: קרא את מצב הפרוקסי הנוכחי

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

scutil --proxy

הסתכל על HTTPEnable, HTTPProxy, HTTPPort, המקבילים ל-HTTPS וכל ProxyAutoConfigEnable עם ה-URL שלו. פרוקסי מופעל בפורט ששום דבר לא מאזין בו הוא התקלה שלך. כתובת PAC היא הצורה האחרת: ההגדרה יכולה להיות פעילה בלי כתובת ידנית גלויה, כי הקובץ בוחר את הפרוקסי בזמן הבקשה.

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

שלב 2: מצא מי הבעלים של ההגדרה

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

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

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

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

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

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

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

שלב 4: אם הפרוקסי נעלם וזה עדיין נכשל

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

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

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

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