Prečo PAC proxy v hosťujúcom virtuálnom stroji nefunguje s URL hostiteľa

„Hostiteľ používa tento PAC súbor, tak som rovnakú URL vložil do virtuálneho stroja“ je rozumná veta a neúplný plán. URL PAC ukazuje na skript zásad, nie na proxy. Kým hosť nemôže tento skript stiahnuť, vyhodnotiť ho s vlastnými adresami hosťa a potom dosiahnuť akúkoľvek proxy, ktorú skript pomenuje, je URL len reťazec v poli nastavení. Väčšina zmätku okolo proxy zásad vo virtuálnych strojoch pochádza z toho, že sa tento jeden riadok považuje za celú konfiguráciu.

URL PAC je skript, nie proxy

Súbor obsahuje funkciu, ktorá prijíma URL a hostiteľa a vracia popis proxy alebo slovo DIRECT. Nič v URL nehovorí aplikácii, kam má posielať prevádzku; toto rozhodnutie vzniká za behu, vnútri skriptu, s údajmi, ktoré si skript vyžiada od platformy. Dialóg nastavení, ktorý prijíma URL PAC, prijíma ukazovateľ na rozhodovaciu procedúru.

Práve tento rozdiel vysvetľuje, prečo môže kopírovanie URL vyzerať, že fungovalo. Pole je vyplnené, nastavenie uložené a zlyhanie sa prejaví až neskôr, keď sa skript nedá stiahnuť alebo keď vráti proxy, ku ktorej sa hosť nedostane.

Štyri kroky zlyhávajú každý inak

Vnútri hosťa sa musia v poradí stať štyri veci a každá má vlastný podpis chyby. Hosť stiahne PAC súbor. Aplikácia vyhodnotí skript pre požadovanú URL pomocou miestnych informácií. Vybraná proxy sa preloží a dosiahne sa. Overenie identity prebehne, ak ho proxy vyžaduje.

Začnite dôkazom stiahnutia, pretože bez neho je všetko ďalšie bezvýznamné. PAC súbor na súkromnom serveri vyžaduje povolenú cestu k tomuto serveru, skôr než môže pomôcť akékoľvek pravidlo, a voľba proxy v nedostupnom skripte nemôže vytvoriť cestu, ktorá by ho stiahla:

curl -sS -o /dev/null -w '%{http_code}\n' http://pac.corp.example/proxy.pac
getent hosts pac.corp.example

Ak tento dopyt zlyháva z hosťa a funguje z hostiteľa, problém je v ceste hosťa k PAC serveru, nie v obsahu skriptu. Ak vráti súbor JavaScript, prejdite k druhému kroku a zistite, čo skript rozhoduje pre kontext hosťa.

Ten istý skript rozhoduje vnútri virtuálneho stroja inak

Funkcie PAC môžu skúmať požadovaného hostiteľa a informácie o stroji, ktorý vyhodnotenie vykonáva. Pravidlo postavené na vlastnej adrese klienta, napríklad také, ktoré kontroluje adresu rozhrania alebo členstvo v podsieti, uvidí adresu hosťa, nie fyzického hostiteľa. Za NAT na strane hostiteľa sú to rôzne adresy, a preto ten istý skript môže zvoliť inú proxy alebo vnútri virtuálneho stroja prejsť na DIRECT.

To nie je chyba skriptu. Skript robí presne to, na čo bol napísaný, s iným vstupom, a to vysvetľuje mätúcu správu, kde hostiteľ používa proxy a hosť sa pripája priamo. Rozhodnutie reprodukujte, namiesto toho, aby ste o ňom uvažovali: vyhodnocovač PAC, ktorý berie adresu a URL, ak ho vaša distribúcia obsahuje, vyrieši otázku jediným príkazom. Inak testujte s aplikáciou, ktorá sa skutočne použije, a čítajte jej proxy log, namiesto toho, aby ste hádali.

Neuzatvárajte, že hosť zdedil proxy nastavenia hostiteľa pretože jeho prevádzka prechádza prekladom na strane hostiteľa. Sieťový preklad preposiela pakety; nekopíruje konfiguráciu aplikácií a systémová proxy je konfigurácia aplikácie.

Nástroje, ktoré PAC vôbec nečítajú

Nástroje príkazového riadka sú samostatná hranica a práve tam sa stráca veľa času. curl nespúšťa PAC súbory, ako jeho dokumentácia k proxy hovorí priamo. Nasmorovanie proxy premennej na URL na stiahnutie PAC neurobí zo skriptu proxy koncový bod; nástroj sa bude snažiť hovoriť HTTP so súborom JavaScript a zlyhá spôsobom, ktorý vyzerá ako sieťový problém.

To isté platí pre mnohých správcov balíčkov, runtime prostredia jazykov a nástroje na zostavovanie, ktoré rešpektujú len explicitné proxy premenné alebo vlastnú konfiguráciu. Ak je test, na ktorom vám záleží, nástroj CLI, nakonfigurujte ho s konkrétnou proxy, ktorú by zvolil skript PAC, a poznamenajte si, ako ste k tejto voľbe dospeli, aby ju ďalší človek mohol zopakovať.

Pri desktopových aplikáciách na Linuxe treba systémové nastavenie prepnúť do automatického režimu a tiež mu dať URL; URL uložená, kým je režim ešte manuálny, nič nerobí. Skontrolujte oboje a skontrolujte to vnútri hosťa:

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

DIRECT je tiež rozhodnutie

Výsledok PAC DIRECT znamená, že aplikácia obchádza HTTP proxy, nie že unikla zo siete. Výsledné spojenie môže stále sledovať trasu operačného systému tunelom alebo zlyhať z dôvodov, ktoré nemajú nič spoločné s používaním proxy. Naopak, výsledok proxy opisuje požiadavku jednej aplikácie, nie každý proces v hosťovi.

Overujte teda v smere, v ktorom bola požiadavka napísaná. Ak požiadavka znie „táto aplikácia dosiahne na internú lokalitu“, dokážte, že táto aplikácia dosiahne, a poznamenajte, ktorá proxy alebo trasa ju preniesla. Ak požiadavka znie „virtuálny stroj je v podnikovej sieti“, prehliadač fungujúci cez vybranú proxy je dôkaz pre tento prehliadač a nič viac.

Opravte reťaz vnútri hosťa, namiesto toho, aby ste vypínali tunel hostiteľa alebo zmäkčovali politiku preposielania, aby test prešel. Reťaz má štyri články a zmena, ktorá jeden z nich vynechá, vydrží do ďalšej aktualizácie skriptu alebo zmeny adresy hosťa.