Zakaj proxy PAC v gostujočem VM ne deluje z URL gostitelja

„Gostitelj uporablja to datoteko PAC, zato sem v VM vstavil isti URL“ je razumna poved in nepopoln načrt. URL PAC kaže na skript pravil, ne na proxy. Dokler gost ne more pridobiti tega skripta, ga ovrednotiti z lastnimi naslovi gosta in nato doseči katerega koli proxyja, ki ga skript imenuje, je URL le niz v polju nastavitev. Večina zmede okoli pravil proxyja v virtualnih strojih izhaja iz tega, da se ta ena vrstica obravnava kot celotna konfiguracija.

URL PAC je skript, ne proxy

Datoteka vsebuje funkcijo, ki sprejme URL in gostitelja ter vrne opis proxyja ali besedo DIRECT. Nič v URL ne pove aplikaciji, kam naj pošlje promet; ta odločitev se sprejme med izvajanjem, znotraj skripta, s podatki, ki jih skript zahteva od platforme. Pogovorno okno z nastavitvami, ki sprejme URL PAC, sprejme kazalec na postopek odločanja.

Prav ta razlika pojasnjuje, zakaj je lahko kopiranje URL videti uspešno. Polje se izpolni, nastavitev se shrani, napaka pa se pokaže šele pozneje, ko skripta ni mogoče pridobiti ali ko vrne proxy, do katerega gost ne more priti.

Štirje koraki spodletijo vsak na svoj način

Znotraj gosta se morajo po vrsti zgoditi štiri stvari in vsaka ima svoj podpis napake. Gost pridobi datoteko PAC. Aplikacija ovrednoti skript za zahtevani URL z lokalnimi informacijami. Izbrani proxy se razreši in doseže. Preverjanje pristnosti se zgodi, če ga proxy zahteva.

Začnite z dokazom pridobitve, ker je brez tega vse nadaljnje nesmiselno. Datoteka PAC na zasebnem strežniku zahteva dovoljeno pot do tega strežnika, preden lahko pomaga katero koli pravilo, izbira proxyja v nedosegljivem skriptu pa ne more ustvariti poti, ki bi jo pridobila:

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

Če ta zahteva spodleti iz gosta in deluje z gostitelja, je težava pot gosta do strežnika PAC, ne vsebina skripta. Če vrne datoteko JavaScript, pojdite na drugi korak in ugotovite, kaj skript odloči za kontekst gosta.

Isti skript se v VM odloča drugače

Funkcije PAC lahko pregledajo zahtevanega gostitelja in podatke o stroju, ki izvaja vrednotenje. Pravilo, zgrajeno na lastnem naslovu odjemalca, na primer tisto, ki preverja naslov vmesnika ali pripadnost podomrežju, bo videlo naslov gosta in ne fizičnega gostitelja. Za NAT na strani gostitelja so to različni naslovi, zato lahko isti skript izbere drug proxy ali se v VM vrne na DIRECT.

To ni napaka v skriptu. Skript dela natanko to, za kar je bil napisan, z drugačnim vhodom, in to pojasnjuje zmedeno poročilo, v katerem gostitelj uporablja proxy, gost pa se poveže neposredno. Odločitev reproducirajte, namesto da bi o njej razmišljali: ocenjevalnik PAC, ki sprejme naslov in URL, če ga vaša distribucija vsebuje, reši vprašanje z enim ukazom. Sicer testirajte z aplikacijo, ki bo res uporabljena, in berite njeno proxy dnevnik, namesto da bi ugibali.

Ne sklepajte, da je gost podedoval proxy nastavitve gostitelja ker njegov promet poteka skozi prevajanje na strani gostitelja. Omrežno prevajanje posreduje pakete; ne kopira konfiguracije aplikacij, sistemski proxy pa je konfiguracija aplikacije.

Orodja, ki PAC sploh ne berejo

Orodja ukazne vrstice so ločena meja in prav tu se izgubi veliko časa. curl ne izvaja datotek PAC, kot njegova dokumentacija o proxyju pove naravnost. Usmerjanje spremenljivke proxy na URL za prenos PAC ne spremeni skripta v končno točko proxyja; orodje bo poskušalo govoriti HTTP z datoteko JavaScript in spodletelo na način, ki je videti kot omrežna težava.

Enako velja za številne upravitelje paketov, izvajalna okolja jezikov in orodja za gradnjo, ki upoštevajo le izrecne spremenljivke proxy ali lastno konfiguracijo. Če je test, ki vas zanima, orodje CLI, ga konfigurirajte s konkretnim proxyjem, ki bi ga izbral skript PAC, in zapišite, kako ste prišli do te izbire, da jo bo naslednja oseba lahko ponovila.

Za namizne aplikacije v Linuxu je treba sistemsko nastavitev preklopiti v samodejni način in ji dati tudi URL; URL, shranjen, ko je način še ročen, ne naredi ničesar. Preverite oboje in preverite znotraj gosta:

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

DIRECT je tudi odločitev

Rezultat PAC DIRECT pomeni, da aplikacija obide proxy HTTP, ne da je ušla iz omrežja. Nastala povezava lahko še vedno sledi poti operacijskega sistema skozi tunel ali spodleti iz razlogov, ki nimajo nič skupnega z uporabo proxyja. Nasprotno, rezultat proxyja opisuje zahtevo ene aplikacije, ne vsakega procesa v gostu.

Zato preverjajte v smeri, v kateri je zahteva napisana. Če je zahteva „ta aplikacija doseže notranjo stran“, dokažite, da jo ta aplikacija doseže, in zapišite, kateri proxy ali pot jo je prenesla. Če je zahteva „VM je v podjetniškem omrežju“, je brskalnik, ki deluje prek izbranega proxyja, dokaz za ta brskalnik in nič več.

Popravite verigo znotraj gosta, namesto da bi izklopili tunel gostitelja ali omilili politiko posredovanja, da bi test uspel. Veriga ima štiri člene in sprememba, ki enega preskoči, zdrži do naslednje posodobitve skripta ali spremembe naslova gosta.