mitmproxy, DevTools, Gradle : trois couches derrière le VPN
Le loopback n’entre jamais dans le tunnel. Classez le symptôme en écouteur, magasin de confiance ou filtre de paquets, et réparez la couche qui a réellement échoué.
Le VPN se connecte, et trois outils sans rapport échouent de trois manières différentes le même après-midi. mitmproxy cesse de voir les requêtes, Chrome refuse le débogueur et Gradle lève BindException pendant la liaison d’une socket locale. Le soupçon partagé est que le tunnel bloque localhost. Il ne peut pas : 127.0.0.1 est traité à l’intérieur du noyau et n’atteint jamais un adaptateur, encore moins une passerelle.
Trois couches, trois pannes différentes
Ce qui a changé avec le client n’est pas la route vers le loopback. C’est un proxy local, un magasin de confiance de la machine et un filtre de paquets, et chacun casse une partie différente du flux de travail d’un développeur. Ranger le symptôme dans la bonne ligne constitue l’essentiel du diagnostic :
| Symptom | Layer | First check |
|---|---|---|
| Proxy sees no traffic | Local proxy or listener | ss -lntp, or netstat -ano on Windows |
| TLS error in one tool only | Trust store | Which CA bundle does that runtime read? |
| Local bind or connect refused | Packet filter or port owner | Who holds the port, and what rule drops it? |
Presque tous les rapports de ce type partent de la dernière ligne et remontent, ce qui est à l’envers. Le tunnel est la seule couche qui, de façon démontrable, ne peut pas voir le trafic loopback, il mérite donc le moins de suspicion. Commencez par ce que le processus a lié, demandez ensuite à quels certificats il fait confiance, et seulement alors regardez la politique de la machine.
Commencez par l’écouteur, pas par le tunnel
Quand un proxy sur 127.0.0.1:8080 cesse de recevoir du trafic, l’une de trois choses s’est produite : il n’a jamais démarré, il a lié un autre port, ou le filtre a supprimé la connexion loopback. Lister les sockets en écoute répond à cela en une seule commande, et montre aussi quel processus possède le port quand deux outils ne sont pas d’accord sur qui était là en premier.
Une adresse locale dans une recherche de route confirme la même chose depuis l’autre direction. ip route get vers une destination loopback rapporte le périphérique loopback, jamais le tunnel, ce qui est une phrase utile à garder prête quand quelqu’un propose un changement de routage comme correctif.
La couche proxy : l’environnement n’est pas la configuration
Beaucoup de clients d’entreprise exécutent un proxy HTTP et attendent des applications qu’elles l’utilisent. Définir HTTPS_PROXY dans un shell corrige les outils en ligne de commande qui le respectent, et ne fait rien pour un outil qui lit son propre fichier de réglages. Gradle, Selenium et gRPC consultent chacun leur propre configuration, et un proxy exporté dans un terminal est invisible pour un démon lancé par l’IDE.
Les outils de conteneurs sont l’endroit habituel où cela devient visible. Le loopback d’un conteneur est le sien, donc 127.0.0.1 à l’intérieur du conteneur ne signifie jamais le proxy de l’hôte ; il faut l’adresse de l’hôte ou un réglage de réseau hôte. Un correctif qui fonctionne dans le shell et échoue à la compilation est généralement cette ligne, pas le tunnel.
La couche de confiance : l’outil lit un autre magasin
L’interception est le deuxième changement, et elle produit les erreurs les plus trompeuses. Le client présente son propre certificat pour les connexions inspectées, si bien qu’un navigateur qui fait confiance à la racine d’entreprise réussit tandis qu’un outil doté d’un magasin de CA embarqué échoue. Les requêtes Python via certifi sont le cas classique : le magasin du système d’exploitation peut être correct et la requête échouer quand même, parce que cet environnement d’exécution ne le lit jamais. Le texte de l’erreur mentionne rarement l’interception, et c’est pourquoi cette ligne est mal diagnostiquée comme un point de terminaison cassé.
Comparez ce que le point de terminaison présente réellement avec ce que l’outil a validé. openssl s_client montre la chaîne envoyée par le serveur ; la sortie de validation propre à l’outil montre ce qu’il a décidé. Quand ils ne concordent pas, REQUESTS_CA_BUNDLE ou SSL_CERT_FILE est le levier pour cet environnement d’exécution, et la racine d’entreprise appartient au magasin que cet environnement lit, plutôt qu’à un emplacement global que seuls certains outils respectent.
Un changement de version qui corrige une erreur SSL est une preuve sur la politique de confiance et de chiffrement, pas sur le VPN. Une rétrogradation de Python qui fait fonctionner un client SOAP a changé le magasin de CA embarqué et les réglages TLS par défaut ; le chemin réseau n’a pas bougé.
La couche de filtre : elle peut aussi supprimer le loopback
Le troisième changement est un filtre de paquets, et certains produits installent des règles qui suppriment le trafic qui n’entre pas dans le tunnel. Les écouteurs locaux peuvent être inclus. Cela transforme une socket qui fonctionnait en connexion refusée ou expirée, et l’erreur qui en résulte ressemble à un bug de l’application plutôt qu’à une politique de la machine.
La propriété du port est l’autre moitié de cette couche. BindException signifie que la socket n’a pas pu être ouverte, ce qui est une défaillance différente d’une connexion refusée. Vérifiez si un autre processus détient déjà le port avant d’accuser le filtre, puis cherchez une règle qui supprime le trafic local et ajoutez l’autorisation la plus étroite que le produit prend en charge. Deux outils qui se disputent le même port de débogage produisent exactement le même message qu’un blocage par politique, et un seul des deux se corrige par un changement de pare-feu.
Le port de débogage de Chrome échoue dans la même famille. Le navigateur démarre, le pilote n’atteint pas le point de terminaison DevTools, et le message nomme DevTools plutôt que le réseau. Des indicateurs de lancement supplémentaires et un gestionnaire de pilotes redondant changent quel processus possède le port, ce qui explique pourquoi les retirer semble parfois réparer le VPN.
Réparez la couche qui a échoué
Réparez la couche qui a échoué, pas le tunnel. Un écouteur loopback injoignable a besoin que son écouteur ou son port soit corrigé. Un certificat non fiable a besoin de la racine d’entreprise installée là où cet environnement d’exécution précis regarde, l’exception restant étroite. Un filtre qui supprime le trafic local a besoin d’une règle d’autorisation précise plutôt que d’un filtre désactivé, car le désactiver rouvre aussi tout le reste qu’il protégeait.
Reconnecter le VPN ne teste aucune de ces couches. Cela ne fait que rejouer le changement qui les a cassées, et c’est pourquoi les trois mêmes pannes reviennent après chaque reconnexion et disparaissent après chaque redémarrage qui laisse le client inactif.