Dig.Minimalist schrieb:
Ich hatte nicht erwartet dass 3 Netzwerke ein Problem darstellen bei Unifi & Omada...
Das tun sie auch nicht - es sei denn man muss über die normale Konfiguration hinaus etwas tun. Sowas wie Haupt- Gast- und HomeOffice-Netzwerk sind kein Problem, weil das einfach 3 stinknormale Netzwerke sind und lediglich ein paar Regeln in der Firewall bekommen. D.h. der Zugriff untereinander bzw. ins Internet wird reglementiert oder eben nicht. Funktioniert wunderbar und zuverlässig.
Weicht man aber von diesem Standardszenario ab, wird das Eis schon dünner.
Beispiel netzwerkübergreifendes Drucken (rein fiktives Beispiel):
Nehmen wir mal an du hast einen Drucker im Hauptnetzwerk. Nu sitzt du aber im HomeOffice und möchtest von deinem Firmenlaptop auf deinem heimischen Drucker drucken. Sofern der Drucker keine weiteren Einstellungen oder Restriktionen hat, ist es ihm egal ob er aus dem Haupt- oder dem Office-Netzwerk bedient wird - Hauptsache er hat ein Standardgateway für die Rückantwort.
Nehmen wir jetzt aber mal weiter an, dass der Hersteller - warum auch immer - in der Firmware hinterlegt hat, dass der Drucker nur aus demselben Subnetz bedient werden darf. Das hieße, dass der Drucker die IP-Adresse des anfragenden PCs prüft und ablehnt, wenn diese nicht zu seiner eigenen IP passt.
Was nun? Normalerweise könnte man nun im Router, der zwischen Haupt- und Office-Netzwerk sitzt, eine NAT-Regel einbauen, die nur für den Drucker ein SNAT/Masquerade macht, dem Drucker also vorgaukelt, dass der Router drucken will - wenn man denn so eine NAT-Regel im Router überhaupt anlegen kann! Und genau das ist der Knackpunkt.
Ein weiterer Aspekt: Doppel-NAT bei Routerkaskaden. Zumindest bei Unifi ist es gar so, dass man das automatische SNAT/Masquerade am WAN-Port nicht ausschalten kann. In einer Routerkaskade muss man also zwingend mit Doppel-NAT leben.
Das mögen Grenzfälle sein, die dich vielleicht nie betreffen. Aber es zeigt deutlich, dass die Unifi- und Omada-Router nur für übliche Szenarien geeignet sind und bei Abweichungen davon an ihre Grenzen stoßen. Ein IoT-Netzwerk ist aus den in #5 genannten Gründen je nach den eingesetzten IoT-Komponenten eben kein übliches Szenario. Selbst mit etwas wie pfSense/OPNsense oder sonstigen fortgeschrittenen Routersystemen ist ein IoT-Netzwerk nicht so einfach zu gestalten, wenn die verwendete Hardware nicht mitspielt.
Ein ganz konkretes Beispiel zu IoT:
Lampen von Philips Hue sollten ja bekannt sein. Dazu gehört eine Bridge, die via LAN ins Netzwerk gehängt wird und ihrerseits via Zigbee mit den Lampen funkt. Auf einem Smartphone kann man die Hue-App runterladen. Befindet man sich im selben (W)LAN wie die Bridge, drückt man bei der App auf "Bridge suchen" und einen kurzen Moment später meldet die App "Bridge gefunden!". Die App hat einen Broadcast (eine Art Rundruf) ins Netzwerk geschickt und die Bridge hat sich daraufhin gemeldet. Ales gut.
Ich habe auch Hue zu Hause, aber meine Bridge hängt nicht im Hauptnetzwerk, sondern eben in einem IoT-Netzwerk. Nehme ich nun die App auf meinem Smartphone (Hauptnetzwerk) und klicke auf "Bridge suchen", meldet die App "Nix gefunden". Warum? Ein Broadcast ist auf das lokale Netzwerk begrenzt, die App sucht also nur in meinem Hauptnetzwerk. Glücklicherweise hat Philips mal mitgedacht und schlauerweise einen Button danach eingebaut, der sinngemäß heißt: "Bridge per IP verbinden". Gebe ich dort die IP meiner Bridge im IoT-Netzwerk ein, verbindet sich die App und alles läuft.
Aber: Das gilt bei weitem nicht für alle IoT bzw. smart devices und ihre dazugehörigen Apps. Kann die App nicht direkt via IP-Adresse verbinden, muss man entweder mit dem Smartphone in das IoT-WLAN wechseln oder das Zielgerät wohl oder übel ins Hauptnetzwerk verlegen. Die dritte Option, ein Braodcast-Relay, erwähne ich nur der Vollständigkeit halber.
