Зошто 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 е на корпоративната мрежа“, прелистувач што работи преку избрано прокси е доказ за тој прелистувач и ништо повеќе.

Поправете го синџирот внатре во гостинот наместо да го исклучите тунелот на домаќинот или да ја олабавите политиката за препраќање за тестот да помине. Синџирот има четири алки, а промената што прескокнува една од нив ќе се задржи до следниот пат кога скриптата ќе се ажурира или ќе се смени адресата на гостинот.