VPN sur Mac et proxy PAC : deux décisions, pas un seul réglage

Votre Mac télécharge un script de politique, puis demande à ce script quel intermédiaire une requête doit utiliser, tandis que le tunnel décide seulement comment le saut choisi est atteint. Les deux réponses aboutissent sur la même socket, si bien qu'une requête qui échoue après que les deux ont réussi ressemble à une seule panne alors qu'il y en a deux. Séparer le téléchargement de la sélection, et la sélection de la route, représente l'essentiel du travail dans ces tickets. L'ordre ci-dessous suit ce que macOS fait réellement, avec les vérifications qui rendent chaque étape visible.

Où l'adresse PAC et le proxy divergent

Une adresse comme https://config.corp.example/proxy.pac nomme un document à télécharger, et ce document nomme un serveur par lequel envoyer le trafic. Coller l'URL dans un champ d'hôte de proxy demande au client d'ouvrir une connexion proxy vers un serveur de fichiers qui n'écoute jamais une telle connexion. Dans le fichier se trouve une fonction que le client appelle à chaque requête, et sa valeur de retour est le prochain saut pour cette destination unique. Cette indirection explique pourquoi deux machines sur le même service réseau peuvent se comporter différemment alors que toutes deux détiennent l'URL correcte. Elle explique aussi pourquoi un changement de politique prend effet sans que personne ne touche au proxy lui-même.

Lisez le script avant d'interpréter quoi que ce soit en aval, car les règles qu'il contient portent les exceptions de l'organisation et l'ordre dans lequel elles s'appliquent. Une plage large précoce peut masquer un suffixe interne ultérieur, et un hôte qui devrait manifestement contourner le proxy continue de l'utiliser. Quand quelqu'un affirme que la politique est fausse, le script est le seul endroit où cette affirmation se règle.

Le script doit être récupéré avant de décider quoi que ce soit

Télécharger la politique exige un nom résolu et une route vers ce qui sert le fichier, et un tunnel connecté n'implique ni l'un ni l'autre. Si l'hôte n'est résolu que par un DNS privé, le résolveur utilisé à ce moment décide si le téléchargement peut commencer. Si l'hôte se trouve sur une plage privée, la route doit exister depuis cette machine et non depuis l'ordinateur portable d'un collègue. Une copie mise en cache lors d'une session antérieure cache tout cela jusqu'à l'expiration du cache ou au redémarrage de la machine.

Exécutez les trois vérifications ci-dessous dans l'ordre et arrêtez-vous au premier échec, car les étapes ne partagent pas de cause. Ensemble, elles montrent si la politique est configurée, si elle est joignable et ce qu'elle renvoie.

scutil --proxy
networksetup -getautoproxyurl "Wi-Fi"
curl -sS -o /dev/null -w "%{http_code}\n" https://config.corp.example/proxy.pac

La première commande affiche le dictionnaire de proxy du service actif, y compris toute URL de configuration automatique que le système détient. La deuxième signale l'URL associée à un service nommé, ce qui compte sur un portable qui passe du Wi-Fi à l'Ethernet. La troisième récupère le fichier sans le rendre, de sorte qu'un 404, un délai d'attente et un échec de résolveur restent distinguables. Si cette dernière commande renvoie le script alors que les applications échouent encore, le problème a déjà dépassé la récupération.

Ce qu'une réponse DIRECT saute réellement

La spécification PAC donne au client un petit vocabulaire, et DIRECT en est un mot. Le mot dit au client de sauter le proxy pour cette requête et ne dit rien sur l'interface que la socket utilisera ensuite. Une socket directe sur un tunnel complet sort tout de même par le VPN et montre tout de même l'adresse de sortie du tunnel à la destination.

Lire DIRECT comme extérieur au VPN est l'erreur qui envoie les gens vers le mauvais panneau de réglages. L'image miroir est tout aussi fréquente, car on peut atteindre un proxy privé par une route divisée tandis que le reste de la machine reste hors du tunnel. Ce que la destination signale alors appartient à la sortie propre du proxy, qui peut se trouver dans un autre pays. Écrire l'attente pour un hôte interne et un hôte public l'expose rapidement, car le script répond souvent différemment aux deux. Une fois que vous savez quel saut a produit l'adresse, le rapport cesse d'être mystérieux.

Trois pannes qui apparaissent comme une seule page d'erreur

La politique peut échouer à se télécharger, le proxy choisi peut être injoignable, et une requête qui arrive au service peut encore y être refusée. Les trois arrivent comme un délai d'attente ou une page d'erreur générique, et aucune ne nomme l'étape qui a cassé. Capturer la décision à côté de l'erreur est ce qui les sépare. Les deux sondes ci-dessous testent le saut que le script a choisi, une pour chaque branche qu'il peut renvoyer.

curl -v --max-time 8 http://proxy.corp.example:8080/
curl -v --max-time 8 https://intranet.corp.example/

Une connexion établie vers le proxy déplace la question vers l'authentification ou vers la politique propre au proxy, qui a un autre responsable. Une connexion établie vers l'hôte interne sans proxy sur le chemin écarte la route et pointe vers la politique. Les deux commandes ignorent le dictionnaire de proxy de macOS sauf si le shell exporte des variables de proxy, alors effacez-les d'abord. Aucune des deux sondes ne prouve l'autre, et c'est pourquoi une page d'erreur induit en erreur si longtemps.

Ce qu'il faut transmettre avec le ticket

Envoyez le service réseau actif, l'URL du PAC, le résultat d'évaluation pour l'hôte en échec et l'étape où l'erreur est apparue. Ces quatre éléments permettent à la personne suivante de reproduire la décision au lieu de deviner quelle couche était impliquée. Ajoutez l'état du tunnel au moment du test, car un résultat capturé avant une reconnexion est périmé. Conservez aussi la révision du script, car le fichier de politique change sans préavis et la réponse d'hier n'est peut-être plus d'actualité.

Notez comment le client se comporte quand le script ne peut pas être récupéré, car les implémentations diffèrent et la décision de proxy n'est pas un interrupteur général de l'appareil. Certaines reviennent à une connexion directe et d'autres échouent en mode fermé, et cette différence change qu'une panne ressemble à un proxy cassé ou à une politique qui fonctionne. Confirmez le comportement pour le client et la version exacts avant de vous y fier pendant un incident.