Le proxy de débogage devient aveugle quand le VPN d’entreprise se connecte

L’outil de capture fonctionne toute la matinée, le tunnel se connecte, et il se tait. Déconnectez et il repart. Le réflexe est de penser que le VPN a cassé le proxy, mais la configuration du proxy n’a pas changé. Ce qui a changé, c’est la configuration que les applications lisent désormais : une entrée de tunnel peut porter ses propres réglages de proxy, un profil géré peut réactiver la configuration automatique, et certains environnements d’exécution ne lisent qu’une partie de ce que le système propose. Lisez la valeur par connexion avant de toucher à la valeur globale.

Windows garde un proxy par connexion

Dans les options Internet, deux couches se ressemblent dans la boîte de dialogue. Les réglages du réseau local s’appliquent à la connexion locale ordinaire, tandis qu’une entrée d’accès à distance ou de VPN garde sa propre copie sous HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections, stockée en valeur binaire. Écrire les valeurs globales du registre que l’on connaît ne met pas cette copie à jour.

C’est exactement ainsi qu’un outil se comporte correctement avant la connexion et incorrectement après, sans aucun changement visible dans ses réglages. La boîte de dialogue que vous fixiez était le panneau du réseau local. Il était correct, et il était hors sujet. L’entrée que Windows utilisait réellement était celle créée pour le tunnel.

La façon prise en charge de modifier une entrée est l’API d’options de connexion WinINET : remplissez une INTERNET_PER_CONN_OPTION_LIST avec le nom de la connexion, les indicateurs, le serveur proxy et une liste d’exceptions, appliquez-la, puis actualisez. Pour une vérification rapide, ouvrez la boîte de dialogue de l’entrée du tunnel et comparez son panneau proxy à celui du réseau local ; la différence est généralement évidente une fois qu’on sait où regarder.

Un PAC géré peut se réactiver tout seul

Sous macOS, le script de configuration automatique du proxy et la découverte automatique du proxy sont des propriétés d’un service réseau, pas de la machine. Un profil de configuration peut les imposer : ils réapparaissent donc après que vous les avez décochés, et chaque requête part alors vers le proxy choisi par le script.

Inspectez et, si vous y êtes autorisé, désactivez ces deux commutateurs pour le service qui porte le trafic :

networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy

Utilisez le vrai nom du service plutôt qu’une supposition. Un portable doté à la fois du Wi-Fi et d’un adaptateur Ethernet USB en a deux, et un seul porte votre trafic. scutil --proxy affiche les valeurs du service principal actuel. Comparez cette sortie avec ce que vous avez modifié avant de conclure que le profil a gagné.

Pointez l’outil vers le vrai amont

Si le script contient le proxy d’entreprise, lisez-le et saisissez la même adresse comme proxy externe dans l’outil de capture. L’outil transmet alors au vrai amont, ce que le proxy d’entreprise attend, et il reste dans le chemin de la requête au lieu de se battre contre la stratégie.

C’est le geste qui vous garde en train de déboguer plutôt que de reconfigurer.

Poussez le proxy dans le tunnel

Un client basé sur OpenVPN peut accepter des options de proxy qui s’appliquent une fois le tunnel monté, ce qui est pratique quand le client possède les routes :

dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888

Seuls les clients qui respectent l’option l’utiliseront, et celle-ci fixe votre port d’écoute en dur dans un profil. Traitez-la comme une commodité de laboratoire et non comme un standard de déploiement, car la prochaine poussée de profil la supprimera.

Certains clients ne lisent jamais le proxy système

Firefox garde ses propres réglages de proxy, ce qui explique qu’il continue parfois à capturer quand un navigateur utilisant le proxy système ne le fait pas. Un ancien client .NET qui ne comprend pas la configuration automatique se connecte directement où qu’il s’exécute, si bien qu’une page chargée par l’entrée du tunnel peut encore échouer dans l’application.

Les outils réseau ont aussi leurs propres causes. Une session FTP qui se bloque à travers un tunnel ou un partage de connexion téléphonique est souvent un problème de mode actif contre passif négocié par le client, et aucun réglage de proxy n’y changera rien.

Lisez la configuration, pas l’interrupteur

Travaillez dans cet ordre : la valeur de proxy propre à l’entrée du tunnel, l’état PAC et de découverte automatique par service, puis la gestion du proxy par l’application elle-même. Arrêtez-vous au premier qui diffère de ce que vous supposiez.

Chaque cas ici est un problème de priorité de configuration. Aucun n’est le tunnel qui casse votre outil.