Чаму проксі 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 сістэмную наладу трэба перавесці ў аўтаматычны рэжым і даць адрас URL; адрас, захаваны пакуль рэжым яшчэ ручны, нічога не робіць. Праверце абодва і праверце іх унутры госця:

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

DIRECT — гэта таксама рашэнне

Вынік PAC са значэннем DIRECT азначае, што праграма абыходзіць проксі HTTP, а не тое, што яна вырвалася з сеткі. Атрыманае злучэнне ўсё яшчэ можа ісці маршрутам аперацыйнай сістэмы праз тунель або праваліцца з прычын, якія не маюць дачынення да ўжывання проксі. І наадварот, вынік проксі апісвае запыт адной праграмы, а не кожны працэс у госці.

Таму правярайце ў тым кірунку, у якім напісана патрабаванне. Калі патрабаванне — «гэта праграма дасягае ўнутранага сайта», дакажыце, што гэта праграма дасягае, і адзначце, які проксі або маршрут яго перанёс. Калі патрабаванне — «ВМ знаходзіцца ў карпаратыўнай сетцы», працаздольны браўзер праз абраны проксі — доказ для гэтага браўзера і не больш.

Выпраўляйце ланцуг унутры госця, а не выключайце тунель хоста або паслабляйце палітыку перасылкі, каб тэст прайшоў. У ланцугу чатыры звяны, і змена, якая прапускае адно з іх, трымаецца да наступнага абнаўлення скрыпта або змены адраса госця.