Hvorfor en PAC-proxy i en gjeste-VM feiler med vertens URL

«Verten bruker denne PAC-filen, så jeg la den samme URL-en inn i VM-en» er en rimelig setning og en ufullstendig plan. En PAC-URL peker på et policy-skript, ikke på en proxy. Inntil gjesten kan hente skriptet, evaluere det med gjestens egne adresser og deretter nå proxyen skriptet navngir, er URL-en bare en streng i et innstillingsfelt. Mesteparten av forvirringen rundt proxy-policy i virtuelle maskiner kommer av å behandle den ene linjen som hele konfigurasjonen.

En PAC-URL er et skript, ikke en proxy

Filen inneholder en funksjon som tar en URL og en vert og returnerer en proxybeskrivelse eller ordet DIRECT. Ingenting i URL-en forteller applikasjonen hvor trafikken skal sendes; den beslutningen tas ved kjøring, inne i skriptet, med data skriptet ber plattformen om. En innstillingsdialog som godtar en PAC-URL, godtar en peker til en beslutningsprosedyre.

Den forskjellen er grunnen til at kopiering av URL-en kan se ut som det virket. Feltet fylles ut, innstillingen lagres, og feilen viser seg først senere, når skriptet ikke kan hentes, eller når det returnerer en proxy som gjesten ikke når.

De fire trinnene feiler hver på sin måte

Inne i gjesten må fire ting skje i rekkefølge, og hver har sin egen feilsignatur. Gjesten henter PAC-filen. Applikasjonen evaluerer skriptet for den forespurte URL-en med lokal informasjon. Den valgte proxyen slås opp og nås. Autentisering skjer hvis proxyen krever det.

Begynn med å bevise hentingen, for alt videre er meningsløst uten den. En PAC-fil på en privat server krever en tillatt vei til den serveren før noen regel kan hjelpe, og et proxyvalg inne i et utilgjengelig skript kan ikke skape veien som ville hente det:

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

Hvis den forespørselen feiler fra gjesten og virker fra verten, er problemet gjestens vei til PAC-serveren, ikke innholdet i skriptet. Hvis den returnerer en JavaScript-fil, gå videre til trinn to og finn ut hva skriptet bestemmer for gjestens kontekst.

Det samme skriptet bestemmer annerledes inne i en VM

PAC-funksjoner kan inspisere den forespurte verten og informasjon om maskinen som utfører evalueringen. En regel bygget på klientens egen adresse, for eksempel en som kontrollerer en grensesnittadresse eller medlemskap i et subnett, vil se gjestens adresse i stedet for den fysiske vertens. Bak NAT på vertssiden er dette forskjellige adresser, og derfor kan det samme skriptet velge en annen proxy eller falle tilbake til DIRECT inne i VM-en.

Det er ikke en feil i skriptet. Det er skriptet som gjør nøyaktig det det ble skrevet for, med en annen inngang, og det forklarer den forvirrende rapporten der verten bruker proxyen og gjesten kobler til direkte. Gjenskap beslutningen i stedet for å resonnere om den: en PAC-evaluator som tar en adresse og en URL, hvis distribusjonen din har en, avgjør spørsmålet med én kommando. Ellers test med applikasjonen som faktisk skal brukes, og les proxy-loggen dens i stedet for å gjette.

Ikke konkluder med at gjesten har arvet vertens proxyinnstillinger fordi trafikken går gjennom oversettelse på vertssiden. Nettverksoversettelse videresender pakker; den kopierer ikke applikasjonskonfigurasjon, og systemproxyen er applikasjonskonfigurasjon.

Verktøy som ikke leser PAC i det hele tatt

Kommandolinjeverktøy er en egen grense, og det er her mye tid går tapt. curl kjører ikke PAC-filer, som proxy-dokumentasjonen sier rett ut. Å peke en proxyvariabel mot PAC-nedlastings-URL-en gjør ikke skriptet til et proxy-endepunkt; verktøyet vil prøve å snakke HTTP med en JavaScript-fil og feile på en måte som ser ut som et nettverksproblem.

Det samme gjelder mange pakkebehandlere, språkkjøringsmiljøer og byggeverktøy, som bare respekterer eksplisitte proxyvariabler eller sin egen konfigurasjon. Hvis testen du bryr deg om er et CLI-verktøy, konfigurer det med den konkrete proxyen som PAC-skriptet ville ha valgt, og noter hvordan du kom frem til det valget, slik at neste person kan gjenta det.

For skrivebordsapplikasjoner på Linux må systeminnstillingen settes til automatisk modus og også gis en URL; en URL som lagres mens modusen fortsatt er manuell, gjør ingenting. Kontroller begge, og kontroller dem inne i gjesten:

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

DIRECT er også en beslutning

Et PAC-resultat på DIRECT betyr at applikasjonen omgår HTTP-proxyen, ikke at den har sluppet ut av nettverket. Den resulterende forbindelsen kan fortsatt følge en operativsystemrute gjennom en tunnel, eller feile av grunner som ikke har noe med proxybruk å gjøre. Omvendt beskriver et proxyresultat én applikasjons forespørsel, ikke hver prosess i gjesten.

Så verifiser i den retningen kravet ble skrevet. Hvis kravet er «denne applikasjonen når det interne nettstedet», bevis at den applikasjonen gjør det, og noter hvilken proxy eller rute som bar den. Hvis kravet er «VM-en er på bedriftsnettet», er en fungerende nettleser via en valgt proxy bevis for den nettleseren og ikke noe mer.

Reparer kjeden inne i gjesten i stedet for å slå av vertens tunnel eller lempe på videresendingspolicyen for å få en test til å bestå. Kjeden har fire ledd, og en endring som hopper over ett av dem holder til neste gang skriptet oppdateres eller gjestens adresse endres.