Datenschutz und Sicherheit -> Lokales Netzwerk: verbuggt in macOS Sequoia

[James Atlick]

Die Datenschutz Funktion bezüglich "Geräte im Lokal Netzwerk zu finden" ist verbuggt seit macOS Sequoia.

Remotedesktop und Nextcloud funktionieren nicht mehr, wenn die Berechtigung nicht gegeben wird.
Was bei Nextcloud abstrus ist, da dies gar nicht im lokalen Netzwerk läuft bei mir.
Vor macOS Sequoia war dies noch kein Problem.

Browser wie Firefox und Chrome sind dabei noch seltsamer, da sie sich nicht konsistent und teilweise unterschiedlich nach Gerät verhalten.
Teilweise können lokale webGUIs aufgerufen werden, teilweise nicht. Ein Muster ist nicht wirklich erkennbar. Manchmal hilf bereits an und wieder ausschalten.

TLDR: Falls bei Euch eine App nicht läuft oder ihr nicht mehr auf die Webseite Eurer Fritzbox kommt, versucht es mit
Systemeinstellungen -> Privatsphäre und Sicherheit -> Lokales Netzwerk.

 

[Marcel Bresink]

Die Datenschutz Funktion bezüglich "Geräte im Lokal Netzwerk zu finden" ist verbuggt seit macOS Sequoia.

Diese Aussage ergibt so keinen Sinn, da diese Funktion neu, also in älteren Versionen überhaupt nicht vorhanden ist.

Früher konnte macOS bezüglich Netzwerk nur den Zugriff auf Netzwerk-Volumes blockieren. Jetzt wird zusätzlich auch der Zugriff auf Bonjour blockiert. Das ist mit "Geräte finden" gemeint.

Wenn das bei Dir zum Ausfall von Netzwerkfunktionen führt, ist zu vermuten, dass der lokale DNS-Server nicht passend konfiguriert ist, bzw. die Bonjour-Domain ".local" als Ersatz verwendet werden muss.

 

[James Atlick]

Du hast recht, dachte es gab die Funktion schon vor Sequioa und sie wäre einfach noch nie angesprungen bei mir, weil ich keine solche Apps habe.

Naja, jedenfalls hat dies nix mit Bonjour zu tun. Es geht nicht um Bonjour Dienste, sondern um Dinge wie lokale webGUIs oder Nextcloud.

 

[Marcel Bresink]

Web-GUIs und Nextcloud erfordern Zugriffe über das Netz, wobei DNS-Abfragen stattfinden, um das Vorhandensein von Zertifikaten zu prüfen. Selbstverständlich tangiert das auch Bonjour-Funktionen.

 

[James Atlick]

Spoiler: was du schreibst ist falsch oder am Thema vorbei

WebGUIS können auch über IPs aufgerufen werden.
Nextcloud kann DNS benötigen um A oder AAAA records abzufragen, das hat dann aber nix mit lokalem Netzwerk zu tun (ausser dass eventuell der DNS im lokalen Netzwerk ist, dann würde es aber genauso das aufrufen von apfeltalk.de passieren, weil dies ja auch über den lokalen DNS läuft).
Zertifikate sind nochmals eine ganz andere Baustelle, sind aber ebensowenig von DNS abhängig.
Ja, Bonjour verwendet mDNS, ist aber total am Thema vorbei, weil die besprochenen Dienste gar kein Bonjour verwenden.

Ich versuche es mal so: Reddit Link mit dem gleichen Problem

 

[Marcel Bresink]

WebGUIS können auch über IPs aufgerufen werden.

Das hat nichts mit dem Problem zu tun. Aus Sicherheitsgründen wird der Browser trotzdem DNS-Abfragen durchführen, um festzustellen, mit welcher Gegenstelle er es zu tun hat. Das kann sogar passieren, wenn Server und Browser auf dem gleichen Rechner laufen.

Zertifikate sind nochmals eine ganz andere Baustelle, sind aber ebensowenig von DNS abhängig.

Nein, Dir fehlt offenbar elementares Basiswissen.

Reddit Link mit dem gleichen Problem

Was soll uns das jetzt sagen? Noch mehr Leute ohne Fachwissen?

 

[James Atlick]

Das hat nichts mit dem Problem zu tun. Aus Sicherheitsgründen wird der Browser trotzdem DNS-Abfragen durchführen, um festzustellen, mit welcher Gegenstelle er es zu tun hat.

Sorry, aber was für ein ausgemachter Quatsch.
Natürlich kann ich ein Netzwerk ohne DNS haben und dennoch ein webGUI über die IP 10.10.10.1 aufrufen.

Nein, Dir fehlt offenbar elementares Basiswissen.

Ich glaube eher du leidest unter dem Dunning Kruger Effekt.
"Alternative Names" für X.509 Zertifikate. Kein DNS!

Was soll uns das jetzt sagen? Noch mehr Leute ohne Fachwissen?

Wenn du nach lesen dieses Threads das Problem noch immer nicht verstehen kannst, bist du offensichtlich nicht fähig oder willens das Problem zu verstehen.
Statt hier zu stören und mir fehlendes Basiswissen vorzuwerfen, könntest du dich über Zertifikate schlau machen

 

[Marcel Bresink]

Natürlich kann ich ein Netzwerk ohne DNS haben und dennoch ein webGUI über die IP 10.10.10.1 aufrufen.

Das hat niemand bestritten, aber durch diese Konfiguration zwingst Du macOS dazu, auf Bonjour auszuweichen.

"Alternative Names" für X.509 Zertifikate. Kein DNS!

Genau. Und kein DNS heißt, dass das System auf andere Weise das lokale Netzwerk überprüfen muss, um festzustellen, welcher Name gültig ist.

 

[Sequoia]

Es ist wieder ein typischer Thread des Nutzers.

Ich würde mal, mit Verlaub unterstellen, dass @Marcel Bresink durchaus die nötige Expertise bzgl. Netzwerk usw. aufweist

 

[James Atlick]

Das hat niemand bestritten, aber durch diese Konfiguration zwingst Du macOS dazu, auf Bonjour auszuweichen.

Warum sollte Chrome, beim aufrufen einer lokalen IP irgendwas mit Bonjour machen?

dass das System auf andere Weise das lokale Netzwerk überprüfen muss, um festzustellen, welcher Name gültig ist.

Nein, kein name, Alternative Name und zwar die IP. Geprüft mit dem public key private key Verfahren.
Das funktioniert auch in einem offline management VLAN ohne DNS problemlos.

Es ist wieder ein typischer Thread des Nutzers.

Typischer Sequoia mal wieder. Nix konkretes beizutragen, Hauptsache mit einer dummen Anmache reingrätschen.

Bis jetzt war der gesamt Thread total irrelevant und am Thema vorbei.
Chrome verhält sich inkonsistent bezüglich lokalen webGUIs.
Bei manchen ist kein Zugriff mehr möglich, bei anderen schon.
Bei mir ging es zuerst nicht, dann mit an und wieder ausschalten geht es plötzlich.

Nicht reproduzierbar, nicht konsistent, noch kein Muster erkennbar, unterschiedliches Verhalten bei unterschiedlichen Usern.

Aber da ihr bestimmt wieder toll vom Thema abschweifen werdet und total am Thema vorbeireden möchtet, beantwortet mir doch bitte nur eine Frage:
Warum kann ich auf das webGUI Zugreifen mit Chrome, obwohl ich Chrome keinen Zugriff auf das lokale Netzwerk gestattet habe?*

*kein DoH oder DoT aktiv, keine DNS, direkte Eingabe der IP. Egal ob ein wegGUI mit cert oder ohne.

Hört doch endlich bitte auf in diesem Forum immer die Schuld auf den User zu schieben und sieht doch endlich mal ein, dass selbst die heilige Kuh Apple ab und an Fehler macht! Das ist so verdammt anstrengend, wenn man nur einen kleinen Bug diskutieren will und dann solche Unterstellungen und Nebelpetarden von Euch reintrudeln.

 

[Sequoia]

Hört doch endlich bitte auf in diesem Forum immer die Schuld auf den User zu schieben und sieht doch endlich mal ein, dass selbst die heilige Kuh Apple ab und an Fehler macht! Das ist so verdammt anstrengend, wenn man nur einen kleinen Bug diskutieren will und dann solche Unterstellungen und Nebelpetarden von Euch reintrudeln.

In meinem Beruf ist es das fatalste, eigenes Unwissen nicht zu erkennen.

In diesem Sinne, viel Spaß noch mit dem „Bug“. Marcel hat es dir wohlwollend und plausibel versucht zu erklären.

 

[Marcel Bresink]

Warum kann ich auf das webGUI Zugreifen mit Chrome, obwohl ich Chrome keinen Zugriff auf das lokale Netzwerk gestattet habe?*

Es gibt keine Möglichkeit, einen Zugriff auf das lokale Netzwerk zu verbieten. Die Datenschutzeinstellungen von macOS 15 unterstützen zwei Dinge:

• eine Bestätigung für den Zugriff auf Netzwerk-Volumes (File-Server-Verbindungen)
• eine Bestätigung für suchartige Zugriffe auf das lokale Netz (Bonjour-Dienste und ähnliche DNS-Operationen für die lokale Domain oder lokale IP-Adressen)

Nein, kein name, Alternative Name und zwar die IP.

Das heißt, Du zwingst Browser und/oder Betriebssystem, zu testen, ob die IP innerhalb oder außerhalb Deines Netzes liegt. Wie macht das System das wohl?

sieht doch endlich mal ein, dass selbst die heilige Kuh Apple ab und an Fehler mach

Apple macht andauernd schwere Fehler und die Betriebssysteme sind in einem beklagenswerten Zustand. Das wird hier seit Jahren diskutiert. Deshalb ist es wichtig, zwischen echten Bugs und Missverständnissen zu unterscheiden.

 

[James Atlick]

@Sequoia arbeitest du bei der Arbeit auch nur ad hominem oder beteiligst du dich auch stellenweise an einem Diskurs?

Es gibt keine Möglichkeit, einen Zugriff auf das lokale Netzwerk zu verbieten.

Das ist aber schade, dann ist die Funktion "Lokales Netzwerk" sehr eingeschränkt.
Was ok ist. Dann stellt sich aber halt die nächste Frage, warum es "Lokales Netzwerk" schafft, mir den Zugriff auf Nextcloud zu verbieten.
Oder manchmal sogar den Zugriff auf webGUIs per IP. Weil webGUI per IP fallen in keiner deiner zwei genannten Punkte.

Das heißt, Du zwingst Browser und/oder Betriebssystem, zu testen, ob die IP innerhalb oder außerhalb Deines Netzes liegt.

Verstehe nicht worauf du hinaus willst.
Ich "zwinge" den Browser zu nix. DNS brauche ich für ein valides Cert auch nicht. Das funktioniert auch in einem management ohne VLAN mit eigenen certs.

zu testen, ob die IP innerhalb oder außerhalb Deines Netzes liegt. Wie macht das System das wohl?

RFC1913, aber was hat dies mit dem Thema zu tun?

Apple macht andauernd schwere Fehler und die Betriebssysteme sind in einem beklagenswerten Zustand.

Naja, immerhin ist es bekannt und wird hoffentlich überarbeitet.
Ist ja auch noch ganz neu und noch nicht lange im Produktiveinsatz.

Unclear working of Local Network P… | Apple Developer Forums

forums.developer.apple.com

 

[Marcel Bresink]

Weil webGUI per IP fallen in keiner deiner zwei genannten Punkte.

Das kannst Du nur mit Sicherheit sagen, wenn Du den jeweiligen Web-Browser entwickelt hättest.

DNS brauche ich für ein valides Cert auch nicht.

Du verwechselst die Frage, was technisch mindestens nötig wäre, mit der Frage, welche indirekten Auswirkungen die manuelle Verwendung einer IP-Adresse nach sich zieht.

Und RFC 1913 beschreibt ein historisches Protokoll, das mal eine gewisse Bedeutung in Großbritannien hatte, heute aber praktisch nicht mehr eingesetzt wird.

Ist ja auch noch ganz neu und noch nicht lange im Produktiveinsatz.

Das ist eigentlich bereits 4 Jahre in allen anderen Apple-Betriebssystemen im Produktiveinsatz, nur in macOS ist es neu.

 

[James Atlick]

Mir ist ehrlich gesagt auch nicht 100% klar, was die Funktion genau bewirken soll.
Nur mDNS usw. blockieren oder komplett lokalen Zugriff blockieren?

Du verwechselst die Frage, was technisch mindestens nötig wäre, mit der Frage, welche indirekten Auswirkungen die manuelle Verwendung einer IP-Adresse nach sich zieht.

Sags du mir.

Und RFC 1913 beschreibt ein historisches Protokoll,

Sorry, meinte RFC 1918.

Aber das ist am Ende alles nettes technisches Nebengeplänkel.

Ändert nix daran, dass ich folgende Situation hatte:
- Chrome kann nicht auf webGUI
- stelle privacy auf on
- Chrome kann auf webGUI
- stellle privacy auf off
- Chrome kann noch immer auf webGUI
Das ist kein konsistentes Verhalten.

Nextcloud hingegen läuft konsequent nicht mehr, wenn ich die Funktion ausschalte.
Da wäre spannen zu wissen warum. Ich habe die Nextcloud Desktop App nicht programmiert
Finde es seltsam, da Nextcloud auf cloud.domain.com zugreift.
cloud.domain.com wird von unbound auf ein reverse proxy aufgelöst, der im lokalen Netzwerk ist.
Aber wie merkt macOS, dass dies lokal ist und nicht remote? Ich vermute mal RFC1918.
Oder macht Nextcloud irgend ein Scan, schlägt fehl weil blockiert und geht damit falsch um, statt einfach die Domain zu nutzten?

 

[Marcel Bresink]

Sorry, meinte RFC 1918.

Auch das ergibt keinen Sinn. Du verwechselst private IPv4-Netze mit lokalen Netzen.

 

[James Atlick]

Private IPv4 Netze definiert in RFC 1918 sind immer lokale Netze.
RFC1918 definiert drei reservierte Blöcke für private Netzwerke.
Private Address Spaces.
Private Address Spaces sind lokal.

Blockierst du RFC1918, kombiniert mit link local, ULA und Multicast, hast du den Zugriff aus lokale Netzwerk blockiert. Habe ich was vergessen?

 

[Marcel Bresink]

Ja, Du hast vergessen, dass ein lokales Netz keine privaten Adressen nutzen muss. Du könntest ja offizielle Adressen für das eigene Netz gekauft haben.

 

[James Atlick]

Stimmt. Glaube den edge case können wir ignorieren