Por qué un proxy PAC en una VM invitada falla con la URL del anfitrión

«El anfitrión usa este archivo PAC, así que puse la misma URL en la VM» es una frase razonable y un plan incompleto. Una URL PAC apunta a un script de política, no a un proxy. Hasta que el invitado pueda descargar ese script, evaluarlo con las direcciones propias del invitado y luego alcanzar el proxy que el script nombre, la URL es solo una cadena en un campo de configuración. La mayor parte de la confusión sobre la política de proxy en máquinas virtuales viene de tratar esa única línea como toda la configuración.

Una URL PAC es un script, no un proxy

El archivo contiene una función que recibe una URL y un anfitrión y devuelve una descripción de proxy o la palabra DIRECT. Nada en la URL le dice a la aplicación a dónde enviar el tráfico; esa decisión ocurre en tiempo de ejecución, dentro del script, con datos que el script pide a la plataforma. Un diálogo de configuración que acepta una URL PAC está aceptando un puntero a un procedimiento de decisión.

Esa distinción es la razón por la que copiar la URL puede parecer que funcionó. El campo queda relleno, la configuración se guarda y el fallo solo aparece más tarde, cuando el script no se puede descargar o cuando devuelve un proxy que el invitado no puede alcanzar.

Los cuatro pasos fallan cada uno de una forma

Dentro del invitado tienen que ocurrir cuatro cosas en orden, y cada una tiene su propia firma de error. El invitado descarga el archivo PAC. La aplicación evalúa el script para la URL solicitada con información local. El proxy seleccionado se resuelve y se alcanza. La autenticación ocurre si el proxy la exige.

Empiece por demostrar la descarga, porque todo lo demás carece de sentido sin ella. Un archivo PAC en un servidor privado requiere una ruta permitida hasta ese servidor antes de que ninguna regla pueda ayudar, y una elección de proxy dentro de un script inalcanzable no puede crear la ruta que lo descargaría:

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

Si esa petición falla desde el invitado y funciona desde el anfitrión, el problema es la ruta del invitado hasta el servidor PAC, no el contenido del script. Si devuelve un archivo JavaScript, pase al segundo paso y averigüe qué decide el script para el contexto del invitado.

El mismo script decide distinto dentro de una VM

Las funciones PAC pueden inspeccionar el anfitrión solicitado e información sobre la máquina que realiza la evaluación. Una regla construida sobre la dirección propia del cliente, por ejemplo una que comprueba una dirección de interfaz o una prueba de pertenencia a una subred, verá la dirección del invitado en lugar de la del anfitrión físico. Detrás del NAT del lado del anfitrión son direcciones distintas, y por eso el mismo script puede elegir otro proxy o volver a DIRECT dentro de la VM.

Eso no es un fallo del script. Es el script haciendo exactamente aquello para lo que fue escrito, con una entrada distinta, y eso explica el informe confuso en el que el anfitrión usa el proxy y el invitado se conecta directamente. Reproduzca la decisión en lugar de razonar sobre ella: un evaluador de PAC que reciba una dirección y una URL, si su distribución incluye uno, resuelve la cuestión con un solo comando. De lo contrario, pruebe con la aplicación que realmente se va a usar y lea su registro de proxy en lugar de adivinar.

No concluya que el invitado ha heredado la configuración de proxy del anfitrión porque su tráfico pasa por una traducción del lado del anfitrión. La traducción de red reenvía paquetes; no copia la configuración de las aplicaciones, y el proxy del sistema es configuración de aplicación.

Herramientas que no leen PAC en absoluto

Las herramientas de línea de comandos son una frontera aparte, y es aquí donde se pierde mucho tiempo. curl no ejecuta archivos PAC, como su documentación de proxy dice claramente. Apuntar una variable de proxy a la URL de descarga del PAC no convierte el script en un extremo de proxy; la herramienta intentará hablar HTTP con un archivo JavaScript y fallará de una forma que parece un problema de red.

Lo mismo se aplica a muchos gestores de paquetes, entornos de ejecución de lenguajes y herramientas de compilación, que solo respetan variables de proxy explícitas o su propia configuración. Si la prueba que le importa es una herramienta CLI, configúrela con el proxy concreto que el script PAC habría elegido, y anote cómo derivó esa elección para que la siguiente persona pueda repetirla.

Para las aplicaciones de escritorio en Linux, la configuración del sistema tiene que ponerse en modo automático y además recibir una URL; una URL guardada mientras el modo sigue siendo manual no hace nada. Compruebe ambas cosas, y compruébelas dentro del invitado:

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

DIRECT también es una decisión

Un resultado PAC de DIRECT significa que la aplicación evita el proxy HTTP, no que se haya escapado de la red. La conexión resultante todavía puede seguir una ruta del sistema operativo a través de un túnel, o fallar por motivos que no tienen nada que ver con el uso del proxy. A la inversa, un resultado de proxy describe la petición de una aplicación, no cada proceso del invitado.

Así que verifique en la dirección en la que se escribió el requisito. Si el requisito es «esta aplicación llega al sitio interno», demuestre que esa aplicación llega, y anote qué proxy o ruta lo transportó. Si el requisito es «la VM está en la red corporativa», un navegador que funciona a través de un proxy seleccionado es evidencia para ese navegador y nada más.

Repare la cadena dentro del invitado en lugar de apagar el túnel del anfitrión o relajar la política de reenvío para que pase una prueba. La cadena tiene cuatro eslabones, y un cambio que se salte uno de ellos se mantendrá hasta la próxima vez que se actualice el script o cambie la dirección del invitado.