VPN در Mac و پروکسی PAC: دو تصمیم، نه یک تنظیم

مک شما یک اسکریپت سیاست دانلود می‌کند و سپس از آن اسکریپت می‌پرسد که یک درخواست باید از کدام واسطه استفاده کند، در حالی که تونل فقط تعیین می‌کند گام انتخاب‌شده چگونه به دست می‌آید. هر دو پاسخ به یک سوکت می‌رسند، پس درخواستی که پس از موفقیت هر دو شکست می‌خورد، در حالی که دو خطاست، مثل یک خطا به نظر می‌رسد. جدا کردن دانلود از انتخاب، و انتخاب از مسیر، بیشتر کار این تیکت‌هاست. ترتیب زیر از آنچه 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، timeout و خطای تجزیه‌کننده قابل تشخیص می‌مانند. اگر آن دستور آخر اسکریپت را برگرداند در حالی که برنامه‌ها همچنان شکست می‌خورند، مشکل از مرحله واکشی گذشته است.

پاسخ DIRECT در واقع چه چیزی را رد می‌کند

مشخصات PAC به کلاینت واژگانی کوچک می‌دهد، و DIRECT یکی از کلمات آن است. این کلمه به کلاینت می‌گوید برای آن درخواست پروکسی را رد کند و چیزی درباره اینکه سوکت پس از آن از کدام رابط استفاده می‌کند نمی‌گوید. سوکت مستقیم روی یک تونل کامل همچنان از VPN خارج می‌شود و همچنان نشانی خروج تونل را به مقصد نشان می‌دهد.

خواندن DIRECT به عنوان چیزی بیرون از VPN همان خطایی است که مردم را به پنل تنظیمات اشتباه می‌فرستد. تصویر آینه‌ای هم به همان اندازه رایج است، چون می‌توان از طریق مسیر تقسیم‌شده به پروکسی خصوصی رسید در حالی که بقیه ماشین بیرون از تونل می‌ماند. آنچه مقصد گزارش می‌کند به خروجی خود پروکسی تعلق دارد، که ممکن است در کشور دیگری باشد. نوشتن انتظار برای یک میزبان داخلی و یک میزبان عمومی این را سریع آشکار می‌کند، چون اسکریپت اغلب به آن دو متفاوت پاسخ می‌دهد. وقتی بدانید کدام گام نشانی را تولید کرده، گزارش دیگر مرموز نیست.

سه شکست که به صورت یک صفحه خطا ظاهر می‌شوند

ممکن است سیاست دانلود نشود، پروکسی انتخاب‌شده در دسترس نباشد، و درخواستی که به سرویس می‌رسد همچنان آنجا رد شود. هر سه به صورت timeout یا صفحه خطای عمومی می‌رسند، و هیچ‌کدام نام مرحله‌ای را که شکسته نمی‌برند. ثبت تصمیم در کنار خطا همان چیزی است که آنها را جدا می‌کند. دو کاوش زیر گامی را آزمایش می‌کنند که اسکریپت انتخاب کرده، یکی برای هر شاخه‌ای که می‌تواند برگرداند.

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

اتصال کامل به پروکسی پرسش را به احراز هویت یا به سیاست خود پروکسی منتقل می‌کند، که صاحب دیگری دارد. اتصال کامل به میزبان داخلی بدون پروکسی در مسیر، مسیر را رد می‌کند و به سیاست اشاره دارد. هر دو دستور دیکشنری پروکسی macOS را نادیده می‌گیرند مگر اینکه پوسته متغیرهای پروکسی را صادر کند، پس ابتدا آنها را پاک کنید. هیچ‌یک از دو کاوش دیگری را اثبات نمی‌کند، و به همین دلیل یک صفحه خطا این‌قدر طولانی گمراه می‌کند.

چه چیزی را همراه تیکت تحویل دهید

سرویس شبکه فعال، URL PAC، نتیجه ارزیابی میزبان ناموفق و مرحله‌ای که خطا در آن ظاهر شد را بفرستید. این چهار مورد به نفر بعدی اجازه می‌دهد تصمیم را بازتولید کند به جای اینکه حدس بزند کدام لایه درگیر بود. وضعیت تونل را در لحظه آزمون اضافه کنید، چون نتیجه‌ای که پیش از اتصال مجدد ثبت شده کهنه است. بازبینی اسکریپت را هم نگه دارید، چون فایل سیاست بدون اطلاع تغییر می‌کند و پاسخ دیروز ممکن است دیگر به‌روز نباشد.

ثبت کنید که کلاینت وقتی اسکریپت واکشی نمی‌شود چگونه رفتار می‌کند، چون پیاده‌سازی‌ها متفاوت‌اند و تصمیم پروکسی یک کلید قطع سراسری دستگاه نیست. برخی به اتصال مستقیم برمی‌گردند و برخی بسته شکست می‌خورند، و این تفاوت تغییر می‌دهد که یک قطعی مثل پروکسی خراب به نظر برسد یا مثل سیاستی که کار می‌کند. رفتار را برای کلاینت و نسخه دقیق تأیید کنید پیش از اینکه در یک رخداد به آن تکیه کنید.