Il s'avère qu'il est très facile de casser votre système si vous y mettez votre cœur et votre esprit. Ce problème a une origine alambiquée et une solution plutôt intéressante, alors soyez indulgent avec moi. Il se trouve que c'était une nuit sombre et pluvieuse, et j'ai entrepris de tester plusieurs services VPN. L'un d'eux :Mullvad. Cela a bien fonctionné pendant un certain temps, mais j'ai ensuite mis à niveau la version de l'application de la version 2019.1 à la version 2019.8, et les choses ont cessé de fonctionner correctement. Chaque fois que je me connectais au VPN, la résolution DNS s'arrêtait. Boîte d'essai :Kubuntu 18.04.
Je ne savais pas si cela était spécifique à mon hôte ou à un problème plus large, j'ai donc décidé de tester également dans KDE neon, qui se trouve être l'une des nombreuses distributions que j'ai installées sur l'ordinateur portable G50. Un ou deux redémarrages plus tard, beaucoup de belles mises à jour Plasma (allant jusqu'au 5.16.90 au moment de la rédaction), et quelques petits ajustements, Mullvad fonctionnait bien. Mais ensuite, le gestionnaire de réseau a commencé à se plaindre d'une connectivité limitée. Voyons ce que ça donne.
Plus de problèmes, plus de détails
Tout d'abord, je voulais comprendre POURQUOI Mullvad ne fonctionnait pas bien dans l'instance de Kubuntu. Après un débogage magique, j'ai réalisé qu'il y avait un conflit avec Pi-Hole, installé localement. En matière de DNS, il ne peut y en avoir qu'un. Ou quelque chose. Et bien sûr, systemd n'aide pas avec sa myriade de liens symboliques et ses journaux obscurcis. Mais c'est une autre histoire.
Au néon, j'avais la connectivité VPN, mais environ une minute après le début de la session, le point d'exclamation est soudainement apparu à côté de l'icône Sans fil. Curieux. J'ai fait toutes sortes de tests de vitesse et de connectivité du réseau, et tout fonctionnait sans aucun problème. Cependant, l'icône est restée - et nmcli general le confirme sur la ligne de commande.
Que dit le journal ?
Eh bien, parcourir les journaux système n'est jamais une activité amusante, mais celle-ci a montré quelque chose que je n'avais jamais vu auparavant. Erreurs liées aux adaptateurs virtuels VMware Workstation vmnet1 et vmnet8. Apparemment, il s'agissait de problèmes avec la fonctionnalité DHCP.
... dhcpcd[1042] :vmnet8 :dhcp_sendpacket :opération non autorisée
... dhcpcd[1042] :vmnet1 :dhcp_sendpacket :opération non autorisée
Comme la configuration de Workstation était de toute façon une version d'essai expirée, j'ai décidé de désinstaller le programme et de voir si cela résoudrait réellement le problème. Et il semble que ce soit le cas. La raison réelle du problème était que Mullvad est configuré pour bloquer le trafic du réseau local par défaut lorsqu'il est connecté, ce qui inclut les plages locales utilisées par les adaptateurs vmnet.
Par conséquent, la solution de contournement au problème consisterait à autoriser le trafic local dans l'application VPN ou à modifier l'utilisation du logiciel concerné. Là encore, le problème n'en est pas vraiment un, à moins que vous ne deviez utiliser les deux en même temps. Pour la plupart des gens, cela ne sera jamais pertinent.
Alors, quel est le message ?
J'ai vu des dizaines de rapports sur le "gestionnaire de réseau + point d'exclamation" sur le Web, et la plupart des utilisateurs pensent qu'il s'agit d'un bogue stupide, un comportement transitoire qui peut être résolu en redémarrant le gestionnaire de réseau ou en reconnectant le réseau, mais dans ce cas particulier, il y avait une "sorte de" problème réel - cependant, cela correspond au mot idiot. Ce n'était pas grand ou cardinal ou perceptible à moins que vous n'ayez besoin d'avoir des machines virtuelles en cours d'exécution juste à ce moment-là, mais cela existait, et le gestionnaire de réseau a en fait signalé correctement un état dégradé de fonctionnalité, d'où une connectivité limitée.
Conclusion
De petits problèmes aléatoires peuvent être très ennuyeux. D'autant plus lorsque vous avez tendance à vouloir les ignorer comme un bogue dans le logiciel, mais qu'ils finissent par être réels. Pas nécessairement cardinal, mais pas un faux positif. C'est pourquoi vous ne devriez jamais diagnostiquer les problèmes si toutes vos fonctionnalités de base sont présentes. Mais nous avons compris celui-ci, donc tout va bien.
Dans un scénario comme celui-ci, la prochaine étape logique serait que le système d'exploitation partage les détails du problème plutôt que de simplement alerter, et permette à l'utilisateur de comprendre pleinement les implications, puis de décider de faire quelque chose ou de les ignorer. Le point d'exclamation, sans aucune explication verbeuse, est inutilement alarmant, d'autant plus qu'il n'y a aucun effet visible. Et avouons-le, si Internet fonctionne, alors il n'y a pas de problème, n'est-ce pas ! Eh bien, si vous faites partie des nerds qui détestent le hasard soudain, celui-ci pourrait calmer légèrement vos démons TOC. Maintenant, si jamais le point d'exclamation revient, nous parlerons. De nouveau. Nous avons terminé.