Kvifor ein PAC-proxy i ein gjeste-VM feilar med vertens URL

«Verten brukar denne PAC-fila, så eg la den same URL-en inn i VM-en» er ei rimeleg setning og ein ufullstendig plan. Ein PAC-URL peikar på eit policy-skript, ikkje på ein proxy. Fram til gjesten kan hente skriptet, evaluere det med gjestens eigne adresser og deretter nå proxyen skriptet namngjev, er URL-en berre ein streng i eit innstillingsfelt. Mesteparten av forvirringa rundt proxy-policy i virtuelle maskinar kjem av å handsame den eine linja som heile konfigurasjonen.

Ein PAC-URL er eit skript, ikkje ein proxy

Fila inneheld ein funksjon som tar ein URL og ein vert og returnerer ei proxybeskriving eller ordet DIRECT. Ingenting i URL-en fortel applikasjonen kvar trafikken skal sendast; den avgjerda blir teken ved køyring, inne i skriptet, med data skriptet ber plattforma om. Ein innstillingsdialog som godtar ein PAC-URL, godtar ein peikar til ein avgjerdsprosedyre.

Den skilnaden er grunnen til at kopiering av URL-en kan sjå ut som det virka. Feltet blir fylt ut, innstillinga blir lagra, og feilen viser seg først seinare, når skriptet ikkje kan hentast, eller når det returnerer ein proxy som gjesten ikkje når.

Dei fire trinna feilar kvar på sin måte

Inne i gjesten må fire ting skje i rekkjefølgje, og kvar har sin eigen feilsignatur. Gjesten hentar PAC-fila. Applikasjonen evaluerer skriptet for den førespurde URL-en med lokal informasjon. Den valde proxyen blir slått opp og nådd. Autentisering skjer om proxyen krev det.

Byrja med å prove hentinga, for alt vidare er meiningslaust utan henne. Ei PAC-fil på ein privat server krev ein tillaten veg til den serveren før noka regel kan hjelpe, og eit proxyval inne i eit utilgjengeleg skript kan ikkje skape vegen som ville hente det:

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

Om den førespurnaden feilar frå gjesten og virkar frå verten, er problemet gjestens veg til PAC-serveren, ikkje innhaldet i skriptet. Om han returnerer ei JavaScript-fil, gå vidare til trinn to og finn ut kva skriptet avgjer for konteksten til gjesten.

Det same skriptet avgjer annleis inne i ein VM

PAC-funksjonar kan inspisere den førespurde verten og informasjon om maskina som utfører evalueringa. Ein regel bygd på klienten si eiga adresse, til dømes ein som kontrollerer ei grensesnittadresse eller medlemskap i eit subnett, vil sjå adressa til gjesten i staden for den fysiske verten si. Bak NAT på vertssida er dette ulike adresser, og difor kan det same skriptet velje ein annan proxy eller falle tilbake til DIRECT inne i VM-en.

Det er ikkje ein feil i skriptet. Det er skriptet som gjer nøyaktig det det vart skrive for, med ein annan inngang, og det forklarer den forvirrande rapporten der verten brukar proxyen og gjesten koplar til direkte. Gjenskap avgjerda i staden for å resonnere om henne: ein PAC-evaluator som tar ei adresse og ein URL, om distribusjonen din har ein, avgjer spørsmålet med éin kommando. Elles test med applikasjonen som faktisk skal brukast, og les proxy-loggen hans i staden for å gjette.

Ikkje konkluder med at gjesten har arva proxyinnstillingane til verten fordi trafikken går gjennom omsetjing på vertssida. Nettverksomsetjing vidaresendar pakkar; ho kopierer ikkje applikasjonskonfigurasjon, og systemproxyen er applikasjonskonfigurasjon.

Verktøy som ikkje les PAC i det heile

Kommandolinjeverktøy er ei eiga grense, og det er her mykje tid går tapt. curl køyrer ikkje PAC-filer, som proxy-dokumentasjonen seier rett ut. Å peike ein proxyvariabel mot PAC-nedlastings-URL-en gjer ikkje skriptet til eit proxy-endepunkt; verktøyet vil prøve å snakke HTTP med ei JavaScript-fil og feile på ein måte som ser ut som eit nettverksproblem.

Det same gjeld mange pakkehandsamarar, språkkøyringsmiljø og byggjeverktøy, som berre respekterer eksplisitte proxyvariablar eller sin eigen konfigurasjon. Om testen du bryr deg om er eit CLI-verktøy, konfigurer det med den konkrete proxyen som PAC-skriptet ville ha valt, og noter korleis du kom fram til det valet, slik at neste person kan gjenta det.

For skrivebordsapplikasjonar på Linux må systeminnstillinga setjast til automatisk modus og også få ein URL; ein URL som blir lagra medan modusen framleis er manuell, gjer ingenting. Kontroller begge, og kontroller dei inne i gjesten:

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

DIRECT er også ei avgjerd

Eit PAC-resultat på DIRECT betyr at applikasjonen omgår HTTP-proxyen, ikkje at han har sleppt ut av nettverket. Den resulterande tilkoplinga kan framleis følgje ein operativsystemrute gjennom ein tunnel, eller feile av grunnar som ikkje har noko med proxybruk å gjere. Omvendt skildrar eit proxyresultat førespurnaden til éin applikasjon, ikkje kvar prosess i gjesten.

Så verifiser i den retninga kravet vart skrive. Om kravet er «denne applikasjonen når det interne nettstaden», prov at den applikasjonen gjer det, og noter kva proxy eller rute som bar han. Om kravet er «VM-en er på bedriftsnettet», er ein fungerande nettlesar via ein vald proxy prov for den nettlesaren og ikkje noko meir.

Reparer kjeda inne i gjesten i staden for å slå av tunnelen til verten eller lempe på vidaresendingspolicyen for å få ein test til å bestå. Kjeda har fire ledd, og ei endring som hoppar over eitt av dei held til neste gong skriptet blir oppdatert eller adressa til gjesten blir endra.