Une règle PAC pour les noms courts peut contourner votre proxy

Comprenez pourquoi un nom d'hôte sans point et sa forme pleinement qualifiée peuvent choisir des routes différentes dans un même script PAC.

Un script PAC reçoit le nom d'hôte depuis l'URL. dashboard ne devient pas automatiquement dashboard.example.internal avant la comparaison :

function FindProxyForURL(url, host) {
  if (isPlainHostName(host)) {
    return "DIRECT";
  }
  return "PROXY 203.0.113.10:8080";
}

Utilisez un point de terminaison HTTP réel à la place de l'adresse de documentation ; la liste de proxys HTTP fournit des candidats pour les tests vers une destination publique lorsque cette route est autorisée. Dans ce script, le nom court renvoie délibérément DIRECT ; le nom pleinement qualifié atteint la branche proxy. « Plain hostname » désigne une écriture sans point, et non la constatation que l'hôte se trouve sur un réseau local de confiance.

Si la politique voulue est un seul domaine interne, faites correspondre ce domaine plutôt que tous les noms courts. dnsDomainIs et shExpMatch ont des entrées et des sémantiques de motif différentes. Un contrôle de suffixe pour .example.internal n'inclut pas la racine exacte example.internal ; incluez explicitement ce cas lorsque c'est voulu. Un motif de type shell n'est ni un sous-réseau IP ni une expression régulière.

Comparez le résultat du script pour le nom court, le nom pleinement qualifié, un hôte public sans rapport et toute racine de domaine visée. Cela teste la sélection des règles sans se connecter au proxy. Inspectez la première règle qui renvoie lorsqu'une branche DIRECT large empêche d'essayer un point de terminaison autrement joignable.

Utilisez une comparaison de noms lorsqu'elle exprime la politique ; les assistants DNS ajoutent leurs propres résolutions et délais. Gardez aussi le contournement local implicite du navigateur séparé du script. Un contrôle localhost ne peut pas remplacer l'écriture réelle de la destination publique ou interne.

Articles similaires