5
Mikrotik - mDNS Repeater erstmalig in der aktuellen Beta von RouterOS
Servus Kollegen.
Mikrotik hatte es vor ca. 1 Jahr angekündigt:
Nun wurde das Kind geboren (RouterOS 7.16 beta3)
https://mikrotik.com/download/changelogs#tab-testing
Zur Zeit ist dieser erst einmal nur über die Konsole nutzbar mit folgender Anweisung (Interfaces sind natürlich anzupassen)
Bitte die Firewall nicht vergessen! Diese muss mDNS Traffic natürlich auf allen beteiligten Interfaces in der Input-Chain zulassen damit der mDNS Proxy diesen Traffic auch sehen und weiterleiten kann:
In einem ersten Test funktioniert das Repeating der mDNS Multicasts zwischen den angegebenen Interfaces einwandfrei. Damit wird der Docker-Container oder zusätzliche Devices für das Repeating endlich überflüssig.
Gruß @colinardo
Mikrotik hatte es vor ca. 1 Jahr angekündigt:
(normis) MikroTik Support : MikroTik is working on mDNS repeater, but that will come together with a global DNS overhaul and it will be an improvement in all areas, not just this one. This is also why it takes some time to make.
Nun wurde das Kind geboren (RouterOS 7.16 beta3)
https://mikrotik.com/download/changelogs#tab-testing
What's new in 7.16beta3 (2024-Jun-27 08:33):
*) dns - added support for mDNS proxy (CLI only);
*) dns - added support for mDNS proxy (CLI only);
Zur Zeit ist dieser erst einmal nur über die Konsole nutzbar mit folgender Anweisung (Interfaces sind natürlich anzupassen)
/ip dns set mdns-repeat-ifaces=vlan100,vlan200
Bitte die Firewall nicht vergessen! Diese muss mDNS Traffic natürlich auf allen beteiligten Interfaces in der Input-Chain zulassen damit der mDNS Proxy diesen Traffic auch sehen und weiterleiten kann:
/ip firewall filter
add action=accept chain=input dst-address=224.0.0.251 dst-port=5353 in-interface=vlan100 protocol=udp place-before=0
add action=accept chain=input dst-address=224.0.0.251 dst-port=5353 in-interface=vlan200 protocol=udp place-before=0In einem ersten Test funktioniert das Repeating der mDNS Multicasts zwischen den angegebenen Interfaces einwandfrei. Damit wird der Docker-Container oder zusätzliche Devices für das Repeating endlich überflüssig.
Gruß @colinardo
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: 3936888204
Url: https://administrator.de/contentid/3936888204
Ausgedruckt am: 18.12.2024 um 23:12 Uhr
5 Kommentare
Neuester Kommentar
Goil 
1
super!
Die 7.16 vom RouterOS ist endlich stable und dann hab ich das Feature gleich ausprobiert.
Funktioniert super ... meistens ...
Ich hab ne neue Mediaserver-Software (MinimServer), mit der das nicht funktioniert.
Hab schon jede Menge tcpdumps und Paket-Sniffer-Mitschnitte untersucht - bisher fehlt mir aber die zündende Idee.
Was mir schon aufgefallen ist: bei der Firewall spielt u.U. auch der Port 1900 eine Rolle und - je nach Software - braucht man die eine oder andere FORWARD-Regel.
Außerdem scheint da IGMP im Spiel zu sein, also hab ich mal einen PIM eingerichtet.
Hilft aber alles nix. Man sieht, wie die Geräte (Client und Server) der Multicast-Gruppe beitreten ... und dann kommt nichts mehr. Hat jemand ne Idee, wie ich da rangehen könnte?
Hab das Szenario auch schon mal getestet mit Server und Client im selben Subnetz, da funktioniert das allerliebst.
Die 7.16 vom RouterOS ist endlich stable und dann hab ich das Feature gleich ausprobiert.
Funktioniert super ... meistens ...
Ich hab ne neue Mediaserver-Software (MinimServer), mit der das nicht funktioniert.
Hab schon jede Menge tcpdumps und Paket-Sniffer-Mitschnitte untersucht - bisher fehlt mir aber die zündende Idee.
Was mir schon aufgefallen ist: bei der Firewall spielt u.U. auch der Port 1900 eine Rolle und - je nach Software - braucht man die eine oder andere FORWARD-Regel.
Außerdem scheint da IGMP im Spiel zu sein, also hab ich mal einen PIM eingerichtet.
Hilft aber alles nix. Man sieht, wie die Geräte (Client und Server) der Multicast-Gruppe beitreten ... und dann kommt nichts mehr. Hat jemand ne Idee, wie ich da rangehen könnte?
Hab das Szenario auch schon mal getestet mit Server und Client im selben Subnetz, da funktioniert das allerliebst.
Servus @rapkin.
Port UDP1900 Gehört zu SSDP und wird i.d.R. bei der uPnP Service-Discovery auf die Multicast Adresse 239.255.255.250 verwendet, das hat nichts mit mDNS zu tun und sind zwei separate Baustellen. Hier muss dann ein IGMP Proxy oder PIM ins Spiel kommen der zwischen den Broadcast-Domains vermittelt. Vergessen darf man hier auch nicht die Firewall (IGMP INPUT und Forward-Chain) auf dem Router. Discovery ist das eine, die eigentliche Verbindung zwischen den Geräten eine andere! Des weiteren muss die TTL der IGMP Pakete per Mangel Rule erhöht werden da diese sonst mit einer TTL von 1 vom Router verworfen werden.
Da hat jedes Gerät andere Anforderungen an offene Ports, das lässt sich nur durch eingehende Analyse des Traffics dieser Devices beheben wenn man nicht alles blind freigeben will.
Gruß @colinardo
Port UDP1900 Gehört zu SSDP und wird i.d.R. bei der uPnP Service-Discovery auf die Multicast Adresse 239.255.255.250 verwendet, das hat nichts mit mDNS zu tun und sind zwei separate Baustellen. Hier muss dann ein IGMP Proxy oder PIM ins Spiel kommen der zwischen den Broadcast-Domains vermittelt. Vergessen darf man hier auch nicht die Firewall (IGMP INPUT und Forward-Chain) auf dem Router. Discovery ist das eine, die eigentliche Verbindung zwischen den Geräten eine andere! Des weiteren muss die TTL der IGMP Pakete per Mangel Rule erhöht werden da diese sonst mit einer TTL von 1 vom Router verworfen werden.
Da hat jedes Gerät andere Anforderungen an offene Ports, das lässt sich nur durch eingehende Analyse des Traffics dieser Devices beheben wenn man nicht alles blind freigeben will.
Gruß @colinardo
1
Hi @colinardo,
danke für die zahlreichen und hilfreichen Tipps!
Bei den IGMP Paketen wäre ich - naiver Weise - davon ausgegangen, dass das der PIM regelt. Also natürlich nicht die Firewall Rules, aber die Geschichte mit der TTL. Naja ... wieder mal was gelernt ...
Hast Du nen Tipp, wie so ne Mangle Rule aussehen muss? Das ist absolutes Neuland für mich ...
danke für die zahlreichen und hilfreichen Tipps!
Bei den IGMP Paketen wäre ich - naiver Weise - davon ausgegangen, dass das der PIM regelt. Also natürlich nicht die Firewall Rules, aber die Geschichte mit der TTL. Naja ... wieder mal was gelernt ...
Hast Du nen Tipp, wie so ne Mangle Rule aussehen muss? Das ist absolutes Neuland für mich ...
Bsp.
/ip firewall mangle
add action=change-ttl chain=prerouting comment="uPnP IGMP" dst-address-type=multicast in-interface-list=LAN new-ttl=set:10 passthrough=no protocol=igmp
add action=change-ttl chain=prerouting comment="uPnP SSDP" dst-address-type=multicast dst-port=1900 in-interface-list=LAN new-ttl=set:10 passthrough=no protocol=udp 
