curl نمی‌تواند فایل PAC شما را بخواند: به‌جایش پروکسی را پاس دهید
PAC یک سیاست JavaScript است؛ curl یک نقطه پایانی می‌خواهد. بپرسید سیاست برای URL شما کدام پروکسی را انتخاب می‌کند، همان را پاس دهید و مراقب NO_PROXY و TLS باشید.
نشانی فایل PAC و نقطه پایانی پروکسی در یک فایل پیکربندی قابل‌تبادل به نظر می‌رسند، اما چنین نیستند. یکی برنامه سیاست است که باید برای هر URL ارزیابی شود؛ دیگری میزبان و پورتی است که اتصال می‌پذیرد. curl فقط دومی را می‌فهمد. سپردن یک نشانی PAC به --proxy خطای دسته‌بندی است که به شکلی گیج‌کننده شکست می‌خورد، معمولاً پس از یک مهلت طولانی CONNECT به یک کارساز وب.
هر یک در واقع چیست
| شما دارید | چیست | curl با آن چه می‌کند |
|---|---|---|
http://wpad.corp.example/proxy.pac | JavaScript که برای یک URL مشخص پروکسی یا اتصال مستقیم برمی‌گرداند | آن را به‌صورت فایل دریافت می‌کند و همان‌جا می‌ایستد |
http://proxy.corp.example:8080 | شنونده‌ای که درخواست‌های پروکسی‌شده را می‌پذیرد | از آن استفاده می‌کند، از جمله CONNECT برای مقصدهای HTTPS |
در پرسش‌های متداول curl صریح آمده است: curl هیچ تفسیری از JavaScript یا PAC ارائه نمی‌کند. پوششی پیرامون curl که PAC را بفهمد می‌تواند، اما خود curl نه، و هیچ گزینه‌ای آن را به مرورگر تبدیل نمی‌کند.
چرا مرورگر کار می‌کند و curl نه
مرورگر با پیکربندی پروکسی سیستم یکپارچه می‌شود، فایل PAC را می‌گیرد و قواعدش را روی URLی که باز می‌کنید اجرا می‌کند. این ارزیابی همان خدمتی است که فایل PAC ارائه می‌دهد و درون مرورگر رخ می‌دهد، نه درون پایانه شما.
دریافت فایل PAC با curl فقط متن آن را می‌آورد. این کار curl را وادار به اجرای سیاست نمی‌کند، و خواندن دستی آن برای یافتن پروکسی نسخه دستی همان ارزیابی است، با همان احتمال انتخاب شاخه نادرست. اگر آن را می‌خوانید، دستور return را بخوانید که با میزبان شما می‌خواند، نه نخستین نام پروکسی در فایل را. بیشتر فایل‌های PAC چند پروکسی دارند و فقط یک شاخه به شما مربوط است.
برای یک پروکسی HTTP تأییدشده و یک سرویس HTTPS تأییدشده، یک درخواست نمونه چنین است:
curl --proxy http://proxy.corp.example:8080 https://service.example.net/statusنشانی نخست شنونده پروکسی است و دومی سرویسی که می‌خواهید. این‌ها نقاط پایانی نمونه‌اند نه آزمونی که کسی انجام داده باشد، پس آن‌ها را با طرح، پورت و جریان احراز هویت سازمان خود جایگزین کنید.
پروکسی این مقصد را انتخاب کنید
از مدیر بپرسید سیاست برای URLی که لازم دارید کدام پروکسی را انتخاب می‌کند، نه اینکه سازمان کدام پروکسی را دارد. قواعد PAC می‌توانند برای سرویس‌های داخلی، سایت‌های عمومی و شرایط جایگزینی هنگام خرابی نتایج متفاوتی بدهند، و قاعده‌ای که امروز با URL شما می‌خواند پس از یک ویرایش ممکن است با دیگری بخواند.
اگر جریان کار بیش از یک درخواست شناخته‌شده لازم دارد، از تنظیم ایستای پشتیبانی‌شده توسط مدیر یا یک یکپارچه‌سازی تأییدشده که PAC را می‌فهمد استفاده کنید. سخت‌کدکردن یک نشانی کپی‌شده تا روزی کار می‌کند که سیاست تغییر کند و هیچ‌کس دیگر یادش نباشد چرا آن نشانی انتخاب شد.
سپس ببینید curl چه چیزی را به ارث می‌برد. متغیرهای محیطی پروکسی و NO_PROXY می‌توانند پروکسی‌ای را که پاس داده‌اید بازنویسی یا حذف کنند، و استثنایی که با مقصد شما بخواند درخواست را بی‌صدا مستقیم می‌فرستد. سیاست موردنظر را حفظ کنید، نه اینکه هر استثنایی را پاک کنید یا همه چیز را از یک نشانی رد کنید. درخواست را یک بار با -v اجرا کنید و بررسی کنید واقعاً به کدام نشانی متصل شده است.
دو هویت TLS را جدا نگه دارید
با پروکسی HTTPS، دو اتصال TLS در جریان است: اتصال شما به پروکسی و اتصال پروکسی به مقصد. هر کدام هویت خودش را برای بررسی دارد، و خاموش‌کردن بررسی برای هر یک از آن‌ها رفع PAC نیست، مشکلی دوم است که به اولی افزوده می‌شود.
بررسی را روشن نگه دارید و خطایی را که می‌گیرید بخوانید. چالش احراز هویت پروکسی، پروکسی غیرقابل‌دسترس و رد شدن از سوی وبگاه سه نتیجه متفاوت‌اند و فقط اولی درباره اعتبارنامه‌هاست. VPN هنوز باید مسیری مجاز به یک پروکسی خصوصی فراهم کند، از جمله تحلیل نام برای خود میزبان پروکسی، پیش از آنکه هیچ‌یک از این‌ها موفق شود.
نقطه پایانی، طرح، پورت، روش احراز هویت، استثناها و مسیر VPN تا پروکسی را بنویسید. همان سابقه است که درخواست بعدی را بازتولیدپذیر می‌کند و تفاوت میان شناختن پروکسی و حدس زدن درباره آن است.