Ein Problem mit Windows und SMB in verschiedenen Subnetzen

[tbelau666]

Hallo!

Na mal sehen... Ich habe zwei Subnetze, 192.168.0 und 192.168.13. Das 0er Netzwerk sammelt alle drahtgebundenen, nicht-IoT-Geräte. Im 13er Netz sind diverse Server - zentrale Dienste. So halt auch ein Samba-Server. Damit der von Windows erkannt werden kann, läuft da gershnik/wsddn drauf. Funktioniert auch gut. Im 0er Netz...

Zwischen den beiden Subnetzen hängt ne als FW ausgemusterte USG PRO 4 als reiner Multicast-Router. Die konfiguriere ich per Hand, aber das ist ne andere Geschichte. Da läuft PIMD drauf. Es gibt ne DNAT-Regel für die TCP-Verbindung zu Port 5357 - ne Rück-Regel kann man sich wg. conntrack sparen - und eine für SNAT, damit die Pakete vom Port UDP/3702 korrekt ankommen. Es meldet sich immer das Router-Interface mit seiner IP. Wie das sein soll.

Auf dem Samba-Server im 13er Netz hab ich mit policy routing (UDP/3702 und TCP/5357) dafür gesorgt, daß der WSD-Traffic - und nur der - durch besagten Multicast-Router läuft.

Auf meinem "Spielrechner" hab ich ein Script, daß per WSD alle Geräte abfragt. Funktioniert. Es werden die diversen Windows-Rechner und auch der Samba-Server gelistet. Der Traffic sieht ok aus, paßt alles soweit. Nur sobald ich mit nem Windows-Rechner nachsehen will, sehe ich nichts.

tcpdump "sagt", daß der Traffic zwischen Script und Samba praktisch identisch ist mit dem zwischen Windows und Samba. Hello auf 239.255.255.250, Antwort vom Samba-Server, nochmal nachfragen und TCP aufmachen. Letzteres tut aber Windows nicht. Dafür kommen noch zig Anfragen an nmbd (sprich NetBIOS), die aber auch zu keinem Ergebnis führen. nmblookup mit Linux-Tools geht prima.

Vllt. hat ja jemand nen Tip. Ich bin da jetzt etwas ratlos.

Bis denn dann
Thomas

 

[the other]

Moinsen,
nur mal kurz geraten: funkt da irgendwie die Windows Firewall noch zwischen? Bin kein Windows Mensch, aber lese immer wieder, dass am Ende ja auch daran oft der Grund des Scheiterns begründet sei. Und da dein SMB Server in einem anderen Netzwerk ist...kann es ja durchaus sein, dass das Defender Ding da blockt. Mal geschaut? Ggf Firewall kurz geöffnet?
Tauchen die Probleme "nur" auf, wenn du es laufen lässt wie oben beschrieben von dir? Gelingt ein manueller direkter Zugriff auf den SMB Server am fraglichen Windows client?

 

[tbelau666]

Manuell geht das alles. In der Leiste oben die Adresse rein (DNS geht auch) und schon geht es los. Wie gesagt funktioniert das auch wenn ich den wsddn im selben Netz starte. Dann brauche ich oben nichts eintragen. Nur halt nicht durch den Router.

Das mit der Defender-FW hab ich noch nicht durchdacht. Ich weiß aber, das die im Windows ne ziemlich genaue Netzwerk-Aufklärung haben. In Win7 hatte ich mal in der Netzwerkumgebung die komplette Verkabelung incl. der dumb switches. Wie auch immer die das machen...

Ich könnte natürlich den Samba-Server in das lokale Netz mit rein legen. Ich muß ihm nur ein weiteres Interface geben (ist ne VM), aber dann lerne ich nichts ;-)

 

[tbelau666]

Ach so... extra Router. Ich hab natürlich noch ne OPNsense FW laufen. Die wollte ich aber mit dem Multicast-Kram nicht belasten und PIMD geht da drauf nicht. Mit der Hand-konfigurierten USG kann man alles Mögliche machen - auch die ehem. WAN-Interfaces bonden - und hat dann ne gute Bandbreite extra. 2GB/s rein und 2GB/s auf drei Netze verteilt ("Gleichzeitigkeitsfaktor") wieder raus. Naja, wenn die das bringt. Hab noch keinen Last-Test, fummele ja noch.

 

[the other]

Moinsen,
und wo / wie ist die opnSense da mit drin?
Läuft dein Verkehr zwischen PC und SMB Server auch durch die opnsense? Da den Zugriff auch erlaubt?

Also: am PC sitzend und den SMB Server erreichen geht, per script dagegen keine Verbindung? (sorry, hab deinen Aufbau noch nicht verinnerlicht, zu komplex für meinen Feierabend )

 

[tbelau666]

Das mit der sense ist ne etwas längere Geschichte... Ich hatte zur USG wie die meisten nen Controller. Irgendwann hab ich nen "Anfall" bekommen und mal geguckt, welche Verbindungen der so raus macht. Ohne Ende in Ubiquitis Cloud... Hab ich abgedreht und wußte, was da rüber geht... SÄMTLICHE Statistiken. Angefangen bei der Latenz und aufgehört beim Netflow. War bei älteren Versionen noch nicht. Verschiedenes wie Bonding oder vernünftige OpenVPN-Einstellungen funktionierte mit dem allgegenwärtigen Controller auch nicht. Jedenfalls nicht ohne JSON-Tricks. Im Allg. wurde die auch zu langsam für den allg. Gebrauch. In der Zwischenzeit hatte ich mir nen Server gekauft. Also hab ich die USG gegen OPNsense eingetauscht. Mehr "Bums" und ne bessere Netz-Anbindung. Dann lag die USG erstmal rum.

Jetzt hatte ich mal wieder ein bischen Muße und wollte mich mit dem Windows-Kram genauer befassen. IGMPProxy funktioniert auf der sense nicht und PIMD gibt es nicht. Grübel... Die USG basiert auf VyOS 1.1. Also Debian 7. Damit kann man was anfangen... PIMD - man kann auch Pakete von Debian 8 installieren - kannte ich schon, wenn man den Ubiquiti-Kram peu a peu weg schmeißt (wer braucht das ohne Controller?) und nur auf VyOS setzt, hat man wieder nen brauchbaren Router. In der CLI geht bonding und für "nur" multicast streams ist das Teil völlig in Ordnung. Irgend ein ARP-daemon geht nach wie vor nicht...

Jedenfalls ist es so, daß die sense alles macht. IPSec in DMZ-Server, routing zwischen den internen Netzen, etc. Alles was die USG vorher gemacht hat.

Die USG bearbeitet tatsächlich nur die multicast-Sachen (224.0.0.0/4) und dazu im Moment erstmal die beiden WSD ports.

MEIN Rechner läuft unter Linux mit eben dem Abfrage-Script. Alle anderen PCs im Haus laufen mit Windows. Die sind alle im gleichen Netz. Das 13er ist mein Service-Netz. DNS, TvHeadend, Nextcloud, Minecraft und verschiedene andere Sachen. Von den Servern da drin will ich möglichst keinen in den Benutzer-Netzen sehen. Auf der sense läuft IPS. Das würde ausgehebelt.