Зашто PAC прокси у гостојућој VM не ради са URL-ом хоста

„Хост користи ову PAC датотеку, па сам исти URL ставио у VM“ је разумна реченица и непотпуни план. PAC URL упућује на скрипту политике, а не на прокси. Док гост не може да преузме ту скрипту, да је оцени својим адресама и затим достигне било који прокси који скрипта именује, URL је само низ у пољу подешавања. Већина забуне око политике проксија у виртуелним машинама долази од тога што се тај један ред третира као цела конфигурација.

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

Датотека садржи функцију која прима URL и хоста и враћа опис проксија или реч DIRECT. Ништа у URL-у не каже апликацији куда да пошаље саобраћај; та одлука се доноси у време извршавања, унутар скрипте, са подацима које скрипта тражи од платформе. Дијалог подешавања који прихвата PAC URL прихвата показивач на процедуру одлучивања.

Управо та разлика објашњава зашто копирање 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 датотеку, пређите на други корак и откријте шта скрипта одлучује за контекст госта.

Иста скрипта унутар VM одлучује другачије

PAC функције могу да прегледају тражени хост и податке о машини која обавља оцену. Правило изграђено на сопственој адреси клијента, на пример оно које проверава адресу интерфејса или припадност подмрежи, видеће адресу госта, а не физичког хоста. Иза NAT-а на страни хоста то су различите адресе, па иста скрипта може да изабере други прокси или унутар VM да се врати на 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 прокси, а не да је побегла из мреже. Добијена веза и даље може да прати руту оперативног система кроз тунел, или да не успе из разлога који немају никакве везе са коришћењем проксија. Обрнуто, прокси резултат описује захтев једне апликације, а не сваки процес у госту.

Зато проверавајте у смеру у ком је захтев написан. Ако захтев гласи „ова апликација стиже до интерног сајта“, докажите да та апликација стиже, и запишите који прокси или рута га је пренела. Ако захтев гласи „VM је на корпоративној мрежи“, прегледач који ради кроз изабрани прокси јесте доказ за тај прегледач и ништа више.

Поправите ланац унутар госта, уместо да искључите тунел хоста или ублажите политику прослеђивања да би тест прошао. Ланац има четири карике, а промена која прескочи једну од њих траје до следећег ажурирања скрипте или промене адресе госта.