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

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

כתובת PAC היא סקריפט, לא פרוקסי

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

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

ארבעת השלבים נכשלים כל אחד בדרך אחרת

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

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

curl -sS -o /dev/null -w '%{http_code}\n' http://pac.corp.example/proxy.pac
getent hosts pac.corp.example

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

אותו סקריפט מחליט אחרת בתוך VM

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

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

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

כלים שלא קוראים PAC בכלל

כלי שורת פקודה הם גבול נפרד, וכאן אובד הרבה זמן. curl לא מבצע קבצי PAC, כפי ש תיעוד הפרוקסי שלו אומר בבירור. הצבעת משתנה פרוקסי אל כתובת ההורדה של PAC לא הופכת את הסקריפט לנקודת קצה של פרוקסי; הכלי ינסה לדבר HTTP עם קובץ JavaScript וייכשל באופן שנראה כמו בעיית רשת.

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

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

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy autoconfig-url

גם DIRECT הוא החלטה

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

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

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