Защо 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 оценител, който приема адрес и URL, ако дистрибуцията ви има такъв, решава въпроса с една команда. Иначе тествайте с приложението, което наистина ще се използва, и четете прокси лога му, вместо да гадаете.

Не заключавайте, че гостът е наследил прокси настройките на хоста защото трафикът му минава през транслация от страната на хоста. Мрежовата транслация препраща пакети; тя не копира конфигурация на приложения и системното прокси е конфигурация на приложение.

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

Инструментите от командния ред са отделна граница и точно там се губи много време. curl не изпълнява PAC файлове, както неговата документация за прокси казва направо. Насочването на прокси променлива към адреса за изтегляне на PAC не превръща скрипта в крайна точка на прокси; инструментът ще се опита да говори HTTP с JavaScript файл и ще се провали по начин, който изглежда като мрежов проблем.

Същото важи за много мениджъри на пакети, среди за изпълнение на езици и инструменти за изграждане, които спазват само изрични прокси променливи или собствената си конфигурация. Ако тестът, който ви интересува, е CLI инструмент, конфигурирайте го с конкретното прокси, което PAC скриптът би избрал, и запишете как сте извели този избор, за да може следващият човек да го повтори.

За приложения за работен плот на Linux системната настройка трябва да се превключи в автоматичен режим и да получи адрес; адрес, запазен докато режимът е още ръчен, не прави нищо. Проверете и двете, и ги проверете вътре в госта:

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

DIRECT също е решение

PAC резултат DIRECT означава, че приложението заобикаля HTTP проксито, а не че е избягало от мрежата. Получената връзка все още може да следва маршрут на операционната система през тунел или да се провали по причини, които нямат нищо общо с използването на прокси. Обратно, прокси резултатът описва заявката на едно приложение, а не всеки процес в госта.

Затова проверявайте в посоката, в която е написано изискването. Ако изискването е „това приложение стига до вътрешния сайт“, докажете, че това приложение стига, и отбележете кое прокси или маршрут го е пренесъл. Ако изискването е „ВМ е в корпоративната мрежа“, работещ браузър през избрано прокси е доказателство за този браузър и нищо повече.

Поправете веригата вътре в госта, вместо да изключвате тунела на хоста или да разхлабвате политиката за препращане, за да мине тест. Веригата има четири звена и промяна, която пропуска едно от тях, ще се задържи до следващото обновяване на скрипта или промяна на адреса на госта.