Un proxy local compatible PAC donne aux outils en ligne de commande un point de terminaison fixe tout en évaluant la politique de routage du réseau pour chaque destination. Alpaca joue ce rôle d'adaptateur : l'outil parle HTTP proxy en local et Alpaca choisit un proxy amont ou une connexion directe.

Avec une installation existante, démarrez son écouteur de bouclage à l'aide des options documentées :

ALPACA_PROXY_AUTH_ALLOWLIST=.corp.example.net \
alpaca -l 127.0.0.1 -p 3128 \
  -C https://config.corp.example.net/proxy.pac

L'URL du PAC, la liste d'autorisation pour l'authentification proxy et le port sont des exemples de déploiement. Fournissez les paramètres d'authentification amont pris en charge par la version et la plateforme installées lorsque les proxys choisis les exigent. La liste d'autorisation identifie les hôtes proxy habilités à recevoir ces identifiants.

Configurez l'outil en ligne de commande pour utiliser le point de terminaison local :

export http_proxy=http://127.0.0.1:3128
export https_proxy=http://127.0.0.1:3128

L'outil peut conserver ces valeurs tandis que le PAC envoie une destination intranet en direct et une destination publique via le proxy d'entreprise. Il n'a pas besoin d'évaluer lui-même le JavaScript du PAC.

Le projet documente aussi un contournement direct temporaire lorsque certains parents choisis deviennent inaccessibles. Intégrez cette solution de repli à la politique de déploiement pour décider si l'adaptateur fournit la route requise.

Vérifiez les types de résultat PAC pris en charge par l'adaptateur. La CLI Alpaca documentée fait des routes PAC SOCKS5 une option explicite via -enable-socks ; l'interface HTTP locale et le protocole amont choisi sont des parties distinctes de la route.

Articles similaires