Pourquoi un proxy PAC dans une VM invitée échoue avec l’URL de l’hôte

« L’hôte utilise ce fichier PAC, donc j’ai mis la même URL dans la VM » est une phrase raisonnable et un plan incomplet. Une URL PAC désigne un script de politique, pas un proxy. Tant que l’invité ne peut pas récupérer ce script, l’évaluer avec les propres adresses de l’invité puis joindre le proxy que le script nomme, l’URL n’est qu’une chaîne dans un champ de configuration. L’essentiel de la confusion autour de la politique de proxy dans les machines virtuelles vient du fait que cette unique ligne est traitée comme toute la configuration.

Une URL PAC est un script, pas un proxy

Le fichier contient une fonction qui prend une URL et un hôte et renvoie une description de proxy ou le mot DIRECT. Rien dans l’URL ne dit à l’application où envoyer le trafic ; cette décision est prise à l’exécution, à l’intérieur du script, avec des données que le script demande à la plateforme. Une boîte de dialogue de configuration qui accepte une URL PAC accepte un pointeur vers une procédure de décision.

C’est cette distinction qui explique pourquoi copier l’URL peut sembler avoir fonctionné. Le champ est rempli, le réglage est enregistré, et la panne n’apparaît que plus tard, quand le script ne peut pas être récupéré ou quand il renvoie un proxy que l’invité ne peut pas joindre.

Les quatre étapes échouent chacune à leur manière

À l’intérieur de l’invité, quatre choses doivent se produire dans l’ordre, et chacune a sa propre signature d’erreur. L’invité récupère le fichier PAC. L’application évalue le script pour l’URL demandée à l’aide d’informations locales. Le proxy sélectionné est résolu et joint. L’authentification a lieu si le proxy l’exige.

Commencez par prouver la récupération, car tout ce qui suit est vide de sens sans elle. Un fichier PAC sur un serveur privé exige un chemin autorisé vers ce serveur avant qu’une règle puisse aider, et un choix de proxy à l’intérieur d’un script inaccessible ne peut pas créer le chemin qui le récupérerait :

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

Si cette requête échoue depuis l’invité et fonctionne depuis l’hôte, le problème est le chemin de l’invité vers le serveur PAC, pas le contenu du script. Si elle renvoie un fichier JavaScript, passez à la deuxième étape et découvrez ce que le script décide pour le contexte de l’invité.

Le même script décide différemment à l’intérieur d’une VM

Les fonctions PAC peuvent inspecter l’hôte demandé et des informations sur la machine qui effectue l’évaluation. Une règle construite sur l’adresse propre du client, par exemple celle qui vérifie une adresse d’interface ou une appartenance à un sous-réseau, verra l’adresse de l’invité plutôt que celle de l’hôte physique. Derrière le NAT côté hôte, ce sont des adresses différentes, et le même script peut donc choisir un autre proxy ou revenir à DIRECT à l’intérieur de la VM.

Ce n’est pas un défaut du script. C’est le script qui fait exactement ce pour quoi il a été écrit, avec une entrée différente, et cela explique le rapport déroutant où l’hôte utilise le proxy et l’invité se connecte directement. Reproduisez la décision plutôt que de raisonner dessus : un évaluateur PAC qui prend une adresse et une URL, si votre distribution en fournit un, tranche la question en une seule commande. Sinon, testez avec l’application qui sera réellement utilisée et lisez son journal de proxy au lieu de deviner.

Ne concluez pas que l’invité a hérité des réglages de proxy de l’hôte parce que son trafic passe par une traduction côté hôte. La traduction réseau achemine des paquets ; elle ne copie pas la configuration des applications, et le proxy système est une configuration d’application.

Les outils qui ne lisent jamais PAC

Les outils en ligne de commande sont une frontière à part, et c’est là que beaucoup de temps se perd. curl n’exécute pas les fichiers PAC, comme sa documentation sur le proxy le dit clairement. Pointer une variable de proxy vers l’URL de téléchargement du PAC ne transforme pas le script en point de terminaison proxy ; l’outil essaiera de parler HTTP à un fichier JavaScript et échouera d’une manière qui ressemble à un problème réseau.

La même chose vaut pour de nombreux gestionnaires de paquets, environnements d’exécution de langages et outils de compilation, qui ne respectent que des variables de proxy explicites ou leur propre configuration. Si le test qui vous intéresse est un outil en ligne de commande, configurez-le avec le proxy concret que le script PAC aurait choisi, et notez comment vous avez abouti à ce choix pour que la personne suivante puisse le refaire.

Pour les applications de bureau sous Linux, le réglage système doit être passé en mode automatique et recevoir aussi une URL ; une URL enregistrée alors que le mode est encore manuel ne fait rien. Vérifiez les deux, et vérifiez-les à l’intérieur de l’invité :

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

DIRECT est aussi une décision

Un résultat PAC de DIRECT signifie que l’application contourne le proxy HTTP, non qu’elle a échappé au réseau. La connexion obtenue peut encore suivre une route du système d’exploitation à travers un tunnel, ou échouer pour des raisons qui n’ont rien à voir avec l’usage d’un proxy. À l’inverse, un résultat de proxy décrit la requête d’une application, pas chaque processus de l’invité.

Vérifiez donc dans le sens où l’exigence a été écrite. Si l’exigence est « cette application atteint le site interne », prouvez que cette application l’atteint, et notez quel proxy ou quelle route l’a portée. Si l’exigence est « la VM est sur le réseau de l’entreprise », un navigateur qui fonctionne via un proxy sélectionné est une preuve pour ce navigateur et rien de plus.

Réparez la chaîne à l’intérieur de l’invité au lieu de couper le tunnel de l’hôte ou d’assouplir la politique de transfert pour faire passer un test. La chaîne a quatre maillons, et une modification qui en saute un tiendra jusqu’à la prochaine mise à jour du script ou au prochain changement d’adresse de l’invité.