Чому 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-проксі, а не що він вирвався з мережі. Отримане з'єднання все ще може йти маршрутом операційної системи через тунель або зазнати невдачі з причин, які не мають жодного стосунку до використання проксі. Навпаки, результат проксі описує запит одного застосунку, а не кожен процес у гостьовій системі.

Тому перевіряйте в тому напрямку, у якому написано вимогу. Якщо вимога — «цей застосунок досягає внутрішнього сайту», доведіть, що цей застосунок досягає, і зазначте, який проксі або маршрут його проніс. Якщо вимога — «ВМ перебуває в корпоративній мережі», робочий браузер через вибраний проксі є доказом для цього браузера і не більше.

Лагодьте ланцюжок усередині гостьової системи, а не вимикайте тунель хоста і не послаблюйте політику пересилання, щоб тест пройшов. У ланцюжку чотири ланки, і зміна, що пропускає одну з них, триватиме до наступного оновлення скрипта або зміни адреси гостьової системи.