VPN installé sous Windows, Linux démarre sans réseau : que vérifier
Chaque démarrage exécute sa propre pile réseau, donc un filtre VPN Windows n’est pas actif sous Linux. Vérifiez lien, adresse, route et DNS avant de réinitialiser quoi que ce soit.
Vous installez un VPN sous Windows, vous redémarrez sous Linux, et la connexion filaire est morte. L’histoire évidente s’écrit toute seule : le VPN a laissé quelque chose derrière lui. L’histoire est fausse, car les deux démarrages exécutent des noyaux distincts avec des pilotes distincts, des tables de routage distinctes et des résolveurs distincts. Un filtre réseau Windows ne s’exécute pas dans Linux, la panne se situe donc soit dans la pile Linux, soit dans quelque chose que les deux démarrages partagent réellement, comme le matériel, le firmware ou le routeur.
Le symptôme et la mauvaise conclusion
La partie utile de l’observation est le moment : la panne est apparue après un changement. La partie inutile est le saut causal vers le VPN Windows, qui ne peut pas fonctionner dans l’autre système d’exploitation. Séparer les deux, c’est tout le travail. Notez la chronologie avant de toucher un câble.
Ce que les deux démarrages partagent réellement, c’est l’adaptateur physique, le câble, le port du commutateur et tout ce qui se trouve en amont. Ce sont de vraies variables communes, et elles méritent une vérification après l’inspection de la pile Linux.
Capturez la pile Linux en quatre commandes
Commencez en lecture seule et enregistrez l’état avant de changer quoi que ce soit : ip -br link pour la présence des interfaces, ip -br address pour les adresses, ip route pour les routes IPv4 et ip -6 route là où IPv6 compte. La référence de l’outil ip distingue ces objets, et une interface présente dans la liste ne prouve pas qu’elle a une adresse opérationnelle ou une route utilisable.
Enregistrez la sortie dans un fichier pour la comparer plus tard à un démarrage qui fonctionne. Une capture que vous ne pouvez pas reproduire n’est qu’un souvenir d’un état.
Est-ce le lien, l’adresse, la route ou le nom ?
Quatre pannes différentes se ressemblent depuis un navigateur. L’appareil peut manquer complètement, être présent sans porteuse, être lié mais sans l’adresse attendue, ou avoir une adresse sans route vers la destination. L’échec de la résolution de noms alors que les adresses brutes fonctionnent est un cinquième cas, et il relève du résolveur et non du pilote.
Chaque cas renvoie à un travail différent : pilote ou firmware pour un appareil manquant, câblage ou commutateur en l’absence de porteuse, DHCP ou configuration statique pour une adresse manquante, et routage ou politique pour un chemin manquant. Un problème de résolveur renvoie à systemd-resolved, NetworkManager ou une configuration DNS locale.
Vérifiez si l’installation Linux possède son propre VPN ou une configuration de pare-feu persistante. Un tunnel local ou un ensemble de règles nftables est un responsable côté Linux, et il est bien plus probable qu’il explique la panne qu’un programme Windows qui ne s’exécute pas.
Comparez ensuite la transition de démarrage
Windows Fast Startup est un arrêt hybride qui conserve l’état de session du noyau au lieu d’effectuer un démarrage complet. La documentation Microsoft sur les états d’alimentation le distingue d’un redémarrage et d’un arrêt complet, ce qui explique pourquoi le même matériel peut se comporter différemment lors des deux transitions.
Si la panne dépend du passage d’un système d’exploitation à l’autre, comparez un redémarrage documenté ou un arrêt complet au chemin normal, après avoir enregistré votre travail. Un résultat qui suit la transition justifie d’examiner l’état du pilote, de l’appareil ou du firmware, et il ne prouve pas à lui seul que Fast Startup a causé une panne d’adaptateur particulière.
Notez quel système d’exploitation a utilisé l’adaptateur en dernier, le type de transition, l’état du lien sous Linux et la première opération qui a échoué. Une différence reproductible entre démarrage à froid et transition à chaud vaut bien plus que la suppression du logiciel VPN des deux installations sans savoir quelle pile a cassé.
Ce qu’il ne faut pas changer
Ne réinitialisez pas les deux piles réseau en premier réflexe. Cela détruit la comparaison et ne corrige souvent rien, parce que le véritable responsable n’a jamais été identifié. Ne réinstallez pas le VPN Windows pour réparer Linux, et ne modifiez pas les réglages du firmware au hasard parce qu’une transition de démarrage a coïncidé avec une panne.
La référence de l’outil ip documente les objets lien, adresse et route utilisés ci-dessus. Lisez d’abord le côté Linux, conservez la capture, et décidez seulement ensuite si la couche matérielle partagée mérite une investigation.