Почему PAC-прокси в гостевой ВМ не работает с URL хоста

«Хост использует этот файл PAC, поэтому я прописал тот же URL в ВМ» — разумное предложение и неполный план. URL PAC указывает на скрипт политики, а не на прокси. Пока гость не может получить этот скрипт, оценить его со своими собственными адресами и затем достичь любого прокси, который назовёт скрипт, URL остаётся всего лишь строкой в поле настроек. Большая часть путаницы вокруг политики прокси в виртуальных машинах возникает из-за того, что эту одну строку считают всей конфигурацией.

URL PAC — это скрипт, а не прокси

Файл содержит функцию, которая принимает URL и хост и возвращает описание прокси или слово DIRECT. Ничто в URL не говорит приложению, куда отправлять трафик; это решение принимается во время выполнения, внутри скрипта, с данными, которые скрипт запрашивает у платформы. Диалог настроек, который принимает URL PAC, принимает указатель на процедуру принятия решения.

Именно это различие объясняет, почему копирование URL может выглядеть как успех. Поле заполнено, настройка сохранена, а сбой проявляется только позже, когда скрипт не удаётся получить или когда он возвращает прокси, до которого гость не может добраться.

Четыре шага срываются каждый по-своему

Внутри гостя четыре вещи должны произойти по порядку, и у каждой свой признак ошибки. Гость получает файл PAC. Приложение оценивает скрипт для запрошенного URL, используя локальные сведения. Выбранный прокси разрешается, и до него доходят. Аутентификация происходит, если прокси её требует.

Начните с доказательства получения, потому что без него всё дальнейшее бессмысленно. Файл 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, который принимает адрес и URL, если он есть в вашем дистрибутиве, решает вопрос одной командой. Иначе проверяйте тем приложением, которое действительно будет использоваться, и читайте его журнал прокси, а не гадайте.

Не делайте вывод, что гость унаследовал настройки прокси хоста потому что его трафик проходит через трансляцию на стороне хоста. Сетевая трансляция пересылает пакеты; она не копирует конфигурацию приложений, а системный прокси — это конфигурация приложения.

Инструменты, которые вообще не читают PAC

Инструменты командной строки — отдельная граница, и именно здесь теряется много времени. curl не выполняет файлы PAC, как прямо сказано в его документации по прокси . Указание переменной прокси на URL загрузки PAC не превращает скрипт в конечную точку прокси; инструмент попытается говорить по HTTP с файлом JavaScript и сбойнёт так, что это выглядит как сетевая проблема.

То же относится ко многим менеджерам пакетов, средам выполнения языков и инструментам сборки, которые соблюдают только явные переменные прокси или собственную конфигурацию. Если важный для вас тест — это инструмент CLI, настройте его на конкретный прокси, который выбрал бы скрипт PAC, и запишите, как вы пришли к этому выбору, чтобы следующий человек мог его повторить.

Для настольных приложений в Linux системную настройку нужно перевести в автоматический режим и вдобавок дать ей URL; URL, сохранённый пока режим ещё ручной, ничего не делает. Проверьте и то и другое, и проверьте это внутри гостя:

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

DIRECT — тоже решение

Результат PAC DIRECT означает, что приложение обходит HTTP-прокси, а не что оно вырвалось из сети. Полученное соединение всё ещё может идти маршрутом операционной системы через туннель или сбойнуть по причинам, не имеющим отношения к использованию прокси. Наоборот, результат прокси описывает запрос одного приложения, а не каждый процесс в госте.

Поэтому проверяйте в том направлении, в котором написано требование. Если требование — «это приложение достигает внутреннего сайта», докажите, что это приложение достигает, и отметьте, какой прокси или маршрут его пронёс. Если требование — «ВМ находится в корпоративной сети», работающий браузер через выбранный прокси является доказательством для этого браузера и не более.

Чините цепочку внутри гостя, а не выключайте туннель хоста и не ослабляйте политику пересылки, чтобы тест прошёл. В цепочке четыре звена, и изменение, пропускающее одно из них, продержится до следующего обновления скрипта или смены адреса гостя.