Hvorfor en PAC-proxy i en gæste-VM fejler med værtens URL

»Værten bruger denne PAC-fil, så jeg lagde den samme URL ind i VM’en« er en rimelig sætning og en ufuldstændig plan. En PAC-URL peger på et politikscript, ikke på en proxy. Indtil gæsten kan hente scriptet, evaluere det med gæstens egne adresser og derefter nå den proxy, scriptet navngiver, er URL’en bare en streng i et indstillingsfelt. Det meste af forvirringen omkring proxy-politik i virtuelle maskiner kommer af at behandle den ene linje som hele konfigurationen.

En PAC-URL er et script, ikke en proxy

Filen indeholder en funktion, der tager en URL og en vært og returnerer en proxybeskrivelse eller ordet DIRECT. Intet i URL’en fortæller applikationen, hvor trafikken skal sendes hen; den beslutning sker ved kørsel, inde i scriptet, med data som scriptet beder platformen om. En indstillingsdialog, der accepterer en PAC-URL, accepterer en pegepind til en beslutningsprocedure.

Den forskel er grunden til, at kopiering af URL’en kan se ud som om det virkede. Feltet er udfyldt, indstillingen er gemt, og fejlen viser sig først senere, når scriptet ikke kan hentes, eller når det returnerer en proxy, som gæsten ikke kan nå.

De fire trin fejler hver på sin måde

Inde i gæsten skal fire ting ske i rækkefølge, og hver har sin egen fejlsignatur. Gæsten henter PAC-filen. Applikationen evaluerer scriptet for den ønskede URL med lokale oplysninger. Den valgte proxy slås op, og der nås frem til den. Godkendelse sker, hvis proxyen kræver det.

Begynd med at bevise hentningen, for alt nedstrøms er meningsløst uden den. En PAC-fil på en privat server kræver en tilladt vej til den server, før nogen regel kan hjælpe, og et proxyvalg inde i et utilgængeligt script kan ikke skabe den vej, der 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 anmodning fejler fra gæsten og virker fra værten, er problemet gæstens vej til PAC-serveren, ikke scriptets indhold. Hvis den returnerer en JavaScript-fil, gå videre til andet trin og find ud af, hvad scriptet beslutter for gæstens kontekst.

Det samme script beslutter anderledes inde i en VM

PAC-funktioner kan inspicere den ønskede vært og oplysninger om maskinen, der udfører evalueringen. En regel bygget på klientens egen adresse, for eksempel en der kontrollerer en interfaceadresse eller et subnet-medlemskab, vil se gæstens adresse i stedet for den fysiske værts. Bag NAT på værtsiden er det forskellige adresser, og derfor kan det samme script vælge en anden proxy eller falde tilbage til DIRECT inde i VM’en.

Det er ikke en fejl i scriptet. Det er scriptet, der gør præcis det, det blev skrevet til, med et andet input, og det forklarer den forvirrende rapport, hvor værten bruger proxyen, og gæsten forbinder direkte. Genskab beslutningen i stedet for at ræsonnere om den: en PAC-evaluator, der tager en adresse og en URL, hvis din distribution har en, afgør spørgsmålet med én kommando. Ellers test med den applikation, der faktisk skal bruges, og læs dens proxylog i stedet for at gætte.

Konkluder ikke, at gæsten har arvet værtens proxyindstillinger fordi dens trafik går gennem oversættelse på værtsiden. Netværksoversættelse videresender pakker; den kopierer ikke applikationskonfiguration, og systemproxyen er applikationskonfiguration.

Værktøjer, der slet ikke læser PAC

Kommandolinjeværktøjer er en separat grænse, og det er her, der spildes meget tid. curl udfører ikke PAC-filer, som dets proxydokumentation siger rent ud. At pege en proxyvariabel på PAC-download-URL’en gør ikke scriptet til et proxyendepunkt; værktøjet vil forsøge at tale HTTP med en JavaScript-fil og fejle på en måde, der ligner et netværksproblem.

Det samme gælder mange pakkehåndteringer, sprogkørselsmiljøer og byggeværktøjer, som kun respekterer eksplicitte proxyvariabler eller deres egen konfiguration. Hvis den test, du bekymrer dig om, er et CLI-værktøj, konfigurer det med den konkrete proxy, som PAC-scriptet ville have valgt, og noter, hvordan du kom frem til det valg, så den næste person kan gentage det.

For skrivebordsapplikationer på Linux skal systemindstillingen sættes til automatisk tilstand og også have en URL; en URL, der gemmes, mens tilstanden stadig er manuel, gør ingenting. Kontroller begge, og kontroller dem inde i gæsten:

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 betyder, at applikationen omgår HTTP-proxyen, ikke at den er sluppet ud af netværket. Den resulterende forbindelse kan stadig følge en operativsystemrute gennem en tunnel eller fejle af grunde, der intet har med proxybrug at gøre. Omvendt beskriver et proxyresultat én applikations anmodning, ikke hver proces i gæsten.

Så verificér i den retning, kravet blev skrevet i. Hvis kravet er »denne applikation når det interne websted«, så bevis, at den applikation gør det, og noter, hvilken proxy eller rute der bar den. Hvis kravet er »VM’en er på virksomhedsnetværket«, er en fungerende browser gennem en valgt proxy bevis for den browser og intet mere.

Ret kæden inde i gæsten i stedet for at slukke for værtens tunnel eller lempe videresendelsespolitikken for at få en test til at bestå. Kæden har fire led, og en ændring, der springer et af dem over, holder indtil næste gang, scriptet opdateres, eller gæstens adresse ændres.