Hallo Ich hatte die Idee, den SMB port zu forwarden. Und zwar mache ich das so. Auf dem Client ist https://github.com/jimparis/unwebsockify drauf. Das lass ich so laufen, das es TCP traffic von port 8445 nimmt, und an meinen Server per TLS+Websocket mit HTTP Basic Auth sendet. Der sendet es weiter an meinen NAS server, und dort drauf läuft python3 websockify. Das wiederum verbindet sich auf port 445, den SMB Port. Unter Linux alles kein Problem. Ich gebe im file manager smb://127.0.0.1:8445/freigabe/ ein, und komme auf das Share. Das läuft erstaunlich gut, viel besser als das webdav zeugs das ich vorher genommen hatte. Nun dachte ich, ok, mach ich das auch auf Windows. Also unwebsockify mit pyinstaller in eine standalone exe umgewandelt, und genau wie unter linux aufgerufen. Soweit so gut, läuft, und leitet die Daten wie gewünscht weiter. Nur, darauf zuzugreifen scheint unmöglich zu sein? Andere hatten das Problem wohl auch schon, beim forwarden von SMB über SSH. \\IP:PORT\freigabe\ geht schonmal nicht, verbindet sich nicht zum port. \\IP@PORT\freigabe\ verbindet sich zum port, aber versucht WebDav statt SMB!?! Einfach port 445 statt 8445 nehmen geht nicht, den hat sich Windows / der lanmanager service, schon geschnappt. Auch auf z.B. 127.0.0.2:445 kann ich es nicht binden lassen. Forwarding per netsh portproxy ging auch nicht, wird zwar in netstat als listening angezeigt, kommt aber auch nie was an, geht wohl weiterhin an den lanmanager. Im Internet findet man dann noch 2 hacks. Eine Abhänigkeit zwischen dem lanmanager und dem port forwarding service herstellen war der erste, brachte keine Änderung. Der andere war das Windows Loopback Testinterface zu installieren, aber das Ding droppt einfach nur allen traffic, ist komplett nutzlos dafür. Und da bin ich jetzt mit meinem Latein am Ende. Ist das wirklich einfach unmöglich? Kann man bei Windows wirklich nicht einmal den SMB Port angeben?
Weil bei Windows bei Netzlaufwerken SMB einfach am besten funktioniert, in punkto Geschwindigkeit und Integration.
DPA schrieb: > Weil bei Windows bei Netzlaufwerken SMB einfach am besten > funktioniert, in punkto Geschwindigkeit und Integration. Wenn du die Freigabe zwingend als Netzlaufwerk einhängen möchtest ist direktes SMB wohl wirklich das Mittel der Wahl. Meine Lösung um von unterwegs auf den Share zu kommen ist eine zwischengeschaltete Nextcloud-Instanz. Die hat den Share als "externe Quelle" eingebunden. Bringt halt noch so schöne Sachen wie Kalender, Kontakte usw. mit.
DPA schrieb: > Weil bei Windows bei Netzlaufwerken SMB einfach am besten funktioniert, > in punkto Geschwindigkeit und Integration. Naja, ich bezweifle das SMB bei der Geschwindigkeit, im vom TE beschriebenen Szenario, wirklich am besten funktioniert und einfach ist es dabei auch nicht mehr. Umgekehrt braucht man für SFTP nur einen SFTP Share Mapper (sshfs, winsfp, sftp-drive oder irgend einen Anderen).
Tim T. schrieb: > Naja, ich bezweifle das SMB bei der Geschwindigkeit, im vom TE > beschriebenen Szenario, wirklich am besten funktioniert und einfach ist > es dabei auch nicht mehr. Microsoft verwendete dafür einstmals den Begriff CIFS = Common Internet File System, um zu suggerieren, es sei als weltweit universelles Filesystem sinnvoll einsetzbar. Als Reaktion auf Suns WebNFS mit ähnlichen Hintergedanken. In dieser Rolle angekommen sind beide Ansätze nicht, m.E. zu recht.
Ich habe selber in der Vergangenheit umfangreiche Tests von Durchsatz und Latenz von NFS (3/4), SMB (1/2/3) und SFTP gemacht. Im LAN war da die Rangfolge, sowohl unter Linux als auch Windows immer SMB > NFS > SFTP. SFTP krankte dabei vorallem an der erhöhten CPU-Last. Sobald man jedoch die Verbindung von NFS und SMB durch einen OpenSSH-Tunnel geführt hat, der zudem auch kein Gigabit mehr hatte, war der Durchsatz durch SFTP etwas höher als bei SMB und bei NFS nochmals etwas unter SMB. Danach war für mich klar, im LAN benutze ich SMB (v3) sowohl unter Windows als auch unter Linux und für Remote Sachen am besten SFTP. Wobei ich, wenn ich eh einen Tunnel habe, aus Faulheit manchmal auch da einfach SMB benutze.
Ich fand es unmöglich, mit SMB 1.0 das Lan auch nur ansatzweise auszulasten. Erst mit 2.0 war das der Fall, aber schneller als NFS ist es auch nicht. Auch mit NFS 2 war das kein Problem. Das legte SMB 1.0 bzw CIFS als Basis für Internet-Traffic nicht eben nahe. Verschlüsselung ist im Internet ohnehin Pflicht. Ob als Tunnel oder direkt.
:
Bearbeitet durch User
Da eigentlich immer alles TLS nutzt, ist das hoch optimiert, von da her will ich meinen momentanen Ansatz mit dem Websocket Tunnel und SMB schon beibehalten. Ich brauche ja nur irgend einen Weg, damit Verbindungen an port 445 bei irgend einer IP bei meinem Programm ankommen. Oder halt irgend einen weg, windows bei zu bringen, für SMB einen anderen Port zu nehmen. Das muss doch irgendwie gehen. Es kann doch nicht sein, dass das ganze an einer simplen Portnummer scheitert...
(prx) A. K. schrieb: > Microsoft verwendete dafür einstmals den Begriff CIFS = Common Internet > File System, um zu suggerieren, es sei als weltweit universelles > Filesystem sinnvoll einsetzbar. Als Reaktion auf Suns WebNFS mit > ähnlichen Hintergedanken. In dieser Rolle angekommen sind beide Ansätze > nicht, m.E. zu recht. So kann man das wohl zutreffend zusammenfassen. Beide kommen mit packet drops ähnlich schlecht klar, beide schleppen Altlasten mit sich, die sie entweder unsicher machen oder durch Ausschluss die Kompatibilität zu bestehenden Installationen zerstören. Es ist eben extrem schwierig bis unmöglich, etwas gleichzeitig performant, störsicher und sicher über ein Netz zu übertragen, welches nicht seinerseits darauf ausgelegt ist, gleichzeitig geringe Latenzen und hohe Übertragungssicherheit zu garantieren. Aber natürlich: Jeglicher Ansatz auf höherer Ebene (z.B. der heute übliche völlige Schwachsinn, den Kram über irgendwelche "Web-Technologien" abzuhandeln) ist natürlich genauso zum Scheitern verurteilt. Der muss entweder wichtige Features der Net-FS wegwerfen oder wird noch langsamer und unzuverlässiger sein. Das liegt in der Natur der Sache.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.