Dieser Beitrag ist älter als drei Jahre. Es könnte also sein, dass auch der Inhalt - zumindest in Teilen - bereits veraltet ist.

Raspberry Pi als „SMB1 / SMB2/3 Gateway“

Vorab: Dieser Artikel beschäftigt sich rein lösungsorientiert ausgehend von einer Situation in der es vorerst keine andere Lösung gibt. Er geht von einem vertrauten Netzwerk aus und beschäftigt sich nicht mit Security-Fragen. Die weitere Abhärtung solch eines Setups obliegt demjenigen der es implementiert.
Es steht außer Frage, dass es vermieden werden sollte mit veralteten SMB Protokollen zu hantieren und dass Lösungen wie diese nur vorübergehend sein können, bis man eine Möglichkeit hat die betroffenen Systeme upzudaten.

Mit den Windows 10 Update Tranchen von etwa Herbst 2020 hat Microsoft das veraltete (und unsichere) SMB1 Protokoll deaktiviert. Dies betrifft jene, die per Dateifreigabe, Netzlaufwerk etc. auf Systeme wie zb. Windows XP (oder niedriger), Windows Server 2003 oder stark veraltete Samba Server zugreifen.

Ich habe hier eigentlich nicht mit großartigen Auswirkungen gerechnet, es zeigte sich aber recht schnell dass in einigen Umgebungen noch solche Systeme im Einsatz sind. Und zwar oft Embedded Systeme (zb. auf Produktionsmaschinen), die sich nicht so ohne weiteres updaten lassen. In diesen Fällen klappte der Zugriff quasi von heute auf morgen nicht mehr.

Der erste Schritt war natürlich, SMB1 auf den Windows 10 Rechnern in den Windows-Features wieder zu aktivieren. Aus mir unbekannten Gründen stellte sich dies aber als äußerst instabil heraus. Die betroffenen Netzlaufwerke funktionierten zwar wieder, allerdings nur für ein paar Stunden – dann kam es oft zu sehr hässlichen Abstürzen und es erforderte mehrere Neustarts um die Netzlaufwerke wieder verbinden zu können. Das alles mitunter mehrmals am Tag.

Daher habe ich mir, bis die betroffenen Systeme upgedatet werden können, einen Workaround einfallen lassen. Die Idee war, einen Raspberry Pi mit Samba einzusetzen. Samba beherrscht alle SMB Protokolle relativ sauber, ich dachte also daran die eigentliche SMB1 Freigabe auf dem Raspberry zu mounten und dann wiederum per Samba mittels SMB3 freizugeben. Der Windows 10 Rechner seinerseits verbindet sich dann sein Netzlaufwerk auf den Raspberry.

Hierzu habe ich ein Standard Raspberry OS verwendet. Zuerst mal alles upgegradet mittels

apt-get update
apt-get upgrade

Anschließend habe ich in der raspi-config die grafische Oberfläche deaktiviert und die nötigen Pakete installiert:

apt-get install samba samba-common-bin
apt-get install cifs-utils
apt-get install smbclient

Nun mal testweise die Freigabe auf dem alten Rechner (10.0.0.5) gemountet

mount.cifs -o user=user,vers=1.0,password=pass,dir_mode=0777,file_mode=0777 //10.0.0.5/Freigabename /mnt/alter_rechner

Wichtig ist hier die Angabe von „vers=1.0“, das die veraltete SMB1 Version erzwingt. Der Freigabe des alten Rechners ist nun nach /mnt/alter_rechner gemountet. Nun muss diese Ihrerseits noch am raspberry freigegeben werden. Hierzu in der /etc/samba/smb.conf zum Beispiel folgenden Schnippsel anhängen:

[Freigabename]
path = /mnt/alter_rechner
writeable=Yes
create mask=0777
directory mask=0777
public=no

Nun kann diese Freigabe auf einem Windows 10 Rechner zum Beispiel mittels \\ip-oder-name-des-raspi\freigabename verbunden werden.

Damit die Freigabe des alten Rechners bei künftigen Neustarts automatisch gemountet wird, habe ich folgenden Eintrag in der /etc/fstab erstellt:

//10.0.0.5/Freigabename     /mnt/alter_rechner      cifs    auto,x-systemd.automount,cache=none,rsize=130048,wsize=57344,user=user,vers=1.0,password=pass,dir_mode=0777,file_mode=0777        0 0

Natürlich ist bei diesem Setup der Raspberry der Netzwerk-Flaschenhals. Als ich die Idee entwickelt habe, war das eher ein Versuch und ich dachte mir die ganze Zeit dass das ein ziemlicher Pfusch ist. Allerdings funktioniert das Setup erstaunlich performant und stabil. Ein auf diesem Weg verbundenes Netzlaufwerk verhält sich sehr zuverlässig und auch bandbreitenintensivere Anwendungen wie das Ansehen eines Videos oder das Kopieren größerer Dateien funktionierten anstandslos und mit annehmbarer Geschwindigkeit.

Für beschriebene Szenarien halte ich diese Vorgehensweise also durchaus für eine valide Übergangslösung.