Por que um proxy PAC numa VM convidada falha com o URL do anfitrião

«O anfitrião usa este ficheiro PAC, por isso coloquei o mesmo URL na VM» é uma frase razoável e um plano incompleto. Um URL PAC aponta para um script de política, não para um proxy. Até que o convidado consiga obter esse script, avaliá-lo com os endereços do próprio convidado e depois alcançar qualquer proxy que o script nomeie, o URL é apenas uma cadeia num campo de configuração. A maior parte da confusão em torno da política de proxy em máquinas virtuais vem de tratar essa única linha como toda a configuração.

Um URL PAC é um script, não um proxy

O ficheiro contém uma função que recebe um URL e um anfitrião e devolve uma descrição de proxy ou a palavra DIRECT. Nada no URL diz à aplicação para onde enviar o tráfego; essa decisão é tomada em tempo de execução, dentro do script, com dados que o script pede à plataforma. Uma caixa de diálogo de configuração que aceita um URL PAC está a aceitar um ponteiro para um procedimento de decisão.

É essa distinção que explica por que copiar o URL pode parecer que funcionou. O campo fica preenchido, a configuração fica guardada, e a falha só aparece mais tarde, quando o script não pode ser obtido ou quando devolve um proxy que o convidado não alcança.

Os quatro passos falham cada um à sua maneira

Dentro do convidado têm de acontecer quatro coisas por ordem, e cada uma tem a sua própria assinatura de erro. O convidado obtém o ficheiro PAC. A aplicação avalia o script para o URL pedido com informação local. O proxy selecionado é resolvido e alcançado. A autenticação ocorre se o proxy a exigir.

Comece por provar a obtenção, porque tudo o resto é inútil sem ela. Um ficheiro PAC num servidor privado exige um caminho permitido até esse servidor antes de qualquer regra poder ajudar, e uma escolha de proxy dentro de um script inalcançável não pode criar o caminho que o obteria:

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

Se esse pedido falhar a partir do convidado e funcionar a partir do anfitrião, o problema é o caminho do convidado até ao servidor PAC, não o conteúdo do script. Se devolver um ficheiro JavaScript, passe ao segundo passo e descubra o que o script decide para o contexto do convidado.

O mesmo script decide de forma diferente dentro de uma VM

As funções PAC podem inspecionar o anfitrião pedido e informação sobre a máquina que realiza a avaliação. Uma regra construída sobre o endereço do próprio cliente, por exemplo uma que verifica um endereço de interface ou a pertença a uma sub-rede, verá o endereço do convidado e não o do anfitrião físico. Atrás do NAT do lado do anfitrião são endereços diferentes, e por isso o mesmo script pode escolher outro proxy ou voltar ao DIRECT dentro da VM.

Isso não é um defeito do script. É o script a fazer exatamente aquilo para que foi escrito, com uma entrada diferente, e isso explica o relatório confuso em que o anfitrião usa o proxy e o convidado se liga diretamente. Reproduza a decisão em vez de raciocinar sobre ela: um avaliador PAC que recebe um endereço e um URL, se a sua distribuição incluir um, resolve a questão com um único comando. Caso contrário, teste com a aplicação que realmente vai ser usada e leia o respetivo registo de proxy em vez de adivinhar.

Não conclua que o convidado herdou as configurações de proxy do anfitrião porque o seu tráfego passa por uma tradução do lado do anfitrião. A tradução de rede encaminha pacotes; não copia a configuração das aplicações, e o proxy do sistema é configuração de aplicação.

Ferramentas que não leem PAC de todo

As ferramentas de linha de comandos são uma fronteira à parte, e é aqui que se perde muito tempo. curl não executa ficheiros PAC, como a sua documentação de proxy diz claramente. Apontar uma variável de proxy para o URL de descarga do PAC não transforma o script num ponto final de proxy; a ferramenta tentará falar HTTP com um ficheiro JavaScript e falhará de uma forma que parece um problema de rede.

O mesmo se aplica a muitos gestores de pacotes, ambientes de execução de linguagens e ferramentas de compilação, que só respeitam variáveis de proxy explícitas ou a sua própria configuração. Se o teste que lhe importa é uma ferramenta CLI, configure-a com o proxy concreto que o script PAC teria escolhido, e registe como chegou a essa escolha para que a próxima pessoa a possa repetir.

Para aplicações de ambiente de trabalho no Linux, a configuração do sistema tem de ser colocada em modo automático e também receber um URL; um URL guardado enquanto o modo ainda é manual não faz nada. Verifique as duas coisas, e verifique-as dentro do convidado:

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

DIRECT também é uma decisão

Um resultado PAC de DIRECT significa que a aplicação contorna o proxy HTTP, não que escapou da rede. A ligação resultante pode ainda seguir uma rota do sistema operativo através de um túnel, ou falhar por razões que nada têm a ver com o uso de proxy. Inversamente, um resultado de proxy descreve o pedido de uma aplicação, não cada processo no convidado.

Portanto verifique na direção em que o requisito foi escrito. Se o requisito é «esta aplicação alcança o site interno», prove que essa aplicação alcança, e registe qual proxy ou rota o transportou. Se o requisito é «a VM está na rede da empresa», um navegador a funcionar através de um proxy selecionado é evidência para esse navegador e nada mais.

Repare a cadeia dentro do convidado em vez de desligar o túnel do anfitrião ou relaxar a política de encaminhamento para fazer passar um teste. A cadeia tem quatro elos, e uma alteração que salte um deles mantém-se até à próxima vez que o script for atualizado ou o endereço do convidado mudar.