Per què falla el proxy PAC d’una VM convidada amb l’URL de l’amfitrió

«L’amfitrió fa servir aquest fitxer PAC, així que he posat la mateixa URL a la VM» és una frase raonable i un pla incomplet. Una URL PAC apunta a un script de política, no a un proxy. Fins que el convidat no pugui baixar aquest script, avaluar-lo amb les seves pròpies adreces i després arribar al proxy que el script anomeni, la URL és només una cadena dins d’un camp de configuració. La major part de la confusió sobre la política de proxy a les màquines virtuals ve de tractar aquesta única línia com tota la configuració.

Una URL PAC és un script, no un proxy

El fitxer conté una funció que rep una URL i un amfitrió i retorna una descripció de proxy o la paraula DIRECT. Res a la URL no diu a l’aplicació on ha d’enviar el trànsit; aquesta decisió es pren en temps d’execució, dins del script, amb dades que el script demana a la plataforma. Un diàleg de configuració que accepta una URL PAC accepta un punter a un procediment de decisió.

Aquesta distinció és la raó per la qual copiar la URL pot semblar que ha funcionat. El camp queda emplenat, la configuració es desa, i la fallada només apareix més tard, quan el script no es pot baixar o quan retorna un proxy que el convidat no pot assolir.

Els quatre passos fallen cadascun d’una manera

Dins del convidat han de passar quatre coses en ordre, i cadascuna té la seva pròpia empremta d’error. El convidat baixa el fitxer PAC. L’aplicació avalua el script per a la URL sol·licitada amb informació local. El proxy seleccionat es resol i s’assoleix. L’autenticació es produeix si el proxy la requereix.

Comenceu demostrant la baixada, perquè sense això tot el que ve després no té sentit. Un fitxer PAC en un servidor privat requereix un camí permès fins a aquest servidor abans que cap regla pugui ajudar, i una tria de proxy dins d’un script inabastable no pot crear el camí que el baixaria:

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

Si aquesta sol·licitud falla des del convidat i funciona des de l’amfitrió, el problema és el camí del convidat fins al servidor PAC, no el contingut del script. Si retorna un fitxer JavaScript, passeu al segon pas i esbrineu què decideix el script per al context del convidat.

El mateix script decideix diferent dins d’una VM

Les funcions PAC poden inspeccionar l’amfitrió sol·licitat i informació sobre la màquina que fa l’avaluació. Una regla construïda sobre l’adreça pròpia del client, per exemple una que comprova una adreça d’interfície o una prova de pertinença a una subxarxa, veurà l’adreça del convidat i no la de l’amfitrió físic. Darrere del NAT del costat de l’amfitrió aquestes són adreces diferents, i per tant el mateix script pot triar un altre proxy o tornar a DIRECT dins de la VM.

Això no és un error del script. És el script fent exactament allò per a què va ser escrit, amb una entrada diferent, i això explica l’informe confús on l’amfitrió fa servir el proxy i el convidat es connecta directament. Reproduïu la decisió en lloc de raonar-hi: un avaluador PAC que rep una adreça i una URL, si la vostra distribució n’inclou un, resol la qüestió amb una ordre. Si no, proveu-ho amb l’aplicació que realment s’utilitzarà i llegiu el seu registre de proxy en lloc d’endevinar.

No conclogueu que el convidat ha heretat la configuració de proxy de l’amfitrió perquè el seu trànsit passa per una traducció del costat de l’amfitrió. La traducció de xarxa reenvia paquets; no copia la configuració de les aplicacions, i el proxy del sistema és configuració d’aplicació.

Eines que no llegeixen PAC de cap manera

Les eines de línia d’ordres són una frontera a part, i és aquí on es perd molt de temps. curl no executa fitxers PAC, tal com la seva documentació sobre proxy diu obertament. Apuntar una variable de proxy a la URL de baixada del PAC no converteix el script en un punt final de proxy; l’eina intentarà parlar HTTP amb un fitxer JavaScript i fallarà d’una manera que sembla un problema de xarxa.

El mateix s’aplica a molts gestors de paquets, entorns d’execució de llenguatges i eines de compilació, que només respecten variables de proxy explícites o la seva pròpia configuració. Si la prova que us interessa és una eina CLI, configureu-la amb el proxy concret que el script PAC hauria triat, i anoteu com heu derivat aquesta tria perquè la propera persona la pugui repetir.

Per a les aplicacions d’escriptori a Linux, la configuració del sistema s’ha de posar en mode automàtic i també ha de rebre una URL; una URL desada mentre el mode encara és manual no fa res. Comproveu les dues coses, i comproveu-les dins del convidat:

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

DIRECT també és una decisió

Un resultat PAC de DIRECT vol dir que l’aplicació evita el proxy HTTP, no que hagi escapat de la xarxa. La connexió resultant encara pot seguir una ruta del sistema operatiu a través d’un túnel, o fallar per motius que no tenen res a veure amb l’ús del proxy. A la inversa, un resultat de proxy descriu la sol·licitud d’una aplicació, no cada procés del convidat.

Per tant, verifiqueu en la direcció en què es va escriure el requisit. Si el requisit és «aquesta aplicació arriba al lloc intern», demostreu que aquesta aplicació hi arriba, i anoteu quin proxy o ruta l’ha portat. Si el requisit és «la VM és a la xarxa corporativa», un navegador que funciona a través d’un proxy seleccionat és evidència per a aquest navegador i res més.

Repareu la cadena dins del convidat en lloc d’apagar el túnel de l’amfitrió o relaxar la política de reenviament per fer passar una prova. La cadena té quatre baules, i un canvi que en salti una es mantindrà fins al proper moment en què s’actualitzi el script o canviï l’adreça del convidat.