Samba über eine NAT-Firewall zum FileServer

[Roemer2201]

Hallo,

Ich habe hier ein Netz mit ein paar Clients (WinXP SP3 32bit), die über NAT (in einer Firewall/Gateway) in ein anderes Netz gehen und dort auf eine Freigabe (Samba) zugreifen. Der Samba-Server ist sozusagen das "Frontend" eines SAN, er läuft auf einem UNIX-System. Näheres zur Version kann ich nicht sagen, da das System von mir nicht betreut wird.

Dabei kam es immer zu Verbindungsabbrüchen bei der Datenübertragung mit der Fehlermeldung "Die Datei %Dateiname% konnte nicht kopiert werden, der angegebene Netzwerkname ist nicht mehr verfügbar".

Nach einer längeren Recherche bin ich darauf gestoßen, dass Samba nicht mehrere Verbindungen von einer IP akzeptiert. Das bedeutet, dass sich die Nutzer immer gegenseitig durch das NAT in der Firewall rausgeworfen haben, sobald ein anderer Client die Verbindung mit der Freigabe aufgenommen hat.

Um das Ganz zu Umgehen, habe ich folgenden Artikel zu Rate gezogen:

You cannot make more than one client connection over a NAT device

Wenn ich das richtig verstanden habe, müsste es reichen, wenn in der Firewall Port 445/TCP geblockt wird. Tut es aber nicht. Die Abbrüche treten immernoch auf.

Zusätzlich sind noch die Ports 137/UDP und 139/TCP offen.

Die Ports 137/UDP und 139/TCP in Verbindung mit dem Registry-Eintrag, der in dem KnowledgeBase Artikel scheint zu funktionieren.

Ich wollte jetzt von Euch wissen, ob es eine bessere/sauberere Lösung gibt, als überall dieses einen Registry-Key zu setzen. (Ich würde es über eine Administrative Vorlage machen)

[flashpixx]

Warum suchst Du das Problem auf MS Seiten? Das Problem ist der Samba Dämon:

Samba Server Security

Samba is able to limit the number of concurrent connections when smbd is launched as a daemon (not from inetd). The 'max smbd processes' smb.conf option allows Administrators to define the maximum number of smbd processes running at any given point in time. Any further attempts from clients to connect to the server will be rejected.

Ändere die Konfiguration Deines Samba Dienstes. Wofür Du ein NAT machst ist gerade bei einer solchen Konstellation überhaupt nicht klar, hier würde ein passendes Routing reichen bzw. je nach Anbindung ein VPN.

[Roemer2201]

Hm, also das mit der Anzahl der Prozesse ist bestimmt nicht das Problem. Ich würde mal schätzen, dass ca. 500-1000 Leute auf diesem FileServer aktiv sind.

Es lässt sich ganz klar reproduzieren, dass nur eine Verbindung aus meinem Netz von dem FileServer akzeptiert wird.

Ich muss auch meinen ersten Post korrigieren, die Abbrüche treten auch bei blockiertem Port 445 TCP und freigeschalteten Port 137 UDP und 139 TCP auf.

Das das Problem auf dem FileServer liegt ist noch nicht so ganz klar. Die Firewall, die mein Netz terminiert und zum Samba-Server hin NAT'et könnte auch die Ursache sein. Ich habe auch noch ein zweites Netz (anderes VLAN), das über die gleiche Firewall auf den gleichen Samba-Server zugreift. Dort funktioniert alles ohne Probleme. Ich habe die Firewall für das "Problem-Netz" schon einmal genau so eingestellt wie das funktionierende, die Abbrüche traten trotzdem auf.

EDIT: Würde ein kleiner Netzplan helfen, das Problem zu verdeutlichen?

[Roemer2201]

Ich habe mich noch etwas weiter zu diesem Problem belesen und auf dieser Seite wird der Effekt sehr genau beschrieben:

Analysis of a networking problem: The case of the mysterious SMB connection resets (or “How to not design a network protocol”) Nynaeve

In diesem Artikel wird aber das Problem nur für Windows-Samba betrachtet.

Ich hatte jetzt die Idee, auf dem Samba-Server von uns zu kontrollieren, ob dort in der smb.cof der Parameter "reset on zero vc = yes" eingetragen ist. Das würde das jetzige Verhalten erklären. (Ich hab keine Zugriff darauf, muss morgen mal ne Runde telefonieren)

Falls dem wirklich so ist, würde ich gern den Parameter auf "no" setzen.

Eigentlich ist es mir zu heiß so einen Parameter im laufenden Betrieb zu ändern. Aber ich sehe keine andere Option.

[flashpixx]

Du könntest ja das Problem einfach mal nachbilden, ist natürlich schon etwas Aufwand. Der Artikel ist aber an sich schon schlüssig. Ich würde vielleicht direkt auf der Samba Mailingliste nachfragen. Was natürlich auch sein könnte, dass das Problem versionsbezogen ist, d.h. evtl auf eine neuere Samba Version migrieren

Auf jeden Fall solltest Du die Mitarbeiter vorwarnen :-P

[Roemer2201]

Das Problem ist nun schon längere Zeit gelöst, deswegen hier die Lösung:

In die Firewall/NAT-Gerät wurde eine weitere Regel hinzugefügt:

nonat <source> <destination>

Was dieser Befehl bewirkt, kann sich sicher jeder denken. Das ist in unserem Fall nicht weiter kritisch.