چرا پروکسی PAC در ماشین مجازی مهمان با نشانی میزبان کار نمی‌کند

«میزبان از این فایل PAC استفاده می‌کند، پس همان نشانی را در ماشین مجازی گذاشتم» جملهٔ معقولی است و برنامه‌ای ناقص. نشانی 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 برگرداند، به گام دوم بروید و بفهمید اسکریپت برای بافتار مهمان چه تصمیمی می‌گیرد.

همان اسکریپت درون ماشین مجازی متفاوت تصمیم می‌گیرد

توابع PAC می‌توانند میزبان درخواستی و اطلاعاتی دربارهٔ ماشینی که ارزیابی را انجام می‌دهد بررسی کنند. قاعده‌ای که بر نشانی خودِ کارخواه بنا شده باشد، مثلاً قاعده‌ای که نشانی یک واسط یا عضویت در یک زیرشبکه را بررسی می‌کند، نشانی مهمان را می‌بیند نه نشانی میزبان فیزیکی را. پشت NAT در سمت میزبان این‌ها نشانی‌های متفاوتی هستند، و بنابراین همان اسکریپت می‌تواند پروکسی دیگری انتخاب کند یا درون ماشین مجازی به DIRECT بازگردد.

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

نتیجه نگیرید که مهمان تنظیمات پروکسی میزبان را به ارث برده است زیرا ترافیکش از ترجمهٔ سمت میزبان می‌گذرد. ترجمهٔ شبکه بسته‌ها را هدایت می‌کند؛ پیکربندی برنامه‌ها را کپی نمی‌کند و پروکسی سامانه پیکربندی برنامه است.

ابزارهایی که اصلاً PAC نمی‌خوانند

ابزارهای خط فرمان مرزی جداگانه‌اند و همان‌جا زمان زیادی تلف می‌شود. curl فایل‌های PAC را اجرا نمی‌کند، همان‌طور که مستندات پروکسی آن به روشنی می‌گوید. نشانه گرفتن یک متغیر پروکسی به نشانی بارگیری PAC اسکریپت را به نقطهٔ پایانی پروکسی تبدیل نمی‌کند؛ ابزار تلاش می‌کند با یک فایل JavaScript به زبان HTTP حرف بزند و به شکلی شکست می‌خورد که شبیه مشکل شبکه است.

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

برای برنامه‌های رومیزی در Linux، تنظیم سامانه باید هم در حالت خودکار قرار گیرد و هم یک نشانی به آن داده شود؛ نشانی‌ای که در حالی ذخیره شود که حالت هنوز دستی است کاری نمی‌کند. هر دو را بررسی کنید، و آن‌ها را درون مهمان بررسی کنید:

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

DIRECT هم یک تصمیم است

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

پس در همان جهتی که الزام نوشته شده راستی‌آزمایی کنید. اگر الزام این است که «این برنامه به سایت داخلی می‌رسد»، ثابت کنید که آن برنامه می‌رسد و یادداشت کنید کدام پروکسی یا مسیر آن را حمل کرد. اگر الزام این است که «ماشین مجازی در شبکهٔ سازمانی است»، مرورگری که از طریق پروکسی انتخاب‌شده کار می‌کند شاهدی برای همان مرورگر است و نه بیشتر.

زنجیره را درون مهمان درست کنید نه اینکه تونل میزبان را خاموش کنید یا سیاست هدایت را شل کنید تا آزمونی بگذرد. زنجیره چهار حلقه دارد و تغییری که یکی از آن‌ها را جا بیندازد تا دفعهٔ بعد که اسکریپت به‌روزرسانی شود یا نشانی مهمان تغییر کند دوام می‌آورد.