Эмне үчүн конок VM ичиндеги PAC прокси хосттун 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ке кайта алат.

Бул скрипттин бузулушу эмес. Скрипт так өзү жазылган ишти башка кирүү менен аткарып жатат, жана бул хост проксини колдонуп, конок түз туташкан түшүнүксүз отчётту түшүндүрөт. Чечим жөнүндө ойлонуунун ордуна аны кайталаңыз: дарек менен URL кабыл алган PAC баалоочу, эгер дистрибутивиңизде болсо, маселени бир буйрук менен чечет. Болбосо чынында колдонула турган колдонмо менен сынаңыз, жана божомолдоонун ордуна анын прокси журналын окуңуз.

Конок хосттун прокси параметрлерин мураска алды деп жыйынтык чыгарбаңыз, анткени анын трафиги хост тараптагы котормодон өтөт. Тармактык котормо пакеттерди жөнөтөт; ал колдонмолордун конфигурациясын көчүрбөйт, ал эми системалык прокси — колдонмо конфигурациясы.

PACты такыр окубаган куралдар

Буйрук сабынын куралдары өзүнчө чек, жана дал ушул жерде көп убакыт жогоот. curl PAC файлдарын аткарбайт, анын прокси документтештирүүсү анык айткандай. Прокси өзгөрмөсүн PAC жүктөө URLине багыттоо скрипти прокси акыркы чекитине айландырбайт; курал JavaScript файлы менен HTTP тилинде сүйлөшүүгө аракет кылат жана тармактык маселеге окшош түрдө ишке ашпайт.

Ушундай эле нерсе көптөгөн пакет менеджерлерине, тил аткаруу чөйрөлөрүнө жана куруу куралдарына тиешелүү, алар так айтылган прокси өзгөрмөлөрүн же өз конфигурациясын гана сыйлашат. Эгер сизди кызыктырган сынак 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 корпоративдик тармакта» болсо, тандалган прокси аркылуу иштеген браузер ошол браузер үчүн далил, андан ашык эмес.

Сынак өтүшү үчүн хосттун туннелин өчүрүүнүн же багыттоо саясатын алсыратуунун ордуна коноктун ичиндеги чынжырды оңдоңуз. Чынжырда төрт звено бар, алардын бирөөнү өткөрүп жиберген өзгөртүү скрипт кийинки жолу жаңыртылганга чейин же коноктун дареги өзгөргөнгө чейин сакталат.