Por que un proxy PAC nunha VM convidada falla coa URL do anfitrión

«O anfitrión usa este ficheiro PAC, así que puxen a mesma URL na VM» é unha frase razoable e un plan incompleto. Unha URL PAC apunta a un script de política, non a un proxy. Ata que o convidado poida descargar ese script, avalialo coas propias direccións do convidado e despois acadar o proxy que o script nomee, a URL é só unha cadea nun campo de configuración. A maior parte da confusión sobre a política de proxy nas máquinas virtuais vén de tratar esa única liña como toda a configuración.

Unha URL PAC é un script, non un proxy

O ficheiro contén unha función que recibe unha URL e un anfitrión e devolve unha descrición de proxy ou a palabra DIRECT. Nada na URL lle di á aplicación a onde enviar o tráfico; esa decisión ocorre en tempo de execución, dentro do script, con datos que o script lle pide á plataforma. Un diálogo de configuración que acepta unha URL PAC está aceptando un punteiro a un procedemento de decisión.

Esa distinción é a razón pola que copiar a URL pode parecer que funcionou. O campo queda cheo, a configuración gárdase, e o fallo só aparece máis tarde, cando o script non se pode descargar ou cando devolve un proxy que o convidado non pode acadar.

Os catro pasos fallan cada un dunha forma

Dentro do convidado teñen que ocorrer catro cousas en orde, e cada unha ten a súa propia sinatura de erro. O convidado descarga o ficheiro PAC. A aplicación avalía o script para a URL solicitada con información local. O proxy seleccionado resólvese e acádase. A autenticación ocorre se o proxy a esixe.

Comece por demostrar a descarga, porque todo o demais carece de sentido sen ela. Un ficheiro PAC nun servidor privado require un camiño permitido ata ese servidor antes de que ningunha regra poida axudar, e unha elección de proxy dentro dun script inalcanzable non pode crear o camiño que o descargaría:

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

Se esa petición falla desde o convidado e funciona desde o anfitrión, o problema é o camiño do convidado ata o servidor PAC, non o contido do script. Se devolve un ficheiro JavaScript, pase ao segundo paso e averigüe que decide o script para o contexto do convidado.

O mesmo script decide distinto dentro dunha VM

As funcións PAC poden inspeccionar o anfitrión solicitado e información sobre a máquina que realiza a avaliación. Unha regra construída sobre a dirección propia do cliente, por exemplo unha que comproba unha dirección de interface ou unha proba de pertenza a unha subrede, verá a dirección do convidado en lugar da do anfitrión físico. Detrás do NAT do lado do anfitrión son direccións distintas, e por iso o mesmo script pode escoller outro proxy ou volver a DIRECT dentro da VM.

Iso non é un fallo do script. É o script facendo exactamente aquilo para o que foi escrito, cunha entrada distinta, e iso explica o informe confuso no que o anfitrión usa o proxy e o convidado se conecta directamente. Reproduza a decisión en lugar de razoar sobre ela: un avaliador de PAC que reciba unha dirección e unha URL, se a súa distribución inclúe un, resolve a cuestión cun só comando. Se non, probe coa aplicación que realmente se vai usar e lea o seu rexistro de proxy en lugar de adiviñar.

Non conclúa que o convidado herdou a configuración de proxy do anfitrión porque o seu tráfico pasa por unha tradución do lado do anfitrión. A tradución de rede reenvía paquetes; non copia a configuración das aplicacións, e o proxy do sistema é configuración de aplicación.

Ferramentas que non len PAC en absoluto

As ferramentas de liña de ordes son unha fronteira aparte, e é aquí onde se perde moito tempo. curl non executa ficheiros PAC, como a súa documentación de proxy di claramente. Apuntar unha variable de proxy á URL de descarga do PAC non converte o script nun extremo de proxy; a ferramenta tentará falar HTTP cun ficheiro JavaScript e fallará dun xeito que parece un problema de rede.

O mesmo se aplica a moitos xestores de paquetes, contornos de execución de linguaxes e ferramentas de compilación, que só respectan variables de proxy explícitas ou a súa propia configuración. Se a proba que lle importa é unha ferramenta CLI, configúrea co proxy concreto que o script PAC tería escollido, e anote como derivou esa elección para que a seguinte persoa poida repetila.

Para as aplicacións de escritorio en Linux, a configuración do sistema ten que poñerse en modo automático e ademais recibir unha URL; unha URL gardada mentres o modo aínda é manual non fai nada. Comprobe ambas as cousas, e compróbeas dentro do convidado:

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

DIRECT tamén é unha decisión

Un resultado PAC de DIRECT significa que a aplicación evita o proxy HTTP, non que escapase da rede. A conexión resultante aínda pode seguir unha ruta do sistema operativo a través dun túnel, ou fallar por motivos que non teñen nada que ver co uso do proxy. Pola contra, un resultado de proxy describe a petición dunha aplicación, non cada proceso do convidado.

Así que verifique na dirección na que se escribiu o requisito. Se o requisito é «esta aplicación chega ao sitio interno», demostre que esa aplicación chega, e anote que proxy ou ruta o levou. Se o requisito é «a VM está na rede corporativa», un navegador que funciona a través dun proxy seleccionado é evidencia para ese navegador e nada máis.

Repare a cadea dentro do convidado en lugar de apagar o túnel do anfitrión ou relaxar a política de reenvío para que pase unha proba. A cadea ten catro elos, e un cambio que salte un deles manterase ata a próxima vez que se actualice o script ou cambie a dirección do convidado.