Varför en PAC-proxy i en gäst-VM misslyckas med värdens URL

”Värden använder den här PAC-filen, så jag la in samma URL i VM:en” är en rimlig mening och en ofullständig plan. En PAC-URL pekar på ett policyskript, inte på en proxy. Tills gästen kan hämta skriptet, utvärdera det med gästens egna adresser och sedan nå vilken proxy skriptet än namnger, är URL:en bara en sträng i ett inställningsfält. Det mesta av förvirringen kring proxy-policy i virtuella maskiner kommer av att den enda raden behandlas som hela konfigurationen.

En PAC-URL är ett skript, inte en proxy

Filen innehåller en funktion som tar en URL och en värd och returnerar en proxybeskrivning eller ordet DIRECT. Inget i URL:en säger till applikationen vart trafiken ska skickas; det beslutet fattas vid körning, inne i skriptet, med data som skriptet begär från plattformen. En inställningsdialog som accepterar en PAC-URL accepterar en pekare till en beslutsprocedur.

Den skillnaden är anledningen till att kopiering av URL:en kan verka ha fungerat. Fältet fylls i, inställningen sparas, och felet visar sig först senare, när skriptet inte kan hämtas eller när det returnerar en proxy som gästen inte når.

De fyra stegen misslyckas var och ett på sitt sätt

Inne i gästen måste fyra saker ske i ordning, och var och en har sin egen felsignatur. Gästen hämtar PAC-filen. Applikationen utvärderar skriptet för den begärda URL:en med lokal information. Den valda proxyn slås upp och nås. Autentisering sker om proxyn kräver det.

Börja med att bevisa hämtningen, för allt därefter är meningslöst utan den. En PAC-fil på en privat server kräver en tillåten väg till den servern innan någon regel kan hjälpa, och ett proxyval inne i ett oåtkomligt skript kan inte skapa vägen som skulle hämta det:

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

Om den begäran misslyckas från gästen och fungerar från värden är problemet gästens väg till PAC-servern, inte skriptets innehåll. Om den returnerar en JavaScript-fil, gå vidare till andra steget och ta reda på vad skriptet beslutar för gästens sammanhang.

Samma skript beslutar annorlunda inne i en VM

PAC-funktioner kan inspektera den begärda värden och information om maskinen som utför utvärderingen. En regel byggd på klientens egen adress, till exempel en som kontrollerar en gränssnittsadress eller medlemskap i ett subnät, ser gästens adress i stället för den fysiska värdens. Bakom NAT på värdsidan är det olika adresser, och därför kan samma skript välja en annan proxy eller falla tillbaka på DIRECT inne i VM:en.

Det är inte ett fel i skriptet. Det är skriptet som gör exakt det det skrevs för, med en annan indata, och det förklarar den förvirrande rapporten där värden använder proxyn och gästen ansluter direkt. Reproducera beslutet i stället för att resonera om det: en PAC-utvärderare som tar en adress och en URL, om din distribution har en, avgör frågan med ett enda kommando. Annars testa med applikationen som faktiskt ska användas, och läs dess proxylogg i stället för att gissa.

Dra inte slutsatsen att gästen har ärvt värdens proxyinställningar eftersom dess trafik går genom översättning på värdsidan. Nätverksöversättning vidarebefordrar paket; den kopierar inte applikationskonfiguration, och systemproxyn är applikationskonfiguration.

Verktyg som inte läser PAC alls

Kommandoradsverktyg är en egen gräns, och det är här mycket tid går förlorad. curl kör inte PAC-filer, som dess proxydokumentation säger rakt ut. Att peka en proxyvariabel mot PAC-nedladdningens URL gör inte skriptet till en proxy-slutpunkt; verktyget kommer att försöka tala HTTP med en JavaScript-fil och misslyckas på ett sätt som ser ut som ett nätverksproblem.

Detsamma gäller många pakethanterare, språkliga körmiljöer och byggverktyg, som bara respekterar explicita proxyvariabler eller sin egen konfiguration. Om testet du bryr dig om är ett CLI-verktyg, konfigurera det med den konkreta proxy som PAC-skriptet skulle ha valt, och notera hur du kom fram till det valet så att nästa person kan upprepa det.

För skrivbordsapplikationer på Linux måste systeminställningen sättas i automatiskt läge och också ges en URL; en URL som sparas medan läget fortfarande är manuellt gör ingenting. Kontrollera båda, och kontrollera dem inne i gästen:

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

DIRECT är också ett beslut

Ett PAC-resultat på DIRECT betyder att applikationen kringgår HTTP-proxyn, inte att den har sluppit ut ur nätverket. Den resulterande anslutningen kan fortfarande följa en operativsystemrutt genom en tunnel, eller misslyckas av skäl som inte har något med proxyanvändning att göra. Omvänt beskriver ett proxyresultat en applikations begäran, inte varje process i gästen.

Så verifiera i den riktning kravet skrevs. Om kravet är ”den här applikationen når den interna webbplatsen”, bevisa att den applikationen gör det, och notera vilken proxy eller rutt som bar den. Om kravet är ”VM:en finns på företagsnätet”, är en fungerande webbläsare via en vald proxy bevis för den webbläsaren och inget mer.

Reparera kedjan inne i gästen i stället för att stänga av värdens tunnel eller lätta på vidarebefordringspolicyn för att ett test ska gå igenom. Kedjan har fyra länkar, och en ändring som hoppar över en av dem håller till nästa gång skriptet uppdateras eller gästens adress ändras.