Wie sich herausstellt, ist es sehr einfach, Ihr System zu brechen, wenn Sie Ihr Herz und Ihren Verstand darauf verwenden. Dieses Problem hat einen komplizierten Ursprung und eine ziemlich interessante Lösung, also haben Sie Geduld mit mir. Zufällig war es eine dunkle und regnerische Nacht, und ich machte mich daran, mehrere VPN-Dienste zu testen. Einer von ihnen:Mullvad. Es hat eine Weile gut funktioniert, aber dann habe ich die Anwendungsversion von Build 2019.1 auf Build 2019.8 aktualisiert, und die Dinge funktionierten nicht mehr einwandfrei. Immer wenn ich mich mit VPN verbinde, stoppt die DNS-Auflösung. Testbox:Kubuntu 18.04.
Ich war mir nicht sicher, ob dies spezifisch für meinen Host oder ein umfassenderes Problem war, also entschied ich mich, auch in KDE Neon zu testen, was zufällig eine der vielen Distributionen ist, die ich auf dem G50-Laptop installiert habe. Ein oder zwei Neustarts später, viele nette Plasma-Updates (die zum Zeitpunkt des Schreibens bis zu 5.16.90 reichten) und einige kleine Optimierungen, ich hatte Mullvad am Laufen. Aber dann fing der Netzwerkmanager an, sich über eingeschränkte Konnektivität zu beschweren. Mal sehen, was sich ergibt.
Mehr Probleme, mehr Details
Zuerst wollte ich verstehen, WARUM Mullvad in der Kubuntu-Instanz nicht gut funktionierte. Nach einigem magischen Debuggen stellte ich fest, dass es einen Konflikt mit Pi-Hole gab, das lokal installiert war. Wenn es um DNS geht, kann es nur einen geben. Oder so. Und natürlich hilft systemd mit seinen unzähligen symbolischen Links und verschleierten Protokollen nicht weiter. Aber das ist eine andere Geschichte.
In Neon hatte ich die VPN-Konnektivität, aber etwa eine Minute nach Beginn der Sitzung tauchte plötzlich das Ausrufezeichen neben dem Wireless-Symbol auf. Neugierig. Ich habe alle möglichen Netzwerkgeschwindigkeits- und Konnektivitätstests durchgeführt, und alles funktionierte ohne Probleme. Das Icon blieb jedoch - und nmcli general bestätigt dies auf der Kommandozeile.
Was sagt das Protokoll?
Nun, das Durchsuchen von Systemprotokollen ist nie eine unterhaltsame Aktivität, aber diese zeigte etwas, das ich noch nie zuvor gesehen habe. Fehler im Zusammenhang mit den virtuellen VMware Workstation-Adaptern vmnet1 und vmnet8. Anscheinend waren es Probleme mit der DHCP-Funktionalität.
... dhcpcd[1042]:vmnet8:dhcp_sendpacket:Operation nicht erlaubt
... dhcpcd[1042]:vmnet1:dhcp_sendpacket:Operation nicht erlaubt
Da das Workstation-Setup sowieso eine abgelaufene Testversion war, entschied ich mich, das Programm zu deinstallieren und zu sehen, ob dies das Problem tatsächlich lösen würde. Und es sieht so aus. Der eigentliche Grund für das Problem lag darin, dass Mullvad so konfiguriert ist, dass es den lokalen Netzwerkverkehr standardmäßig blockiert, wenn es verbunden ist, was die lokalen Bereiche einschließt, die von den vmnet-Adaptern verwendet werden.
Daher besteht die Problemumgehung darin, lokalen Datenverkehr in der VPN-Anwendung zuzulassen oder alternativ die Verwendung der betroffenen Software zu optimieren. Andererseits ist das Problem nicht wirklich eines, es sei denn, Sie müssen beide gleichzeitig verwenden. Für die meisten Menschen wird dies nie relevant sein.
Also, was ist die Botschaft hier?
Ich habe Dutzende von Berichten über den "Netzwerkmanager + Ausrufezeichen" im Web gesehen, und die meisten Benutzer glauben, dass dies ein dummer Fehler ist, ein vorübergehendes Verhalten, das durch einen Neustart des Netzwerkmanagers oder eine erneute Verbindung mit dem Netzwerk behoben werden kann. aber in diesem speziellen Fall gab es eine "Art" echtes Problem - es stimmt jedoch mit dem Wort dumm überein. Es war nicht groß oder kardinal oder auffällig, es sei denn, Sie mussten gerade zu diesem Zeitpunkt virtuelle Maschinen ausführen, aber es existierte, und der Netzwerkmanager hat tatsächlich korrekt einen verschlechterten Status der Funktionalität und damit eine eingeschränkte Konnektivität gemeldet.
Schlussfolgerung
Zufällige kleine Probleme können sehr nervig sein. Umso mehr, wenn Sie sie gerne als Fehler in der Software ignorieren möchten, sie dann aber real sind. Nicht unbedingt kardinal, nur kein Fehlalarm. Aus diesem Grund sollten Sie niemals Probleme diagnostizieren, wenn Ihre Kernfunktionalität vollständig vorhanden ist. Aber wir haben das herausgefunden, also ist alles in Ordnung.
In einem Szenario wie diesem wäre der nächste logische Schritt, dass das Betriebssystem die Details des Problems teilt, anstatt nur zu warnen, und es dem Benutzer ermöglicht, die Auswirkungen vollständig zu verstehen und dann zu entscheiden, ob er etwas tun oder ignorieren möchte. Das Ausrufezeichen ohne ausführliche Erklärung ist unnötig alarmierend, zumal es keinen sichtbaren Effekt gibt. Und seien wir ehrlich, wenn das Internet funktioniert, dann gibt es kein Problem, richtig! Nun, wenn Sie einer der Nerds sind, die plötzliche Zufälle hassen, könnte dies Ihre OCD-Dämonen ganz leicht beruhigen. Wenn das Ausrufezeichen jetzt noch einmal kommt, werden wir uns unterhalten. Wieder. Wir sind fertig.