20.10.2022

3069

Netzwerkerkennung VLAN übergreifend - Mikrotik

Hallo ich habe mal eine Frage.
In der Vergangenheit bin ich immer wieder auf das Problem gestoßen das meine Geräte aus anderen VLANs nicht vom Handy oder PC erkannt werden.

z.b. kann ich von meinem Client VLAN nicht die SMB Freigaben im Server VLAN sehen.

Das hatte mich eigentlich auch bis jezt nicht wirklich gestört da man ja einfach nur die IP-Adresse eingeben muss und fertig.

Jetzt sind aber 2 sachen aufgetreten wo ich um die netzwerkerkennung nich drum herum komme.

Szenario 1:
Iphone App "Apple Homekit"
mein Handy befindet sich im VLAN 10 -> 192.168.10.0/26
die Apple Homekit bridge läuft auf meinem Automationsserver im VLAN40 ->192.168.40.0/26

könnte man in der App die IP Adresse eintragen würde es funktionieren. aber leider sucht die app ihren server selber.

Szenario 2:
mein Laptop befindet wieder im VLAN10
meine ESP32 Boards sind im VLAN30 -> 192.168.30.0/24
möchte ich jetzt per wlan ein programm uploaden habe ich wieder das problem das mein laptop die geräte nicht finden kann. Eine möglichkeit der Addresseingabe ist in dem Programm auch nicht vorhanden.

Ich vermute mal die Netzwerkerkennung funktioniert so das jede IP im Subnetz (im bsp Homekit 10.1 - 10.62) auf dem passenden port angepingt wird und da der server ja in einem anderen netzwerk liegt nicht angepingt wird und somit nicht gefunden werden kann.

jetzt hatte ich gedacht das ich das Problem in den griff bekomme wenn ich in der Firewall meines Mikrotik routers eine NAT regel anlege die auf den Server zeigt.

Ich hatte eigentlich gedacht wenn ich jetzt die IP Adresse 192.168.10.56 aufrufe öffnet sich die Seite des servers der eigentlich unter 192.168.40.10 erreichbar ist.

Das funktioniert auch aber auch nicht.
ich erkläre mir das so:
da die IP adresse 10.56 ja im selben subnet liegt muss nicht geroutet werden und somit geht das packet auch nicht über den router sondern direkt. Da das packet nicht über den Router geht kann die nat regel nicht greifen. Ändere ich die IP adresse von 10.56 auf 10.71 (außerhalb des Subnetz der DHCP clients) kann ich die seite aufrufen da das packet den Router passieren muss.

Jetzt weiß ich leider nicht mehr weiter wie ich das sonst hinbekommen könnte.

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 4342242983

Url: https://administrator.de/contentid/4342242983

Ausgedruckt am: 24.11.2024 um 18:11 Uhr

13 Kommentare

Neuester Kommentar

kann ich von meinem Client VLAN nicht die SMB Freigaben im Server VLAN sehen.

Das ist generell bei gerouteten Netzwerken auch völlig normal. Bekanntlich basiert das Bekanntmachen von SMB/CIFS Shares in einem Netz ohne zentralen DNS Server auf Broadcasts.
Wie du als guter Netzwerker ja auch selber weisst werden Broadcasts prinzipbedingt in gerouteten IP Netzen nicht über die Routergrenzen geforwardet. Ein Grund auch warum man Segmentiert und die Broadcast Belastung in L2 Segmenten niedrig hält.
Folglich "sieht" man VLAN übergreifend an Clients auch keine freigegebenen Shares.
Man kann aber solche Server mit ihren Namen auch lokal in die hosts oder lmhosts Datei statisch eintragen um zumindestens die Share Namen weiterzuverwenden. Siehe dazu auch hier.

Ein weiterer Punkt ist mDNS (Bonjour) was sehr wahrscheinlich deine Apple Komponenten verwenden. Auch damit machen sich Endgeräte automatisch in L2 Segmenten bekannt.
mDNS basiert aber im Gegensatz zu den obigen SMB/CIFS Shares nicht auf Broadcasts sondern auf Multicasts. Speziell einer Link Local Multicast Adresse 224.0.0.251. Diese hat Protokoll bedingt einen festen TTL von 1 und ist damit nicht routebar. Auch nicht über das bordeigenen PIM Multicast Routing weil die TTL 1 ein Forwarding verhindert.

Alles simple Binsenweisheiten in einem Netzwerk. Leide rmachst du sehr wenig Angaben zu den verwendeten Protokolle so das man hier kristallkugeln muss.
Mit einem simplen [ Wireshark] Trace könntest du schnell und wasserdicht erkennen WIE sich deine Endgeräte bekannt machen und einfach und schnell eine Lösung implementieren.
Für mDNS macht man das mit einem Proxy der ggf. schon in deinem Router oder Accesspoint enthalten ist. Ansonsten erledigt das ein 10 Euro Raspberry Pi.
Netzwerk Management Server mit Raspberry Pi
Bonjour an Subnetz weiterleiten

Stichwort IGMP Proxy und MDNS (häufig genutzt von Apple und anderen Geräten), sind beides nicht routbare Protokolle die ihre Subnetzgrenzen per Default nicht verlassen und auf Broadcasts/MultiCasts basieren.
IGMP Proxy für uPnP hat Mikrotik an Board, mDNS hat er nicht da musst du bspw. einen Raspi oder ne VM anklemmen der mDNS zwischen den VLANs vermittelt (avahi)

Vielleicht helfen Dir die Firewall-Regeln aus diesem Beitrag weiter:

Apple AirPrint über VLANs

die Firewall-Regeln aus diesem Beitrag weitee

Wohl eher nicht. Erster Satz im verlinkten Beitrag: "Paket avahi hinzufügen"

Dann bleibt ihm nur die Variante auf eine vernünftige Firewall umzusteigen :-P

Mit einer Firewall an sich hat sein Anliegen ja nichts zu tun. Es ist das Propagieren von SMB/CIFS Namen per Broadcast (Stickwort Helper Adressen) oder dessen statische Konfig.
mDNS/Bonjour ist wieder eine gesonderte Baustelle für Multicasts. Der von dir gepostete Link nutzt den mDNS Daemon (AVAHI) dafür. Ob man den auf einem Router, Firewall oder einem 10€ Raspberry Pi laufen lässt ist dabei unerheblich für eine Lösung. 😉
https://forum.mikrotik.com/viewtopic.php?t=174354

Hier steht's detailliert wie das mit dem Mikrotik für mDNS und avahi gemacht wird
Step by Step: Mikrotik mDNS (Bonjour) reflector between different VLANs with avahi daemon and a linux machine on a tagged trunk port

super. vielen Dank.
Ich habe jetzt avahi auf einem raspberry installiert.

Danach habe ich im Switch einen Trunk Port erstellt und meine 4 VLANS in denen die verschiedenen Geräte sitzen eingefügt.

Mein Mikrotik hat dem raspi dann in den VLANs jeweis eine IP vergeben.

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.30.15  netmask 255.255.255.192  broadcast 192.168.30.63
        inet6 fe80::8560:cc50:28b6:c1d  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:82:b2:78  txqueuelen 1000  (Ethernet)
        RX packets 21246  bytes 3920419 (3.7 MiB)
        RX errors 2  dropped 1  overruns 0  frame 2
        TX packets 706  bytes 108334 (105.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0.10: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.10.26  netmask 255.255.255.192  broadcast 192.168.10.63
        inet6 fe80::4117:e04:7e69:fa4  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:82:b2:78  txqueuelen 1000  (Ethernet)
        RX packets 4856  bytes 818708 (799.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 58  bytes 8156 (7.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0.30: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.30.15  netmask 255.255.255.192  broadcast 192.168.30.63
        inet6 fe80::dbaa:1fdb:32ee:54b5  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:82:b2:78  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 35  bytes 5364 (5.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0.40: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.40.13  netmask 255.255.255.192  broadcast 192.168.40.63
        inet6 fe80::3d60:6fd6:46c2:5443  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:82:b2:78  txqueuelen 1000  (Ethernet)
        RX packets 8786  bytes 981762 (958.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 70  bytes 12580 (12.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0.50: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.50.49  netmask 255.255.255.0  broadcast 192.168.50.255
        inet6 fe80::adf5:bbb1:302e:6c7b  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:82:b2:78  txqueuelen 1000  (Ethernet)
        RX packets 4303  bytes 1045897 (1021.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 393  bytes 55386 (54.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

danach habe ich dann auf dem raspi die Datei /etc/avahi/avahi-daemon.conf angepasst.
zuerst habe ich nur

#enable-reflector=no

enable-reflector=yes

gestellt und dann habe ich noch diese beiden Zeilen abgeändert

use-ipv6=no
#allow-interfaces=eth0,eth0.10,eth0.40,eth0.50

danach konnt ich mir mit avahi-browse -alvt alle geräte anzeigen lassen.

Server version: avahi 0.8; Host name: usbipHost.local
E Ifce Prot Name                                          Type                 Domain
+ eth0.50 IPv6 Tvserver-V2                                   Device Info          local
+ eth0.50 IPv4 Tvserver-V2                                   Device Info          local
+ eth0.40 IPv6 Tvserver-V2                                   Device Info          local
+ eth0.40 IPv4 Tvserver-V2                                   Device Info          local
+ eth0.10 IPv4 LIBREELEC-WOMO                                Device Info          local
+ eth0.50 IPv6 Tvserver-V2                                   Microsoft Windows Network local
+ eth0.50 IPv4 Tvserver-V2                                   Microsoft Windows Network local
+ eth0.40 IPv6 Tvserver-V2                                   Microsoft Windows Network local
+ eth0.40 IPv4 Tvserver-V2                                   Microsoft Windows Network local
+ eth0.10 IPv4 LIBREELEC-WOMO                                Microsoft Windows Network local
+ eth0.50 IPv6 Tvserver-V2                                   SFTP File Transfer   local
+ eth0.50 IPv4 Tvserver-V2                                   SFTP File Transfer   local
+ eth0.40 IPv6 Tvserver-V2                                   SFTP File Transfer   local
+ eth0.40 IPv4 Tvserver-V2                                   SFTP File Transfer   local
+ eth0.10 IPv4 LibreELEC-Womo                                SFTP File Transfer   local
+ eth0.50 IPv6 Tvheadend                                     _htsp._tcp           local
+ eth0.50 IPv4 Tvheadend                                     _htsp._tcp           local
+ eth0.40 IPv6 Tvheadend                                     _htsp._tcp           local
+ eth0.40 IPv4 Tvheadend                                     _htsp._tcp           local
+ eth0.50 IPv6 Tvheadend                                     Web Site             local
+ eth0.50 IPv4 Tvheadend                                     Web Site             local
+ eth0.40 IPv6 Tvheadend                                     Web Site             local
+ eth0.40 IPv4 Tvheadend                                     Web Site             local
+ eth0.10 IPv4 Samsung C48x Series (SEC8425192FEE35)         Web Site             local
+  wlan0 IPv4 shelly1pm-98CDAC1EE2D2                        Web Site             local
+  wlan0 IPv4 shelly1pm-98CDAC1EDE7F                        Web Site             local
+  wlan0 IPv4 shelly1-E89F6D85E838                          Web Site             local
+  wlan0 IPv4 ShellyPro4PM-083AF27B82A0                     Web Site             local
+  wlan0 IPv4 shellyrgbw2-D8CE3F                            Web Site             local
+  wlan0 IPv4 shelly1-E89F6D862516                          Web Site             local
+  wlan0 IPv4 ShellyPlus1-7C87CE731544                      Web Site             local
+  wlan0 IPv4 shellyrgbw2-A803AB                            Web Site             local
+   eth0 IPv4 shellyrgbw2-A803AB                            Web Site             local
+   eth0 IPv4 shelly1pm-98CDAC1EE2D2                        Web Site             local
+   eth0 IPv4 shelly1pm-98CDAC1EDE7F                        Web Site             local
+   eth0 IPv4 shelly1-E89F6D85E838                          Web Site             local
+   eth0 IPv4 ShellyPro4PM-083AF27B82A0                     Web Site             local
+   eth0 IPv4 shellyrgbw2-D8CE3F                            Web Site             local
+   eth0 IPv4 shelly1-E89F6D862516                          Web Site             local
+   eth0 IPv4 ShellyPlus1-7C87CE731544                      Web Site             local
+ eth0.50 IPv6 Tvserver-V2                                   SSH Remote Terminal  local
+ eth0.50 IPv4 Tvserver-V2                                   SSH Remote Terminal  local
+ eth0.40 IPv6 Tvserver-V2                                   SSH Remote Terminal  local
+ eth0.40 IPv4 Tvserver-V2                                   SSH Remote Terminal  local
+ eth0.10 IPv4 LibreELEC-Womo                                SSH Remote Terminal  local
+ eth0.50 IPv4 IOBroker B0BB                                 _hap._tcp            local
+ eth0.10 IPv4 root@LibreELEC-Womo                           PulseAudio Sound Server local
+ eth0.10 IPv4 root@LibreELEC-Womo: Dummy Output             PulseAudio Sound Sink local
+ eth0.10 IPv4 Kodi (LibreELEC-Womo)                         _xbmc-events._udp    local
+ eth0.10 IPv4 000102030405@Kodi (LibreELEC-Womo)            AirTunes Remote Audio local
+ eth0.10 IPv4 Samsung C48x Series (SEC8425192FEE35)         _privet._tcp         local
+ eth0.10 IPv4 Samsung C48x Series (SEC8425192FEE35)         _scanner._tcp        local
+ eth0.10 IPv4 Samsung C48x Series (SEC8425192FEE35)         UNIX Printer         local
+ eth0.10 IPv4 Samsung C48x Series (SEC8425192FEE35)         PDL Printer          local
+ eth0.10 IPv4 Samsung C48x Series (SEC8425192FEE35)         Internet Printer     local
+  wlan0 IPv4 ESP32-4Kanal-RGBW                             _arduino._tcp        local
+   eth0 IPv4 ESP32-4Kanal-RGBW                             _arduino._tcp        local
+  wlan0 IPv4 shellypro4pm-083af27b82a0                     _shelly._tcp         local
+  wlan0 IPv4 shellyplus1-7c87ce731544                      _shelly._tcp         local
+   eth0 IPv4 shellypro4pm-083af27b82a0                     _shelly._tcp         local
+   eth0 IPv4 shellyplus1-7c87ce731544                      _shelly._tcp         local
: Cache exhausted
: All for now

eigentlich müssten jetzt alle Geräte sichtbar werden oder ?

ich hatte dann auf dem Linux Rechner auf dem der IObroker läuft die Geräte auflisten lassen aber da taucht immer noch nur der IO broker auf und mehr nicht. Mit meinem Handy kann ich leider auch nix finden aber das liegt bestimmt daran das ich nicht zuhause bin und nur über VPN verbunden bin. Aber der Linux Server müsste mir doch eig mehr anzeigen.

root@Tvserver-V2:~# avahi-browse -at
+ shim-br0 IPv4 IOBroker B0BB                                 _hap._tcp            local

Der Linux rechner befindet sich im VLAN50 und kann das Raspi erreichen.

kommando zurück.
ich hab was wichtiges vergessen.

man sollte das "#" vor der zeile wegnehmen. ;)

dummer Fehler.

jezt kann mein Linux Rechner die geräte die der Raspi teilt anzeigen.

wenn ich heute Abend zuhause bin wirds dann hoffentlich auch mit dem Handy klappen.

Wenns das denn nun war bitte dann auch nicht vergessen deinen Thread hier als erledigt zu schliessen!

Hier findet ihr auch eine Lösung zum mDNS Repeating direkt auf einem MIkrotik Router
Mikrotik: mDNS Repeater als Docker-Container auf dem Router (ARM,ARM64,X86)

Grüße Uwe

Da mein Mikrotik Router leider kein Docker kann habe ich das auf meinem Unraid Server umgesetzt.
Ich bin so vorgegangen:

Man braucht in jedem Vlan in die mDNS repeatet werden soll eine freie IP Adresse.

1. Vlan Interfaces anlegen (wenn nicht schon vorhanden): Das geht im menü Settings->Network Settings
2. Docker Container anlegen: Docker -> (und ganz unten) Add Container
3. Container konfigurieren:

Name: Avahi
Repository: flungo/avahi
Post Arguments: was hier rein kommt beschreibe ich weiter unten
Network Type: br0
Fixed IP address (optional): 192.168.50.40 oder eine die Frei ist
Neue Variable hinzufügen:

Name : REFLECTOR_ENABLE_REFLECTOR
Key: REFLECTOR_ENABLE_REFLECTOR
Value: yes
4. Container erzeugen
Ferig.

Bei Post Arguments müssen die Interfaces eingetragen werden die Verbunden werden sollen und eine Freie IP in diesem VLAN.
Hier ein Bsp:

;docker network connect  br0.10 Avahi --ip 192.168.10.40;docker network connect br0.30 Avahi --ip 192.168.30.40;

Sollte der Container nicht Avahi heißen musss der Name geändert werden. Die ";" am Anfang, Ende und zwischen den Befehlen darf man nicht Vergessen. Den Fehler habe ich am Angang gemacht.

Vorher hatte ich versucht unter UNRAID den Reflektor zu aktivieren da UNRAID selbst auch Avahi installiert hat. Aber leider wollte das wieso auch immer nicht funktionieren. Deswegen der Umweg über Docker.

So sollten die Einstellungen aussehen: