Ist dann blöd, wenn man z.B. Smart-Home-Geräte hat, die direkt per IP-Adresse angesprochen werden.
Ich würd' ja dann erst mal mein LAN soweit sauber konfigurieren, dass das nicht nötig ist (lokale Domain vergeben, Hostnamen sinnvoll vergeben, ggf. /etc/hosts pflegen usw.) - aber auch in diesem Fall weist man dann im DHCP Server der jeweiligen MAC eine "feste" IP zu und keine außerhalb des IP-Adressraums.
Warum? Weil statische IPs verwaltet werden müssen, denn spätestens bei einer Doppelvergabe oder einer Änderung des Subnetzes kommt man ansonsten in Teufels Küche, wenn man nicht weiß, was man tut und die Adressen manuell dann in der richtigen Reihenfolge ändert. Stichwort & typischer Fehlerfall wäre "Neues Gerät mit (notwendigerweise) fixer default-IP, die einer bereits vergebenen Adresse entspricht in Netz hängen".
Bei einer FB zugegebenermaßen egal, der Routing-Teil ist da dermaßen beschränkt, dass man bis auf Doppelvergaben (s.o.) in die meisten Fehler gar nicht reinlaufen kann. Soll aber ja auch Mitleser geben, die Ubiquiti & Co. im Einsatz haben und die weniger wegen ihrer Netzwerkkenntnisse und mehr wegen des GUIs gekauft haben.
Gerade nachgelesen, das geht bei Apple seit 2020. Śachen gibt es…
Das ging auch bei nicht-Apple Geräten schon lange vorher - einer der Gründe, warum du auch hier im Forum unzählige Beiträge findest, wo die angebliche Sicherheit durch Zugriffssteuerung in WLANs durch MAC-Filter negiert wird. Das ist und war nie ein Schutz gegen jemand, der in dein (W)LAN rein will.
Welche IP-Adressen mein iPhone und/oder meine Apple Watch bei mir im WLAN vergeben bekommen, ist mir eigentlich wurscht. Hauptsache, sie laufen.
Welche IP-Adressen sie haben, kann und sollte dir auch egal sein - nicht aber die Möglichkeit, Geräte eindeutig zu identifizieren (-> feste MAC). Sonst laufen alle weiterführende Sicherheitsmaßnahmen ins Leere.
Bei einer FB wie gesagt egal, die kann das alles nicht - aber es könnte ja auch Mitleser geben, die Router mit weiterführenden Funktionen einsetzen.
Sollte es denn nicht reichen, einem Gerät eine feste IP-Adresse zu geben und DHCP erkennt das dann?
Nein. Wenn "feste" IP, dann entweder statisch lokal außerhalb des IP-Adressraums, oder im DHCP-Server an die MAC binden. Letzteres ist auch schlampig, wird aber in 99% der Fälle funktionieren und im restlichen 1% kann man die Fehler dann durch Löschen der Zuordnung im Server und Neustart des Geräts beheben.
Einzige Ausnahme sind diejenigen Geräte der Netzwerkinfrastruktur, die nach einem Stromausfall die Initiative der Konfiguration übernehmen müssen, also z.B. DHCP- und DNS-Server. Hier in dem Fall also die Fritzbox selbst.
... und diese (statischen) IP-Adressen gehören schon prinzipbedingt nicht in den DHCP Adressraum.
Ich habe da so ein paar Raspberry- und HomeMatic-Skripte, da erfolgt der Aufruf nur per IP-Adresse.
Hast du die da 'rein geschrieben oder können die Skripte tatsächlich keine lokale Namensauflösung? Dann würd' ich mir andere Skripte suchen.
Wie gesagt, man kann ja bei einigen WLAN-Geräten statische IP-Adressen setzen.
Statische IP (konfiguriert man im Netzwerkgerät) != feste IP-Zuweisung durch DHCP-Server (konfiguriert man im Server)
Aber evtl. hat sich das mittlerweile auch geändert und die WLAN-Router erkennen die statische WLAN-Adresse und blockierenn sie dann im DHCP-Bereich.
Nein. Wie soll das auch gehen? Der DHCP-Server könnte den Konflikt ja frühestens dann erkennen, wenn du das Gerät ins Netz hängst und dann ist der Konflikt bereits da.
Das lief alles nach ein paar Minuten, u.A. 50 Shellys und ein umfangreiches Smarthome-Setup. Das wäre mit DHCP ein riesen Aufwand gewesen.
Das ist mit DHCP überhaupt kein riesen Aufwand, wenn man sich nicht darum gedrückt hat, eine lokale Namensauflösung (oder halt gleich einen lokalen DNS) zu konfigurieren. Wenn man in seinen Skripten und Konfigurationen IP-Adressen hardcoded, wird's ein Riesenaufwand - das ist aber kein Problem, sondern ein Symptom eines entsprechend rudimentären Netzwerksetups.
Das kann übrigens auch schon eine Fritzbox. Einfach alle Hostnamen sauber vergeben und über <hostname>.fritz.box (wenn man die Standardeinstellungen nicht geändert hat) oder <hostname>.local statt IP-Adresse ansprechen. Notfalls die /etc/hosts anpassen, wenn das tatsächlich nicht funktioniert. Vorher aber mal erst die ganzen tollen Netzwerkschützer wie Pi-Holes, Adblocker, LittleSnithc & Co. prüfen, ob man da nicht aus "Sicherheitsgründen" die lokale Namensauflösung irgendwo blockiert.
.
