curl לא יכול לקרוא את קובץ ה-PAC שלכם: העבירו את ה-proxy במקום
PAC הוא מדיניות JavaScript; curl רוצה נקודת קצה. שאלו איזה proxy המדיניות בוחרת עבור ה-URL שלכם, העבירו אותו ושימו לב ל-NO_PROXY ול-TLS.
כתובת קובץ ה-PAC ונקודת הקצה של ה-proxy נראות ניתנות להחלפה בקובץ תצורה, והן לא. האחת היא תוכנית מדיניות שצריך להעריך לכל URL; השנייה היא מארח ופורט שמקבלים חיבורים. curl מבין רק את השנייה. העברת כתובת PAC אל --proxy היא שגיאת קטגוריה שנכשלת באופן מבלבל, בדרך כלל אחרי המתנה ארוכה של CONNECT לשרת אינטרנט.
מה כל אחד מהם באמת
| יש לכם | מה זה | מה curl עושה עם זה |
|---|---|---|
http://wpad.corp.example/proxy.pac | JavaScript שמחזיר proxy או חיבור ישיר עבור URL נתון | מוריד אותו כקובץ ועוצר שם |
http://proxy.corp.example:8080 | מאזין שמקבל בקשות דרך proxy | משתמש בו, כולל CONNECT ליעדי HTTPS |
השאלות הנפוצות של curl אומרות זאת בפשטות: curl אינו מספק פרשנות של JavaScript או של PAC. עטיפה סביב curl שמבינה PAC יכולה, אבל curl עצמו לא, ואף דגל לא הופך אותו לדפדפן.
למה הדפדפן עובד ו-curl לא
דפדפן משתלב בתצורת ה-proxy של המערכת, מוריד את קובץ ה-PAC ומריץ את כללי המדיניות שלו מול ה-URL שאתם פותחים. ההערכה הזו היא השירות שקובץ ה-PAC מספק, והיא מתרחשת בתוך הדפדפן, לא בתוך המסוף שלכם.
הורדת קובץ ה-PAC עם curl מביאה רק את הטקסט שלו. היא לא גורמת ל-curl לבצע את המדיניות, וקריאה ידנית שלו כדי למצוא proxy היא גרסה ידנית של אותה הערכה, עם אותה אפשרות לבחור בענף הלא נכון. אם אתם קוראים אותו, קראו את הצהרת ה-return שמתאימה למארח שלכם ולא את שם ה-proxy הראשון בקובץ. רוב קובצי ה-PAC מכילים כמה, ורק ענף אחד חל עליכם.
עבור proxy HTTP מאושר ושירות HTTPS מאושר, בקשה להמחשה היא:
curl --proxy http://proxy.corp.example:8080 https://service.example.net/statusהכתובת הראשונה היא המאזין של ה-proxy, השנייה היא השירות שאתם רוצים. אלו נקודות קצה לדוגמה ולא בדיקה שמישהו ביצע, לכן החליפו אותן בסכמה, בפורט ובתהליך האימות של הארגון שלכם.
בחרו את ה-proxy ליעד הזה
שאלו את המנהל איזה proxy המדיניות בוחרת עבור ה-URL שאתם צריכים, ולא איזה proxy יש לארגון. כללי PAC יכולים להחזיר תוצאות שונות לשירותים פנימיים, לאתרים ציבוריים ולמצבי מעבר עקב תקלה, וכלל שמתאים היום ל-URL שלכם יכול להתאים לאחר אחרי עריכה.
אם תהליך העבודה צריך יותר מבקשה מוכרת אחת, השתמשו בהגדרה סטטית שהמנהל תומך בה או באינטגרציה מאושרת שמבינה PAC. קידוד קשיח של כתובת אחת שהועתקה עובד עד היום שבו המדיניות משתנה ואיש כבר לא זוכר למה נבחרה אותה כתובת.
אחר כך בדקו מה curl יורש. משתני הסביבה של proxy ו-NO_PROXY יכולים לעקוף או להחריג את ה-proxy שהעברתם, והחרגה שמתאימה ליעד שלכם שולחת את הבקשה ישירות בלי לומר דבר. שמרו על המדיניות המיועדת במקום למחוק כל החרגה או לכפות הכול דרך כתובת אחת. הריצו את הבקשה פעם אחת עם -v ובדקו לאיזו כתובת היא באמת התחברה.
הפרידו בין שתי זהויות ה-TLS
עם proxy של HTTPS, שני חיבורי TLS פועלים: שלכם אל ה-proxy ושל ה-proxy אל היעד. לכל אחד זהות משלו לאימות, וכיבוי האימות לאחד מהם אינו תיקון PAC, אלא בעיה שנייה שנוספת לראשונה.
השאירו את האימות פעיל וקראו את הכשל שמתקבל. אתגר אימות של ה-proxy, proxy שאינו נגיש וסירוב של האתר הם שלוש תוצאות שונות, ורק הראשונה עוסקת בהרשאות. ה-VPN עדיין חייב לספק נתיב מורשה ל-proxy פרטי, כולל פתרון שמות עבור מארח ה-proxy עצמו, לפני שמישהו מאלה יצליח.
רשמו את נקודת הקצה, הסכמה, הפורט, שיטת האימות, ההחרגות ונתיב ה-VPN אל ה-proxy. הרשומה הזו היא מה שהופך את הבקשה הבאה לניתנת לשחזור, והיא ההבדל בין להכיר את ה-proxy שלכם לבין לנחש לגביו.