Waarom een PAC-proxy in een gast-VM mislukt met de URL van de host

„De host gebruikt dit PAC-bestand, dus ik heb dezelfde URL in de VM gezet“ is een redelijke zin en een onvolledig plan. Een PAC-URL wijst naar een beleidsscript, niet naar een proxy. Totdat de gast dat script kan ophalen, het kan evalueren met de eigen adressen van de gast en vervolgens de proxy kan bereiken die het script noemt, is de URL niet meer dan een tekenreeks in een instellingenveld. Het meeste misverstand over proxybeleid in virtuele machines komt doordat die ene regel als de hele configuratie wordt gezien.

Een PAC-URL is een script, geen proxy

Het bestand bevat een functie die een URL en een host aanneemt en een proxybeschrijving of het woord DIRECT teruggeeft. Niets in de URL vertelt de toepassing waarheen het verkeer moet; die beslissing valt tijdens het draaien, binnen het script, met gegevens die het script bij het platform opvraagt. Een instellingendialoog die een PAC-URL accepteert, accepteert een verwijzing naar een beslissingsprocedure.

Dat onderscheid is de reden waarom het kopiëren van de URL kan lijken te werken. Het veld is gevuld, de instelling is opgeslagen, en de fout verschijnt pas later, wanneer het script niet kan worden opgehaald of wanneer het een proxy teruggeeft die de gast niet kan bereiken.

De vier stappen mislukken elk op hun eigen manier

Binnen de gast moeten vier dingen in volgorde gebeuren, en elk heeft zijn eigen foutsignatuur. De gast haalt het PAC-bestand op. De toepassing evalueert het script voor de gevraagde URL met lokale informatie. De gekozen proxy wordt opgelost en bereikt. Authenticatie gebeurt als de proxy dat vereist.

Begin met het ophalen te bewijzen, want al het volgende is zinloos zonder. Een PAC-bestand op een particuliere server vereist een toegestaan pad naar die server voordat enige regel kan helpen, en een proxykeuze binnen een onbereikbaar script kan het pad dat het zou ophalen niet maken:

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

Als dat verzoek vanuit de gast mislukt en vanuit de host werkt, is het probleem het pad van de gast naar de PAC-server, niet de inhoud van het script. Als het een JavaScript-bestand teruggeeft, ga naar de tweede stap en zoek uit wat het script voor de context van de gast beslist.

Hetzelfde script beslist anders binnen een VM

PAC-functies kunnen de gevraagde host en informatie over de machine die de evaluatie uitvoert inspecteren. Een regel die op het eigen adres van de client is gebouwd, bijvoorbeeld een die een interfaceadres of lidmaatschap van een subnet controleert, ziet het adres van de gast in plaats van dat van de fysieke host. Achter NAT aan de hostkant zijn dat verschillende adressen, en daarom kan hetzelfde script een andere proxy kiezen of binnen de VM terugvallen op DIRECT.

Dat is geen fout in het script. Het script doet precies wat het is geschreven om te doen, met een andere invoer, en dat verklaart het verwarrende rapport waarin de host de proxy gebruikt en de gast rechtstreeks verbindt. Reproduceer de beslissing in plaats van erover te redeneren: een PAC-evaluator die een adres en een URL aanneemt, als je distributie er een heeft, beslist de vraag met één opdracht. Test anders met de toepassing die werkelijk wordt gebruikt, en lees het proxylogboek in plaats van te gokken.

Concludeer niet dat de gast de proxyinstellingen van de host heeft geërfd omdat het verkeer door vertaling aan de hostkant gaat. Netwerkvertaling stuurt pakketten door; het kopieert geen toepassingsconfiguratie, en de systeemproxy is toepassingsconfiguratie.

Hulpmiddelen die PAC helemaal niet lezen

Opdrachtregelprogramma’s zijn een aparte grens, en daar gaat veel tijd verloren. curl voert geen PAC-bestanden uit, zoals de proxydocumentatie duidelijk zegt. Een proxyvariabele naar de PAC-download-URL wijzen maakt van het script geen proxy-eindpunt; het programma zal proberen HTTP te spreken met een JavaScript-bestand en mislukken op een manier die op een netwerkprobleem lijkt.

Hetzelfde geldt voor veel pakketbeheerders, taalruntimes en bouwgereedschap, die alleen expliciete proxyvariabelen of hun eigen configuratie respecteren. Als de test die u belangrijk vindt een CLI-programma is, configureer het dan met de concrete proxy die het PAC-script zou hebben gekozen, en noteer hoe u tot die keuze kwam zodat de volgende persoon die kan herhalen.

Voor desktoptoepassingen op Linux moet de systeeminstelling op automatische modus worden gezet en ook een URL krijgen; een URL die wordt opgeslagen terwijl de modus nog handmatig is, doet niets. Controleer beide, en controleer ze binnen de gast:

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

DIRECT is ook een beslissing

Een PAC-resultaat van DIRECT betekent dat de toepassing de HTTP-proxy omzeilt, niet dat ze aan het netwerk is ontsnapt. De resulterende verbinding kan nog steeds een route van het besturingssysteem door een tunnel volgen, of mislukken om redenen die niets met proxygebruik te maken hebben. Omgekeerd beschrijft een proxyresultaat het verzoek van één toepassing, niet elk proces in de gast.

Controleer dus in de richting waarin de eis is geschreven. Als de eis is „deze toepassing bereikt de interne site“, bewijs dan dat die toepassing dat doet, en noteer welke proxy of route het heeft gedragen. Als de eis is „de VM staat op het bedrijfsnetwerk“, is een werkende browser via een gekozen proxy bewijs voor die browser en niet meer.

Repareer de keten binnen de gast in plaats van de tunnel van de host uit te schakelen of het doorstuurbeleid te versoepelen om een test te laten slagen. De keten heeft vier schakels, en een wijziging die er één overslaat, houdt stand tot de volgende keer dat het script wordt bijgewerkt of het adres van de gast verandert.