Beiträge von Capybara

    Gruß in die Runde!


    Nachdem ich drei Jahre lang Tumbleweed auf meinem HP Elitebook im Dual-Boot mit Windows laufen hatte, hab ich gestern morgen klare Kante gezeigt und auf dem Laptop eine frische Komplett-Installation ohne Windows durchgeführt.


    Das bereue ich jetzt bitter.


    Nach der Tumbleeweed-Installation hab ich über Stunden gemacht, was dann so anfällt: meine üblichen Programme (nichts Verdächtiges!) installiert, Dateien zurückgespielt, Drucker eingerichtet, Verbindung zu meinem Nextcloud-Account hergestellt.


    Aber kaum war ich mit der Arbeit durch und hatte alles gecheckt, poppten im Sekundentakt Meldungen auf "Wenig Speicherplatz auf Wurzelordner des Dateisystems", nur 356 KB waren da auf wundersame Weise übrig geblieben.


    (Zum Hintergrund: Bei derTumbleweed-Installation hatte ich mich faulerweise vom Installer führen lassen, die da vorgeschlagene Partitionierung war grundsolide, und dabei sind keinerlei Mätzchen meinerseits vorgekommen.)


    Was das aktuelle Problem besonders heftig macht: Sekunden nach den Warnmeldungen wird der Benutzer vom System abgemeldet, ich kann also nichts recherchieren, geschweige denn Änderungen vornehmen.


    Sowas ist mir in Jahrzehnten noch bei keiner Installation eines Betriebssystems passiert und ich fühle mich komplett hilflos - hoffentlich nicht allzu lange.

    Grüße in die Runde!


    Der Titel untertreibt, indem er ein Problem auf DNS-Leaks beschränkt, das weder der Kundendienst von Mullvad (eher uninteressiert) noch Proton (recht ambitioniert) lösen konnte.


    Aber erst mal zum Eingemachten: OpenSUSE Tumbleweed (Kernel 6.15.5-1-default) mit Gnome 48 ist im Einsatz. Bekanntlich stellen weder Mullvad noch Proton ihre guten und bequemen VPN-Programme für OpenSUSE zur Verfügung – abgesehen von exotischen Alternativen bleibt also nur die Möglichkeit, Wireguard über die Kommandozeile oder aber OpenVPN über den NetworkManager einzusetzen.


    Bei Mullvad funktioniert die Wireguard-Variante einwandfrei … wenigstens zuerst. Nach einiger Zeit, ob nun 10 oder vielleicht 40 Minuten, treten allerdings unweigerlich DNS-Leaks auf, einfach auszumachen über dnsleaks.com oder mullvad.net/check. Die Browser trifft dabei keine Schuld: Ob nun Firefox oder LibreWolf, ob Chromium oder Brave, ob WebRTC aktiviert ist oder nicht, all das hat keinerlei Auswirkung. Ebenfalls keine Rolle spielt die Nutzeraktivität am Gerät: Ob ich Programme nutze oder den Rechner schlicht in den Ruhezustand wandern lasse, ändert nichts am Auftreten des Lecks.


    Auch bei Proton läuft es via Wireguard erst mal einwandfrei. Solange der Rechner nicht in den Ruhezustand geht und damit die WLAN-Verbindung gekappt wird, bleibt es auch dabei, bestätigen mir ip.me und dnsleaktest.com. Hier tritt das Problem erst bei einer Unterbrechung der Drahtlos-Verbindung auf: Zwar wird die bestehende VPN-Verbindung noch grafisch mit dem Schlosssymbol in der oberen Leiste angezeigt, hat sich in Wirklichkeit aber komplett verabschiedet. Trotzdem muss sie erst noch einmal per Kommandozeile formell beendet werden (sudo wg-quick down …), bevor sie dann wieder gestartet werden kann (sudo wg-quick up …). Diese Prozedur vier- oder sechsmal am Tag – kann man vergessen.


    Ebenfalls zu vergessen ist die OpenVPN-Alternative. Bei Proton tritt da beispielsweise sofort ein DNS-Leak auf.


    Nach tagelangem Kampf und angesichts der Ratlosigkeit der Kundendienstler der VPN-Anbieter bin ich allmählich mürbe – es kann doch nicht sein, dass ich das Betriebssystem wechseln muss, um ein VPN einsetzen zu können.


    Und eins noch: Wohl nicht ursächlich fürs Problem, aber womöglich ein brauchbarer Hinweis sind diese Zeilen, die neuerdings bei Aufruf einer Wireguard-Verbindung im Terminal erscheinen:


    resolvconf: signature mismatch: /etc/resolv.conf

    resolvconf: run `resolvconf -u` to update


    Hat jemand von euch da eine Idee? Schön wär's!

    Die aktuelle Versiond des in Linux-Distros weit verbreiteten Kompressions-Tools XZ Utils kommt mit einer Backdoor https://www.darkreading.com/vu…-the-backdoor-in-xz-utils, betroffen sind u.a. Nutzer von Debian Testing und OpenSuse Tumbleweed. (Bei letztgenannter erfolgt eine Entschärfung durch XZ-Downgrading bei einem Update mit zypper dup ab 30. März, habe ich gerade selbst überprüft.)


    Und wieder einmal stellen wir fest: Open Source ist eine notwendige, aber nicht hinreichende Voraussetzung für Sicherheit.

    Es geht um die Bluetooth Klassen und nicht um die Version ... ˝ł

    Natürlich … man soll eben nicht gedankenlos reagieren und lostippen, wie ich es gemacht habe.


    Neuerdings soll man allerdings auch nicht mehr meinen Workaround mit dem Bluetooth-Stick benutzen: Mit dem aktuellen Stand von Tumbleweed wird eine neue Version von bluez ausgeliefert, die auch diese Möglichkeit zerschießt. (Ich gehe mal davon aus, dass es bluez war, sonst ist mir jedenfalls kein Verdächtiger aufgefallen).

    Falls hier noch mal jemand vor demselben Problem stehen sollte, kommt jetzt der Workaround, mit dem ich den Parallelbetrieb von Bluetooth und WLAN möglich gemacht habe: Ein Bluetooth-USB-Dongle.


    Da bei Laptops dieselbe Antenne für WIFI und Bluetooth im Einsatz ist, kann es zu üblen Interferenzen kommen, ein Bluetooth-Adapter verhindert eben dies. (Bei mir ein Edimax BT-8500, der sich ausgezeichnet mit dem aktuellen Linux-Kernel verträgt.)

    War ja nur nen Rat von mir, kannst es ja auch mal mit nem bugreport versuchen.


    Dort solltest du aber auch sagen, was du während/nach der Installation gemacht hast.

    Die Totalblockade des Internetzugangs war dann doch ohne Radikalmaßnahme wieder aufzuheben. Und: Wenn ich von "Gefummel" geredet hab, hat das wahrscheinlich falsche Vorstellungen erweckt. Die Installation ist weitgehend standardmäßig abgelaufen, und danach fiel für jemand, der von Debian kommt, natürlich einiges an Gesuche an, um Software, die nicht in OpenSUSE-Repositories zu finden ist, zu ersetzen – Flatpaks, AppImages, Alternativ-Programme …

    Nichts wirklich Verdächtiges also. Ich bediene mich nicht mal aus den Packman-Repos, um denkbare Konflikte zu vermeiden.


    Was übrigens noch bemerkenswert ist: Anfänglich brach die WLAN-Verbindung nach Einsatz von Bluetooth-Lautsprechern gelegentlich ab und war dann wieder für eine halbe oder sogar ganze Stunde herstellbar. Heute ist das WLAN zuverlässig wie auf Knopfdruck deaktiviert, sobald die Bluetooth-Verbindung steht.