Неліктен қонақ VM ішіндегі PAC проксиі хосттың URL-імен жұмыс істемейді
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 корпоративтік желіде» болса, таңдалған прокси арқылы жұмыс істейтін браузер сол браузер үшін дәлел, одан артық емес.
Тест өтуі үшін хосттың туннелін өшірудің немесе бағыттау саясатын әлсіретудің орнына қонақтың ішіндегі тізбекті түзетіңіз. Тізбекте төрт буын бар, ал олардың біреуін өткізіп жіберетін өзгеріс скрипт келесі рет жаңартылғанша немесе қонақтың мекенжайы өзгергенше сақталады.