VPN ב-Mac ופרוקסי PAC: שתי החלטות, לא הגדרה אחת

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

היכן כתובת ה-PAC והפרוקסי נפרדים

כתובת כמו https://config.corp.example/proxy.pac נוקבת במסמך להורדה, והמסמך הזה נוקב בשרת שדרכו ישלח התעבורה. הדבקת ה-URL בשדה מארח של פרוקסי מבקשת מהלקוח לפתוח חיבור פרוקסי לשרת קבצים שלעולם אינו מאזין לחיבור כזה. בתוך הקובץ יש פונקציה שהלקוח קורא לה בכל בקשה, וערך ההחזרה שלה הוא הקפיצה הבאה לאותו יעד בודד. העקיפות הזו מסבירה מדוע שתי מכונות באותה שירות רשת יכולות להתנהג אחרת אף ששתיהן מחזיקות ב-URL הנכון. היא גם מסבירה מדוע שינוי מדיניות נכנס לתוקף בלי שאיש נוגע בפרוקסי עצמו.

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

את הסקריפט חייבים להביא לפני שהוא מחליט משהו

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

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

scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac

הפקודה הראשונה מדפיסה את מילון הפרוקסי של השירות הפעיל, כולל כל כתובת URL של תצורה אוטומטית שהמערכת מחזיקה. השנייה מדווחת על ה-URL שמחובר לשירות בעל שם אחד, וזה חשוב במחשב נייד שעובר בין Wi-Fi ל-Ethernet. השלישית מביאה את הקובץ בלי לעבד אותו, כך ש-404, פסק זמן וכשל פותר נשארים מובחנים. אם הפקודה האחרונה מחזירה את הסקריפט בזמן שאפליקציות עדיין נכשלות, הבעיה כבר עברה את ההורדה.

מה תשובת DIRECT באמת מדלגת עליו

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

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

שלושה כשלים שמופיעים כדף שגיאה אחד

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

curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/

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

מה למסור עם הכרטיס

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

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