VPN déconnecté, internet toujours bloqué : interrupteur ou règle obsolète ?

Le tunnel se ferme, le navigateur s’arrête et tous les autres appareils du même Wi-Fi continuent de fonctionner, ce qui écarte le routeur. Ce schéma a trois propriétaires plausibles : un coupe-circuit à qui l’on a ordonné de bloquer, un état laissé par un client supprimé et un résolveur ou une route qui n’a jamais été restauré. Depuis la fenêtre du navigateur, ils semblent identiques et exigent des réparations différentes. Déterminez lequel vous avez avant de lancer une réinitialisation réseau.

Deux internets bloqués très différents

Un blocage délibéré est une fonction : tant qu’aucun tunnel n’est actif, le client abandonne le trafic pour que rien ne fuie hors du chemin protégé. Un blocage accidentel est une règle, un réglage d’appareil ou de résolveur qui a survécu à la sortie du client. L’un se répare en se connectant ou en désactivant volontairement la politique, l’autre en nettoyant ce qui a été laissé.

La différence se voit dans l’erreur, pas dans le navigateur. Un blocage délibéré produit généralement un refus immédiat ou un blocage silencieux, tandis qu’un résolveur résiduel produit un échec de résolution de noms qui persiste même lorsqu’un ping vers une adresse littérale fonctionne. Aucun des deux n’est identique à une connexion Wi-Fi cassée, qui toucherait aussi les autres appareils. Classez les vérifications selon cette différence : d’abord une adresse littérale, ensuite un nom.

Ce que le client a promis à la déconnexion

Lisez les réglages propres au client pour comprendre le sens de la déconnexion, car de nombreux produits distinguent une pause d’un arrêt complet. Une pause maintient le blocage par conception, tandis qu’un arrêt peut le retirer. Certaines plateformes mobiles expriment la même idée sous forme de règle toujours active qui bloque le trafic dès qu’aucun VPN n’est connecté.

Là où l’organisation exige une protection, la réparation consiste à reconnecter le bon profil plutôt qu’à contourner le blocage. Vérifiez que le nom du serveur se résout encore et que le point de terminaison est joignable via les exceptions documentées par le déploiement, car une reconnexion ratée ressemble exactement à un blocage persistant.

État obsolète d’une suppression interrompue

Une désinstallation interrompue, ou un paquet supprimé pendant que le tunnel était actif, peut laisser derrière elle une chaîne de pare-feu, une règle de routage, une entrée de résolveur ou un adaptateur virtuel. Le processus a disparu et les effets non.

Commencez par le parcours de nettoyage et de réparation pris en charge par l’application, puis, avant de supprimer, identifiez quel composant a installé chaque objet restant. Couper le pare-feu de l’hôte rétablit la navigation et retire en même temps une protection sans rapport. Une réinitialisation réseau globale est pire, car elle jette des réglages de bureau ou Wi-Fi qui fonctionnent sans nommer la cause.

Si deux clients sont installés, décidez lequel possède la politique. Deux propriétaires, voilà comment un blocage survit à la suppression des deux.

Vérifiez l’état déconnecté, pas seulement la navigation

Que la navigation remarche est un faible test d’acceptation. Vérifiez que la politique requise est intacte et que rien d’autre n’a été silencieusement affaibli.

ip rule show
ip route show table all | grep -v '^default'
resolvectl status | head -n 20
sudo nft list ruleset | grep -A 6 'chain output'

Comparez les règles de routage, le résolveur et la politique de pare-feu à l’aspect d’une machine déconnectée propre. Rebranchez et déconnectez ensuite via le flux de travail habituel et répétez les lectures, afin que l’état attendu soit écrit plutôt que mémorisé.

Conservez cette paire avant-après dans le ticket. La prochaine personne qui verra un navigateur bloqué en aura plus besoin que d’un avis de plus sur le meilleur client.