Proč PAC proxy uvnitř hosta virtuálního stroje nefunguje s URL hostitele

„Hostitel používá tento PAC soubor, tak jsem do virtuálního stroje dal stejnou URL“ je rozumná věta a neúplný plán. URL PAC ukazuje na skript zásad, ne na proxy. Dokud host nemůže tento skript stáhnout, vyhodnotit ho svými vlastními adresami a potom dosáhnout proxy, kterou skript pojmenuje, je URL jen řetězec v poli nastavení. Většina zmatení kolem proxy zásad ve virtuálních strojích pochází z toho, že se tento jeden řádek považuje za celou konfiguraci.

URL PAC je skript, ne proxy

Soubor obsahuje funkci, která bere URL a hostitele a vrací popis proxy nebo slovo DIRECT. Nic v URL neříká aplikaci, kam má provoz posílat; toto rozhodnutí vzniká za běhu, uvnitř skriptu, s daty, která si skript vyžádá od platformy. Dialog nastavení, který přijímá URL PAC, přijímá ukazatel na rozhodovací proceduru.

Právě tento rozdíl vysvětluje, proč může kopírování URL vypadat, že fungovalo. Pole je vyplněné, nastavení je uložené a selhání se objeví až později, když skript nelze stáhnout nebo když vrátí proxy, ke které se host nedostane.

Čtyři kroky selhávají každý jinak

Uvnitř hosta se musí v pořadí stát čtyři věci a každá má svůj vlastní podpis chyby. Host stáhne PAC soubor. Aplikace vyhodnotí skript pro požadovanou URL pomocí místních informací. Vybraná proxy se přeloží a dosáhne se jí. Ověření identity proběhne, pokud ho proxy vyžaduje.

Začněte důkazem stažení, protože bez něj je vše další bezvýznamné. PAC soubor na soukromém serveru vyžaduje povolenou cestu k tomuto serveru, než může jakékoli pravidlo pomoci, a volba proxy uvnitř nedosažitelného skriptu nemůže vytvořit cestu, která by ho stáhla:

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

Pokud tento požadavek z hosta selhává a z hostitele funguje, problém je v cestě hosta k PAC serveru, ne v obsahu skriptu. Pokud vrátí soubor JavaScript, přejděte k druhému kroku a zjistěte, co skript rozhoduje pro kontext hosta.

Stejný skript rozhoduje uvnitř virtuálního stroje jinak

Funkce PAC mohou zkoumat požadovaného hostitele a informace o stroji, který vyhodnocení provádí. Pravidlo postavené na vlastní adrese klienta, například takové, které kontroluje adresu rozhraní nebo členství v podsíti, uvidí adresu hosta, ne fyzického hostitele. Za NAT na straně hostitele jsou to různé adresy, a proto stejný skript může zvolit jinou proxy nebo uvnitř virtuálního stroje přejít na DIRECT.

To není chyba skriptu. Skript dělá přesně to, k čemu byl napsán, s jiným vstupem, a to vysvětluje matoucí zprávu, kde hostitel používá proxy a host se připojuje přímo. Rozhodnutí reprodukujte, místo abyste o něm uvažovali: vyhodnocovač PAC, který bere adresu a URL, pokud ho vaše distribuce obsahuje, vyřeší otázku jedním příkazem. Jinak testujte s aplikací, která se skutečně použije, a čtěte její proxy log, místo abyste hádali.

Neuzavírejte, že host zdědil proxy nastavení hostitele protože jeho provoz prochází překladem na straně hostitele. Síťový překlad přeposílá pakety; nekopíruje konfiguraci aplikací a systémová proxy je konfigurace aplikace.

Nástroje, které PAC vůbec nečtou

Nástroje příkazového řádku jsou samostatná hranice a právě tam se ztrácí hodně času. curl nespouští PAC soubory, jak jeho dokumentace k proxy říká přímo. Nasměrování proxy proměnné na URL pro stažení PAC neudělá ze skriptu proxy koncový bod; nástroj se bude snažit mluvit HTTP se souborem JavaScript a selže způsobem, který vypadá jako síťový problém.

Totéž platí pro mnoho správců balíčků, běhových prostředí jazyků a nástrojů pro sestavování, které respektují jen explicitní proxy proměnné nebo vlastní konfiguraci. Pokud je test, na kterém vám záleží, nástroj CLI, nakonfigurujte ho s konkrétní proxy, kterou by skript PAC zvolil, a poznamenejte si, jak jste k této volbě došli, aby ji příští člověk mohl zopakovat.

U desktopových aplikací na Linuxu je třeba systémové nastavení přepnout do automatického režimu a také mu dát URL; URL uložená, dokud je režim ještě ruční, nic neudělá. Zkontrolujte obojí a zkontrolujte to uvnitř hosta:

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

DIRECT je také rozhodnutí

Výsledek PAC DIRECT znamená, že aplikace obchází HTTP proxy, ne že unikla ze sítě. Výsledné spojení může stále sledovat trasu operačního systému tunelem, nebo selhat z důvodů, které s používáním proxy nemají nic společného. Naopak výsledek proxy popisuje požadavek jedné aplikace, ne každý proces v hostovi.

Ověřujte tedy ve směru, ve kterém byl požadavek napsán. Pokud požadavek zní „tato aplikace dosáhne na interní web“, dokažte, že tato aplikace dosáhne, a poznamenejte, která proxy nebo trasa to přenesla. Pokud požadavek zní „virtuální stroj je v podnikové síti“, prohlížeč fungující přes vybranou proxy je důkaz pro tento prohlížeč a nic víc.

Opravte řetěz uvnitř hosta, místo abyste vypínali tunel hostitele nebo změkčovali politiku předávání, aby test prošel. Řetěz má čtyři články a změna, která jeden z nich vynechá, vydrží do příští aktualizace skriptu nebo změny adresy hosta.