7
AVAHI mDNS-Reflector Multicast nur zwischen bestimmten Interfaces zulassen
Hallo,
ich habe folgendes "Problem".
Unsere neuen AccessPoints unterstützen leider kein Bonjour-Gateway mehr. Daher habe ich kurzerhand eine Debian VM mit Avahi (mDNS Reflector) bereitgestellt. Die virtuelle Maschine hat mehrere Interfaces.
Wir haben mehrere VLANs fürs WLAN (Gast, Produktiv, Besprechungsraum) und mehrere VLANs für Mediengeräte, welche Apple TVs, AirPlay-Geräte oder Drucker enthalten.
Nehmen wir an, die Linux VM hat folgende Interfaces konfiguriert:
VLAN 10 -> Wifi Guests
VLAN 20 -> Wifi Produktiv
VLAN 30 -> Wifi Besprechungsraum
VLAN 30 -> AirPlay-Geräte Besprechungsraum (selbes Netz)
VLAN 40 -> AirPlay-Geräte Gebäude 1
VLAN 50 -> AirPlay-Geräte Gebäude 2
VLAN 60 -> AirPrint-Drucker
Der mDNS Reflector funktioniert insofern, dass ich in jedem einzelnen Wifi-VLAN aber auch jedes Gerät aller anderen VLANs bzw. lokalen Interfaces der Debian VM sehe (AirPlay-Geräte Besprechungsraum, AirPlay-Geräte Gebäude 1, AirPlay-Geräte Gebäude 2 und AirPrint-Drucker).
Ich kann den Zugriff zwar via ACLs Steuern (Layer 2 Netzwerk). Dennoch möchte ich beispielsweise nicht, dass im Wifi Guests (VLAN 10), die AirPrinter (VLAN 60) "published" werden.
Ist das irgendwie möglich dynamisch einzurichten?
Bspw. aus VLAN 20 möchte ich nur die Geräte von VLAN 40,50,60 sehen.
aus VLAN 10 möchte ich nur die Geräte von VLAN 30 sehen
Oder muss man schlussendlich mehrere Avahi-Server bereitstellen und das immer mit jeweils zwei Interfaces aufbauen:
AVAHI01 ->VLAN20 und VLAN40
AVAHI02 -> VLAN20 und VLAN50 etc.
Ich hatte es schon über die ufw (Firewall auf dem Avahi-Server) probiert. Einzige Regel die (bei mir) greift, ist: uwf deny out 5353/tcp. Dann wird allerdings kein Gerät mehr gefunden.
ich habe folgendes "Problem".
Unsere neuen AccessPoints unterstützen leider kein Bonjour-Gateway mehr. Daher habe ich kurzerhand eine Debian VM mit Avahi (mDNS Reflector) bereitgestellt. Die virtuelle Maschine hat mehrere Interfaces.
Wir haben mehrere VLANs fürs WLAN (Gast, Produktiv, Besprechungsraum) und mehrere VLANs für Mediengeräte, welche Apple TVs, AirPlay-Geräte oder Drucker enthalten.
Nehmen wir an, die Linux VM hat folgende Interfaces konfiguriert:
VLAN 10 -> Wifi Guests
VLAN 20 -> Wifi Produktiv
VLAN 30 -> Wifi Besprechungsraum
VLAN 30 -> AirPlay-Geräte Besprechungsraum (selbes Netz)
VLAN 40 -> AirPlay-Geräte Gebäude 1
VLAN 50 -> AirPlay-Geräte Gebäude 2
VLAN 60 -> AirPrint-Drucker
Der mDNS Reflector funktioniert insofern, dass ich in jedem einzelnen Wifi-VLAN aber auch jedes Gerät aller anderen VLANs bzw. lokalen Interfaces der Debian VM sehe (AirPlay-Geräte Besprechungsraum, AirPlay-Geräte Gebäude 1, AirPlay-Geräte Gebäude 2 und AirPrint-Drucker).
Ich kann den Zugriff zwar via ACLs Steuern (Layer 2 Netzwerk). Dennoch möchte ich beispielsweise nicht, dass im Wifi Guests (VLAN 10), die AirPrinter (VLAN 60) "published" werden.
Ist das irgendwie möglich dynamisch einzurichten?
Bspw. aus VLAN 20 möchte ich nur die Geräte von VLAN 40,50,60 sehen.
aus VLAN 10 möchte ich nur die Geräte von VLAN 30 sehen
Oder muss man schlussendlich mehrere Avahi-Server bereitstellen und das immer mit jeweils zwei Interfaces aufbauen:
AVAHI01 ->VLAN20 und VLAN40
AVAHI02 -> VLAN20 und VLAN50 etc.
Ich hatte es schon über die ufw (Firewall auf dem Avahi-Server) probiert. Einzige Regel die (bei mir) greift, ist: uwf deny out 5353/tcp. Dann wird allerdings kein Gerät mehr gefunden.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 32656878833
Url: https://administrator.de/forum/avahi-mdns-reflector-multicast-nur-zwischen-bestimmten-interfaces-zulassen-32656878833.html
Ausgedruckt am: 27.12.2024 um 02:12 Uhr
7 Kommentare
Neuester Kommentar
Hallo,
die üppige Zahl von Antworten bekräftigt meine Einschätzung, dass der Apple-mDNS-Schnodder im professionellen Umfeld eher kaum Verwendung findet. Braucht man ja an sich auch nicht.
Vielleicht liegt es aber auch am Zeitpunkt der Anfrage
Mir ist bei dem Setup nicht klar, weshalb Du den Reflektor überhaupt aufs Gästenetz legst. Die im Gästenetz befindlichen Geräte finden sich ja auch ohne Reflektor und andere Geräte sollten aus dem Gästenetz doch hoffentlich eh nicht erreicht werden, oder?
Ansonsten finde ich Deinen Ansatz mit mehreren Relektoren prinzipiell smart, bin aber nicht sicher, ob sich das umsetzen lässt. Jedenfalls kann es ja nur einen Reflektor pro Netz geben. Dein Beispiel würde also nicht gehen.
Ansätze, das zu filtern finden sich zB hier
https://forum.openwrt.org/t/filter-mdns-replies-deep-packet-inspection/1 ... (OpenWRT)
https://forum.mikrotik.com/viewtopic.php?t=197542 (Mikrotik)
sind aber schon aufwändiger. Vielleicht bringen Sie Dich auf den Weg.
Schließlich kann es an sich wohl auch egal sein, ob Geräte per mDNS gefunden werden oder nicht. Da zwischen den Netzen ja sicher ein Firewalling erfolgt, ist das am Ende eher Kosmetik.
Viele Grüße, commodity
die üppige Zahl von Antworten bekräftigt meine Einschätzung, dass der Apple-mDNS-Schnodder im professionellen Umfeld eher kaum Verwendung findet. Braucht man ja an sich auch nicht.
Vielleicht liegt es aber auch am Zeitpunkt der Anfrage
Mir ist bei dem Setup nicht klar, weshalb Du den Reflektor überhaupt aufs Gästenetz legst. Die im Gästenetz befindlichen Geräte finden sich ja auch ohne Reflektor und andere Geräte sollten aus dem Gästenetz doch hoffentlich eh nicht erreicht werden, oder?
Ansonsten finde ich Deinen Ansatz mit mehreren Relektoren prinzipiell smart, bin aber nicht sicher, ob sich das umsetzen lässt. Jedenfalls kann es ja nur einen Reflektor pro Netz geben. Dein Beispiel würde also nicht gehen.
Ansätze, das zu filtern finden sich zB hier
https://forum.openwrt.org/t/filter-mdns-replies-deep-packet-inspection/1 ... (OpenWRT)
https://forum.mikrotik.com/viewtopic.php?t=197542 (Mikrotik)
sind aber schon aufwändiger. Vielleicht bringen Sie Dich auf den Weg.
Schließlich kann es an sich wohl auch egal sein, ob Geräte per mDNS gefunden werden oder nicht. Da zwischen den Netzen ja sicher ein Firewalling erfolgt, ist das am Ende eher Kosmetik.
Viele Grüße, commodity
Hi,
Es ist eine völlig valide und verbreitete Anforderung, dass Airplay-Ziele über Subnetz-Grenzen hinweg gefunden und angesprochen werden können müssen. Auch Gäste benötigen oft (kontrollierten) Zugriff auf Airplay-Ziele außerhalb des eigenen Subnetzes. In manchen Fällen kann man die Airplay-Ziele zwar auch direkt ins Gästenetz stellen, aber dann hat man das selbe Problem halt aus der anderen Richtung: Auch die aus Sicherheitsgründen von den Gästen separierten internen Endgeräte benötigen manchmal Zugriff auf die gleichen Airplay-Ziele. Man kann ja nicht für jede Sicherheitszone eigene Airplay-Devices implementieren.
Solange man original Apple-TVs und nur Endgeräte von Apple verwendet, hat man ja ohnehin kein Problem, da sich diese Geräte auch per Bluetooth finden und für die eigentliche Datenübertragung als Fallback ggf. ein Adhoc-WLAN an der Infrastruktur vorbei etablieren. Letzteres will man in einer verwalteten High-Density-Umgebung aber möglichst nicht haben, da das verfügbare Frequenzspektrum ohnehin bereits voll ist. Ersteres ist auch nicht immer gegeben: auch andere Geräte als AppleTVs "sprechen" Airplay oder Chromecast, z.B. Digitale Tafeln, Beamer usw. - unterstützen aber kein Auffinden per Bluetooth.
Deine Analyse ist hinsichtlich des gemutmaßten Kausalzusammenhangs zwischen Antwortanzahl und Einsatzverbreitung von "Apple-mDNS-Schnodder" in Profinetzen m.E. falsch.
Wir sind uns zwar (vermutlich) einig darin, dass dieser ganze Apple-Kram Spielzeug für Heimanwender ist und vor allem das ganze Bonjour/Zeroconf-Geraffel (gibts ja nicht nur im Apple-Universum) eigentlich nicht in professionelle Netze gehört, aber es bedeutet ja nicht, dass nicht durchaus viele Anwender dies nicht trotzdem einsetzen wollen/müssen und nicht durchaus viele Admins gefordert wären, dies doch ans Laufen zu bekommen. Die Quadratur des Kreises dabei ist halt, es nicht "irgendwie" nur zum Funktionieren zu bringen, sondern Skalierbarkeit, Administrierbarkeit und Kontrolle/Steuerung sicherzustellen, obwohl das dafür gar nicht gemacht ist.
Die Tatsache, dass hier bisher keine Antworten kamen, dürfte eher darin begründet sein, dass das konkret im Zentrum der Frage stehende Avahi für diese valide Anforderung des TO offenkundig keine geeignete Funktionalität bereitstellt oder aber Avahi - möglicherweise eben genau weil dieses Features fehlt - in professionelleren Netzen keine weite Verbreitung hat.
Das Anliegen des TO ist insofern valide, als es hierbei nicht nur um ein Steuern des "Sehen-Könnens" geht, was ja für sich genommen eher ein Usebility- bzw. Komfort-Feature für die Anwender wäre, sondern auch ein Verhindern des Übertragens ungewollten Multicast-Traffics in das jeweilige Subnetz. Ein reiner Reflector ohne Steuerungsmöglichkeit und/oder Proxyfunktionalität überträgt halt sämtliche Service-Announcements in alle angeschlossenen Subnetze. Gerade aber in WLAN-Netzen (was ja häufig die typischen Gäste-Netze sind) will man möglichst die Broad- und Multicast-Last so gering wie möglich halten, weil dies unheimlich Airtime kostet und so die Performence eines großen WLANs ruiniert.
Gute WLAN-Hersteller bringen deshalb zumindest bei zentral verwalteten Lösungen nicht nur ein integriertes Bonjour-Gateway mit, mit dessen Hilfe sich mDNS-Service-Announcements zwischen den Subnetzen steuern lassen, sondern bauen das zu einem umfangreichen policybasierten Multicast-Management auf Netzwerkebene aus. Wir hatten bislang z.B. die Lösung von Meru-Networks im Einsatz. Da war das recht schön gelöst: Wenn ich dort z.B. per Policy festgelegt hatte, dass in einer ESSID nur sog. "Subscriber" zugelassen sind, aber keine sog. "Advertiser", dann wurden auch zwischen den Stations innerhalb der gleichen ESSID eventuelle mDNS-Service-Announcements bereits auf Netzebene durch die APs herausgefiltert, was unheimlich Airtime spart und dem Admin in mehrerer Hinsicht viel Kontrolle gibt. Leider wurde Meru Networks von Fortinet aufgekauft und deren System entgegen ursprünglicher Roadmaps und Beteuerungen mittlerweile abgekündigt. Übergangsweise nutzen wir jetzt einen Teil unserer APs noch bis zum geplanten Austausch weiter, indem wir eine Fortigate als WLAN-Controller einsetzen, aber da ist vieles nicht mehr so schön gelöst, wie es bei Meru mal war - leider auch das Thema mDNS/Multicast-Handling.
@seppo1:
Welche WLAN-Lösung setzt Ihr denn künftig ein, dass diese nicht mal ein einfaches Bonjour-Gateway/Proxy mitbringt?
Mit Avahi kenne ich mich leider nicht aus. Vermutlich kann das System das Geforderte nicht. Habt Ihr vielleicht eine Fortigate in Eurer Infrastruktur? Dann könnt Ihr hiermit einen verwalteten FortiAP (ggf. ohne WLAN-Funktion) als Bonjour-Gateway nutzen und damit zumindest zwischen VLANs "reglementiert" vermitteln. Möglicherweise kann das sogar auch ein FortiAP im Standalone-Mode oder "cloudmanaged", aber das habe ich noch nicht getestet.
Gruß
sk
Zitat von @commodity:
Mir ist bei dem Setup nicht klar, weshalb Du den Reflektor überhaupt aufs Gästenetz legst. Die im Gästenetz befindlichen Geräte finden sich ja auch ohne Reflektor und andere Geräte sollten aus dem Gästenetz doch hoffentlich eh nicht erreicht werden, oder?
Mir ist bei dem Setup nicht klar, weshalb Du den Reflektor überhaupt aufs Gästenetz legst. Die im Gästenetz befindlichen Geräte finden sich ja auch ohne Reflektor und andere Geräte sollten aus dem Gästenetz doch hoffentlich eh nicht erreicht werden, oder?
Es ist eine völlig valide und verbreitete Anforderung, dass Airplay-Ziele über Subnetz-Grenzen hinweg gefunden und angesprochen werden können müssen. Auch Gäste benötigen oft (kontrollierten) Zugriff auf Airplay-Ziele außerhalb des eigenen Subnetzes. In manchen Fällen kann man die Airplay-Ziele zwar auch direkt ins Gästenetz stellen, aber dann hat man das selbe Problem halt aus der anderen Richtung: Auch die aus Sicherheitsgründen von den Gästen separierten internen Endgeräte benötigen manchmal Zugriff auf die gleichen Airplay-Ziele. Man kann ja nicht für jede Sicherheitszone eigene Airplay-Devices implementieren.
Solange man original Apple-TVs und nur Endgeräte von Apple verwendet, hat man ja ohnehin kein Problem, da sich diese Geräte auch per Bluetooth finden und für die eigentliche Datenübertragung als Fallback ggf. ein Adhoc-WLAN an der Infrastruktur vorbei etablieren. Letzteres will man in einer verwalteten High-Density-Umgebung aber möglichst nicht haben, da das verfügbare Frequenzspektrum ohnehin bereits voll ist. Ersteres ist auch nicht immer gegeben: auch andere Geräte als AppleTVs "sprechen" Airplay oder Chromecast, z.B. Digitale Tafeln, Beamer usw. - unterstützen aber kein Auffinden per Bluetooth.
Zitat von @commodity:
die üppige Zahl von Antworten bekräftigt meine Einschätzung, dass der Apple-mDNS-Schnodder im professionellen Umfeld eher kaum Verwendung findet. Braucht man ja an sich auch nicht.
Vielleicht liegt es aber auch am Zeitpunkt der Anfrage
die üppige Zahl von Antworten bekräftigt meine Einschätzung, dass der Apple-mDNS-Schnodder im professionellen Umfeld eher kaum Verwendung findet. Braucht man ja an sich auch nicht.
Vielleicht liegt es aber auch am Zeitpunkt der Anfrage
Deine Analyse ist hinsichtlich des gemutmaßten Kausalzusammenhangs zwischen Antwortanzahl und Einsatzverbreitung von "Apple-mDNS-Schnodder" in Profinetzen m.E. falsch.
Wir sind uns zwar (vermutlich) einig darin, dass dieser ganze Apple-Kram Spielzeug für Heimanwender ist und vor allem das ganze Bonjour/Zeroconf-Geraffel (gibts ja nicht nur im Apple-Universum) eigentlich nicht in professionelle Netze gehört, aber es bedeutet ja nicht, dass nicht durchaus viele Anwender dies nicht trotzdem einsetzen wollen/müssen und nicht durchaus viele Admins gefordert wären, dies doch ans Laufen zu bekommen. Die Quadratur des Kreises dabei ist halt, es nicht "irgendwie" nur zum Funktionieren zu bringen, sondern Skalierbarkeit, Administrierbarkeit und Kontrolle/Steuerung sicherzustellen, obwohl das dafür gar nicht gemacht ist.
Die Tatsache, dass hier bisher keine Antworten kamen, dürfte eher darin begründet sein, dass das konkret im Zentrum der Frage stehende Avahi für diese valide Anforderung des TO offenkundig keine geeignete Funktionalität bereitstellt oder aber Avahi - möglicherweise eben genau weil dieses Features fehlt - in professionelleren Netzen keine weite Verbreitung hat.
Das Anliegen des TO ist insofern valide, als es hierbei nicht nur um ein Steuern des "Sehen-Könnens" geht, was ja für sich genommen eher ein Usebility- bzw. Komfort-Feature für die Anwender wäre, sondern auch ein Verhindern des Übertragens ungewollten Multicast-Traffics in das jeweilige Subnetz. Ein reiner Reflector ohne Steuerungsmöglichkeit und/oder Proxyfunktionalität überträgt halt sämtliche Service-Announcements in alle angeschlossenen Subnetze. Gerade aber in WLAN-Netzen (was ja häufig die typischen Gäste-Netze sind) will man möglichst die Broad- und Multicast-Last so gering wie möglich halten, weil dies unheimlich Airtime kostet und so die Performence eines großen WLANs ruiniert.
Gute WLAN-Hersteller bringen deshalb zumindest bei zentral verwalteten Lösungen nicht nur ein integriertes Bonjour-Gateway mit, mit dessen Hilfe sich mDNS-Service-Announcements zwischen den Subnetzen steuern lassen, sondern bauen das zu einem umfangreichen policybasierten Multicast-Management auf Netzwerkebene aus. Wir hatten bislang z.B. die Lösung von Meru-Networks im Einsatz. Da war das recht schön gelöst: Wenn ich dort z.B. per Policy festgelegt hatte, dass in einer ESSID nur sog. "Subscriber" zugelassen sind, aber keine sog. "Advertiser", dann wurden auch zwischen den Stations innerhalb der gleichen ESSID eventuelle mDNS-Service-Announcements bereits auf Netzebene durch die APs herausgefiltert, was unheimlich Airtime spart und dem Admin in mehrerer Hinsicht viel Kontrolle gibt. Leider wurde Meru Networks von Fortinet aufgekauft und deren System entgegen ursprünglicher Roadmaps und Beteuerungen mittlerweile abgekündigt. Übergangsweise nutzen wir jetzt einen Teil unserer APs noch bis zum geplanten Austausch weiter, indem wir eine Fortigate als WLAN-Controller einsetzen, aber da ist vieles nicht mehr so schön gelöst, wie es bei Meru mal war - leider auch das Thema mDNS/Multicast-Handling.
@seppo1:
Welche WLAN-Lösung setzt Ihr denn künftig ein, dass diese nicht mal ein einfaches Bonjour-Gateway/Proxy mitbringt?
Mit Avahi kenne ich mich leider nicht aus. Vermutlich kann das System das Geforderte nicht. Habt Ihr vielleicht eine Fortigate in Eurer Infrastruktur? Dann könnt Ihr hiermit einen verwalteten FortiAP (ggf. ohne WLAN-Funktion) als Bonjour-Gateway nutzen und damit zumindest zwischen VLANs "reglementiert" vermitteln. Möglicherweise kann das sogar auch ein FortiAP im Standalone-Mode oder "cloudmanaged", aber das habe ich noch nicht getestet.
Gruß
sk
1
Statt Avahi könnte man einen anderen Repeater verwenden welcher mit Filtern ausgestattet ist, wie etwa diesen hier bei dem man Subnetze black- und white listen kann:
https://github.com/geekman/mdns-repeater/blob/master/mdns-repeater.c
Mit Parameter -b x.x.x.x/x lässt sich blacklisten und mit -w x.x.x.x/x whitelisten, dabei lassen sich natürlich auch mehrere Subnetze angeben.
Davon lassen sich auch mehrere Instanzen starten wenn man diese mit unterschiedlichen pid-Pfaden unter dem Parameter -p angibt.
pj
https://github.com/geekman/mdns-repeater/blob/master/mdns-repeater.c
Mit Parameter -b x.x.x.x/x lässt sich blacklisten und mit -w x.x.x.x/x whitelisten, dabei lassen sich natürlich auch mehrere Subnetze angeben.
Davon lassen sich auch mehrere Instanzen starten wenn man diese mit unterschiedlichen pid-Pfaden unter dem Parameter -p angibt.
pj
1Zitat von @sk:
@seppo1:
...Habt Ihr vielleicht eine Fortigate in Eurer Infrastruktur? Dann könnt Ihr hiermit einen verwalteten FortiAP (ggf. ohne WLAN-Funktion) als Bonjour-Gateway nutzen und damit zumindest zwischen VLANs "reglementiert" vermitteln. Möglicherweise kann das sogar auch ein FortiAP im Standalone-Mode oder "cloudmanaged", aber das habe ich noch nicht getestet.
@seppo1:
...Habt Ihr vielleicht eine Fortigate in Eurer Infrastruktur? Dann könnt Ihr hiermit einen verwalteten FortiAP (ggf. ohne WLAN-Funktion) als Bonjour-Gateway nutzen und damit zumindest zwischen VLANs "reglementiert" vermitteln. Möglicherweise kann das sogar auch ein FortiAP im Standalone-Mode oder "cloudmanaged", aber das habe ich noch nicht getestet.
Nachtrag:
Also einen wirklich vollwertigen Standalone-AP-Modus scheint es bei Fortinet gar nicht zu geben. Das habe ich wohl mit einem anderen Hersteller verwechselt. Nach einem Factoryreset oder wenn man bei einem per Fortigate verwalteten AP im AP-Profil das lokale Management erlaubt hat, kommt man zwar per HTTPS und SSH auf den AP drauf und kann dort lokale Einstellungen vornehmen sowie auch ein elementares Bonjour-Relay konfigurieren, das bietet dann aber leider nicht die gesuchte Filtermöglichkeit.
Über die Cloud kann man hingegen die gleichen Einstellungen vornehmen, wie wenn eine Fortigate als WLAN-Controller eingesetzt wird. Allerdings genügt dafür nicht die kostenlose Version der Cloud, sondern dieses Feature erfordert eine laufzeitgebundene sog. "Advanced Management License". Kostet um die 200 EUR inkl. MwSt. pro AP für 3 Jahre und beinhaltet dann u.a. auch FortiCare.
Siehe
https://docs.fortinet.com/document/fortilan-cloud/23.4.0/fortilan-cloud- ...
https://www.fortinet.com/content/dam/fortinet/assets/data-sheets/fortila ...
Nachtrag Nr. 2:
Ein einzelner Unleashed-AP von Ruckus sollte es tun.
Siehe
https://docs.ruckuswireless.com/unleashed/200.1.9.12/t-CreatingABonjourS ...
https://docs.ruckuswireless.com/unleashed/200.1.9.12/t-DeployingBonjourT ...
Gruß
sk
@sk: Danke für die informativen Anmerkungen. Es ist schon klar, dass Apple-Geräte auch im professionellen Umfeld verwendet werden. 
Aber braucht man dafür unbedingt (netzübergreifend) mDNS? - Darum geht es.
Wenn ich einen Drucker netzübergreifend anbinden muss, kann ich das ja auch konventionell über die IP-Adresse erledigen. Vielleicht nicht so komfortabel, wie der Apple-User das gewohnt ist, aber Komfort und Sicherheit sind nicht immer kompatibel.
Für mich ist ein Gästenetz ein Gästenetz. Dort gibt es keine Zugriffe nach innen. Alles andere ist IMO geeignet, die Security auszuhebeln. Wenn im Gästenetz ein spezifisches Device gebraucht wird, wird das dort (notfalls temporär) eingerichtet, fertig. Gerade mit Apple ist das ja dann auch nicht schwierig. Wird das ins Gästenetz gestöpselt, funktioniert ja auch das mDNS sogleich.
Viele Grüße, commodity
Aber braucht man dafür unbedingt (netzübergreifend) mDNS? - Darum geht es.Wenn ich einen Drucker netzübergreifend anbinden muss, kann ich das ja auch konventionell über die IP-Adresse erledigen. Vielleicht nicht so komfortabel, wie der Apple-User das gewohnt ist, aber Komfort und Sicherheit sind nicht immer kompatibel.
Für mich ist ein Gästenetz ein Gästenetz. Dort gibt es keine Zugriffe nach innen. Alles andere ist IMO geeignet, die Security auszuhebeln. Wenn im Gästenetz ein spezifisches Device gebraucht wird, wird das dort (notfalls temporär) eingerichtet, fertig. Gerade mit Apple ist das ja dann auch nicht schwierig. Wird das ins Gästenetz gestöpselt, funktioniert ja auch das mDNS sogleich.
Viele Grüße, commodity
Hallo @commodity und @sk,
danke für eure ausführlichen und konstruktiven Beiträge!
@commodity um das Thema mit dem Gäste-WLAN direkt Mal etwas zu schlichten...
Die Netze aus meinem Beitrag waren fiktiv gewählt. In "echt" sind es andere und sogar auch mehr WLANs, sowie Netze mit Apple-Geräten. Ich habe sie so gewählt, damit es für euch überschaubarer ist und wollte eigentlich nur mein gewünschtes Ziel in den Forderungrund stellen, nicht die Netze als solches.
Um dich aber zu Bekräftigen: Unser "echtes" Gastnetz hat keinen Zugriff nach innen!
Da bin ich derselben Meinung wie du. Dennoch hat @sk völlig Recht, dass es heutzutage valdige und verbreitete Anforderungen sind verschiedene Dienste dort zur Verfügung zu stellen.
Was unternimmt man denn sonst, wenn ein Gast sein iPad an dem Bildschirm eines Besprechungsraums spiegeln möchte?
Wir nutzen im Unternehmen fast ausschließlich Apple-Geräte. Es sind allerdings nicht alles "originale" Apple TVs oder AirPlay-Geräte, da wir unter anderem Barco-ClickShare Produkte mit intergrierten Apple-Diensten im Einsatz haben. Die Bluetooth-Lösung ist für uns daher nicht geeignet.
Auch das Adhoc-WLAN setzen wir nicht ein, da wir WIPS nutzen. WLAN daher nur "aus einer Hand".
@sk nein wir nutzen keine Forti Produkte, sondern die APs eines anderen Firewall-Herstellers.
Wir haben prinzipiell dieselbe Thematik, wie du es von Meru schilderst. Unser Vorgängermodell der APs unterstütze das Bonjour-Gateway, die neuen APs haben das "Feature" plötzlich nicht mehr enthalten. Ich habe dazu mit dem Hersteller gesprochen und er konnte es auch begründen. Laut ihm wird das Feature auch zurückkommen. Die Frage war nur wann...
Daher wollte ich kurzerhand die Zeit mit Avahi-Servern "überbrücken". Sie tuen auch ihren Dienst.
Die einzige Frage, die sich mir stellte: Kann ich mit dem Avahi-Server den mDNS-Traffic irgendwie regelmentieren?
Das scheint nicht der Fall zu sein.
Daher werde ich für meine Umgebung, sofern es funktioniert, vier Avahi Server einrichten oder ich schaue mir die Lösung von @10138557388 an. Ob sich die Apple Geräte in den Geräte-Netzen untereinander sehen, ist mir ziemlich egal. Es geht mir primär ums WLAN. WLAN X darf nur die Geräte A und B sehen. WLAN Y nur die Geräte A und C...
Natürlich wird der Zugriff dann schlussendlich via ACLs regelmentiert. Es ist daher auch eher Kosmetik.
Beim nächsten Mal werden wir die APs neu evaluieren. Für dieses Jahr war die Zeit aus verschiedenen Gründen einfach nicht da.
Wenn es nach mir geht, wird es wahrscheinlich Richtung Aruba, Ruckus oder Cisco gehen. Das werden wir aber sehen, wenn es soweit ist.
danke für eure ausführlichen und konstruktiven Beiträge!
@commodity um das Thema mit dem Gäste-WLAN direkt Mal etwas zu schlichten...
Die Netze aus meinem Beitrag waren fiktiv gewählt. In "echt" sind es andere und sogar auch mehr WLANs, sowie Netze mit Apple-Geräten. Ich habe sie so gewählt, damit es für euch überschaubarer ist und wollte eigentlich nur mein gewünschtes Ziel in den Forderungrund stellen, nicht die Netze als solches.
Um dich aber zu Bekräftigen: Unser "echtes" Gastnetz hat keinen Zugriff nach innen!
Da bin ich derselben Meinung wie du. Dennoch hat @sk völlig Recht, dass es heutzutage valdige und verbreitete Anforderungen sind verschiedene Dienste dort zur Verfügung zu stellen.
Was unternimmt man denn sonst, wenn ein Gast sein iPad an dem Bildschirm eines Besprechungsraums spiegeln möchte?
Wir nutzen im Unternehmen fast ausschließlich Apple-Geräte. Es sind allerdings nicht alles "originale" Apple TVs oder AirPlay-Geräte, da wir unter anderem Barco-ClickShare Produkte mit intergrierten Apple-Diensten im Einsatz haben. Die Bluetooth-Lösung ist für uns daher nicht geeignet.
Auch das Adhoc-WLAN setzen wir nicht ein, da wir WIPS nutzen. WLAN daher nur "aus einer Hand".
@sk nein wir nutzen keine Forti Produkte, sondern die APs eines anderen Firewall-Herstellers.
Wir haben prinzipiell dieselbe Thematik, wie du es von Meru schilderst. Unser Vorgängermodell der APs unterstütze das Bonjour-Gateway, die neuen APs haben das "Feature" plötzlich nicht mehr enthalten. Ich habe dazu mit dem Hersteller gesprochen und er konnte es auch begründen. Laut ihm wird das Feature auch zurückkommen. Die Frage war nur wann...
Daher wollte ich kurzerhand die Zeit mit Avahi-Servern "überbrücken". Sie tuen auch ihren Dienst.
Die einzige Frage, die sich mir stellte: Kann ich mit dem Avahi-Server den mDNS-Traffic irgendwie regelmentieren?
Das scheint nicht der Fall zu sein.
Daher werde ich für meine Umgebung, sofern es funktioniert, vier Avahi Server einrichten oder ich schaue mir die Lösung von @10138557388 an. Ob sich die Apple Geräte in den Geräte-Netzen untereinander sehen, ist mir ziemlich egal. Es geht mir primär ums WLAN. WLAN X darf nur die Geräte A und B sehen. WLAN Y nur die Geräte A und C...
Natürlich wird der Zugriff dann schlussendlich via ACLs regelmentiert. Es ist daher auch eher Kosmetik.
Beim nächsten Mal werden wir die APs neu evaluieren. Für dieses Jahr war die Zeit aus verschiedenen Gründen einfach nicht da.
Wenn es nach mir geht, wird es wahrscheinlich Richtung Aruba, Ruckus oder Cisco gehen. Das werden wir aber sehen, wenn es soweit ist.
Was unternimmt man denn sonst, wenn ein Gast sein iPad an dem Bildschirm eines Besprechungsraums spiegeln möchte?
Dafür würde ich dem Gast keinesfalls Zugriff auf ein internes Netz geben. Ein (Netz-)Bildschirm, der von Gästen genutzt wird gehört für mich ins Gästenetz. Notfalls hat man eben einen Bildschirm mehr. Ist doch ganz im Sinne der Apple-Produktstrategie Auch käme eine Art DMZ dafür in Betracht, die von den (vermeintlich notwendiger Weise) zugreifenden Netzen erreicht werden kann - aber selbst nichts erreicht. Wird mit mDNS aber wohl auch nichts werden.
Viele Grüße, commodity
