curl ne lit pas votre fichier PAC : passez plutôt le proxy
PAC est une politique JavaScript ; curl veut un point de terminaison. Demandez quel proxy la politique choisit pour votre URL, passez-le et surveillez NO_PROXY et TLS.
L’adresse du fichier PAC et le point de terminaison du proxy semblent interchangeables dans un fichier de configuration, et ils ne le sont pas. L’un est un programme de politique qu’il faut évaluer pour chaque URL ; l’autre est un hôte et un port qui acceptent des connexions. curl ne comprend que le second. Passer une adresse PAC à --proxy est une erreur de catégorie qui échoue de façon déroutante, généralement après un long délai CONNECT vers un serveur web.
Ce que chacun est réellement
| Vous avez | Ce que c’est | Ce que curl en fait |
|---|---|---|
http://wpad.corp.example/proxy.pac | JavaScript qui renvoie un proxy ou une connexion directe pour une URL donnée | Le récupère comme un fichier et s’arrête là |
http://proxy.corp.example:8080 | Un écouteur qui accepte les requêtes proxifiées | L’utilise, y compris CONNECT pour les cibles HTTPS |
La FAQ de curl le dit clairement : curl ne fournit aucune interprétation de JavaScript ni de PAC. Un enrobage autour de curl qui comprend PAC peut le faire, mais curl lui-même non, et aucune option n’en fait un navigateur.
Pourquoi le navigateur fonctionne et curl non
Un navigateur s’intègre à la configuration proxy du système, récupère le fichier PAC et exécute ses règles contre l’URL que vous ouvrez. Cette évaluation est le service que fournit le fichier PAC, et elle se produit dans le navigateur, pas dans votre terminal.
Télécharger le fichier PAC avec curl n’en récupère que le texte. Cela ne fait pas exécuter la politique par curl, et le lire à la main pour trouver un proxy est une version manuelle de la même évaluation, avec la même chance de choisir la mauvaise branche. Si vous le lisez, lisez l’instruction return qui correspond à votre hôte plutôt que le premier nom de proxy du fichier. La plupart des fichiers PAC en contiennent plusieurs, et une seule branche vous concerne.
Pour un proxy HTTP approuvé et un service HTTPS approuvé, une requête illustrative est :
curl --proxy http://proxy.corp.example:8080 https://service.example.net/statusLa première adresse est l’écouteur du proxy, la seconde est le service que vous voulez. Ce sont des points de terminaison d’exemple et non un test que quelqu’un aurait effectué, remplacez-les donc par le schéma, le port et le flux d’authentification de votre organisation.
Choisissez le proxy pour cette destination
Demandez à l’administrateur quel proxy la politique sélectionne pour l’URL dont vous avez besoin, et non quel proxy l’organisation possède. Les règles PAC peuvent renvoyer des résultats différents pour les services internes, les sites publics et les conditions de basculement, et une règle qui correspond aujourd’hui à votre URL peut en concerner une autre après une modification.
Si le flux de travail nécessite plus d’une requête connue, utilisez un réglage statique pris en charge par l’administrateur ou une intégration approuvée qui comprend PAC. Coder en dur une seule adresse copiée fonctionne jusqu’au jour où la politique change et où plus personne ne se souvient pourquoi cette adresse avait été choisie.
Regardez ensuite ce que curl hérite. Les variables d’environnement de proxy et NO_PROXY peuvent remplacer ou exclure le proxy que vous avez passé, et une exclusion correspondant à votre cible envoie la requête directement sans le dire. Conservez la politique prévue plutôt que de supprimer toutes les exclusions ou de tout forcer par une seule adresse. Exécutez la requête une fois avec -v et vérifiez à quelle adresse elle s’est réellement connectée.
Gardez les deux identités TLS distinctes
Avec un proxy HTTPS, deux connexions TLS entrent en jeu: la vôtre vers le proxy et celle du proxy vers la destination. Chacune a sa propre identité à vérifier, et désactiver la vérification pour l’une ou l’autre n’est pas un correctif PAC, c’est un second problème ajouté au premier.
Gardez la vérification activée et lisez l’échec que vous obtenez. Un défi d’authentification du proxy, un proxy injoignable et un refus du site web sont trois résultats différents, et seul le premier concerne les identifiants. Le VPN doit encore fournir un chemin autorisé vers un proxy privé, y compris la résolution de noms pour l’hôte du proxy lui-même, avant que tout cela puisse réussir.
Notez le point de terminaison, le schéma, le port, la méthode d’authentification, les exclusions et le chemin VPN vers le proxy. C’est cette note qui rend la prochaine requête reproductible, et c’est la différence entre connaître son proxy et le deviner.