Internet ne marche qu’avec l’application VPN ? Vérifiez quatre couches

Vous essayez un client VPN gratuit ou une extension de navigateur pendant une semaine, vous le désactivez, et Internet s’arrête. L’icône Wi-Fi montre toujours une connexion, les autres appareils du même routeur fonctionnent, et les seules choses qui ramènent la navigation sont la réactivation de l’application ou sa désinstallation. Ce schéma n’est pas une dépendance créée par le chiffrement. Ce sont des réglages que l’application a écrits quelque part que le tunnel ne possède pas.

Le client modifie des réglages que le tunnel ne possède pas

Un client de confidentialité sous Windows ou macOS touche généralement trois endroits à la fois. Il définit le proxy HTTP du système, le même champ qu’expose Internet Options. Il installe une carte réseau virtuelle, souvent un pilote TAP, pour pouvoir capturer des paquets. Et il réécrit la liste des résolveurs, alors que seule la connexion tunnel disparaît quand on appuie sur déconnecter.

Une extension de navigateur est une chose plus étroite. Elle modifie normalement son propre profil ou le proxy que suit un navigateur. C’est pourquoi un seul navigateur peut échouer alors que les outils en ligne de commande continuent de fonctionner, ou l’inverse : l’extension n’a jamais eu l’autorité de toucher les autres couches. La couche qu’elle a modifiée détermine quels outils cassent.

Dans les deux cas, la décision périmée a été prise par un logiciel qui n’avait aucune raison de l’annuler. Le tunnel était la partie visible, et c’était aussi la seule partie dotée d’un arrêt propre. Tout le reste est un réglage dans un stockage qui survit au processus, donc supprimer l’application est la seule étape qui annule les trois à la fois. Lire ces stockages avant de réinstaller quoi que ce soit, voilà ce qui transforme le symptôme en diagnostic.

Trois résidus, trois pannes différentes

Le premier résidu est un proxy qui ne pointe vers rien : la case du proxy LAN est encore cochée, ou l’URL d’un script de configuration vise un port localhost où plus aucun processus n’écoute. Le navigateur transmet chaque requête à ce port mort et se bloque jusqu’à ce que le délai d’attente ressemble à un réseau mort. Le deuxième est une carte réseau qui possède encore une route par défaut, parce qu’un périphérique TAP-Windows ou un pilote de routage du fournisseur reste une interface réelle après une désinstallation. Il conserve la route qui lui a été donnée, et le trafic disparaît dans un tunnel qui n’existe pas. Aucun des deux résidus ne s’annonce ; tous deux ressemblent exactement à une panne.

Le troisième est le DNS, et il échoue plus tôt que les deux autres. Si la liste des résolveurs ne contient que des serveurs joignables par le tunnel, chaque résolution expire avant même qu’une page soit demandée, si bien que le navigateur signale un site inaccessible plutôt qu’un proxy mort. Quel que soit celui que vous avez, aucun n’est une panne au sens du réseau. Chacun est un résidu que personne n’a révoqué, et chacun se répare à un endroit différent.

Descendez les quatre couches

Commencez au plus près de l’application et descendez, car les couches échouent dans cet ordre de visibilité. Changez une couche par test, et retestez après chacune. Tout réinitialiser d’un coup restaure généralement la navigation, et cela vous laisse incapable de dire quel résidu en était la cause, si bien que la prochaine installation recrée la même énigme. L’ordre est proxy, cartes, routes, résolveurs.

Sous Windows, chaque vérification est une commande unique fournie avec le système, donc rien à installer. Exécutez-les dans l’ordre et gardez les sorties ensemble, car les quatre réponses n’ont de sens que côte à côte. Elles rapportent le proxy, les cartes, les routes IPv4 et la liste des résolveurs, dans cet ordre :

netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress

Linux et macOS ont besoin de leurs propres commandes, et elles ne sont pas interchangeables. Sous Linux, les routes viennent de ip route et les résolveurs de resolvectl status là où systemd-resolved en est propriétaire, avec un repli sur cat /etc/resolv.conf. Sous macOS, les routes viennent de netstat -rn, les résolveurs de scutil --dns, et le proxy système de scutil --proxy. Un lecteur macOS qui lance ip route obtient command not found, et /etc/resolv.conf y est un talon généré plutôt que la configuration de référence. Vérifiez la plateforme avant de vérifier la couche, sinon la première commande devient le constat.

Pour chaque couche, posez une question : cette valeur pointe-t-elle encore vers quelque chose qui existe quand l’application est fermée ? Un proxy sur un port mort, une carte sans tunnel, une route par défaut via une interface éteinte et un résolveur à l’intérieur du tunnel répondent tous non. Un seul non suffit à expliquer le symptôme, et c’est pourquoi un seul changement par test compte.

Un proxy n’est pas un tunnel

Un proxy accepte une requête, la va chercher ailleurs et renvoie la réponse, ce qui signifie qu’il connaît la destination et voit tout ce que le site n’a pas chiffré lui-même. Il ne transporte pas d’autres protocoles. Il ne protège pas le chemin, sauf si la destination utilise déjà TLS. Et il peut être modifié par ce qui l’a installé, sans votre intervention.

Cette distinction change la question qui vaut la peine d’être posée. Quand un proxy subsiste, cherchez quel programme dirige encore votre navigateur plutôt que de savoir si le tunnel est actif. Le tunnel peut être parfaitement sain et parfaitement hors sujet pour la panne.

Si vous voulez savoir ce qu’un tel client a réellement fait, observez-le au lieu de lire son tableau de bord. Process Monitor enregistre quelles clés de registre et quels fichiers il touche, tandis qu’une capture de paquets révèle où son trafic est allé. Les deux sont des outils ordinaires, et tous deux répondent mieux que n’importe quel voyant d’état à la question du résidu. Aucun ne demande que l’application tourne encore.

Retirez le composant, pas les preuves

Le correctif durable consiste à retirer ce qui a écrit le réglage. Désinstallez l’application, supprimez la carte virtuelle qu’elle a ajoutée, effacez le proxy et la liste des résolveurs, puis redémarrez et testez alors que l’application est toujours désinstallée. Si la navigation fonctionne à ce moment-là, vous avez trouvé la cause plutôt qu’un contournement. Notez quelle couche était périmée, car le même fournisseur a tendance à livrer deux fois la même erreur.

Si le symptôme revient après l’installation du client suivant, parcourez à nouveau les quatre couches avant de conclure que le service a cassé quelque chose. Les preuves sont généralement encore là, dans l’un des quatre endroits. Une seconde application ne crée pas une cinquième couche ; elle modifie l’une des quatre.

Une réinstallation réinitialise le proxy mais pas une carte périmée, et elle peut laisser deux résolveurs dans la liste. Cette asymétrie explique pourquoi désinstaller puis tester l’emporte sur un bouton de réinitialisation globale. Elle vous donne aussi une référence à laquelle comparer la prochaine fois que la connexion tombe.