Frage zu Samba

[dbeuebeb]

Ich möchte Samba verwenden, damit ich mit Kodi auf einen Ordner zugreifen kann. Der Server befindet sich nicht im lokalen Netzwerk. Hier ist meine Konfiguration:

[global]
workgroup = smb
security = user
encrypt passwords = true
invalid users = root
public = no
guest ok = no
;wins server = w.x.y.z
dns proxy = no
bind interfaces only = no
log file = /var/log/samba/log.%m
max log size = 1000
syslog = 0
panic action = /usr/share/samba/panic-action %d
server role = standalone server
passdb backend = tdbsam
obey pam restrictions = yes
unix password sync = no
pam password change = yes
map to guest = bad user
usershare allow guests = no
min protocol = SMB3
smb encrypt = required
[homes]
comment = Home Directories
browseable = no
read only = yes
create mask = 0700
directory mask = 0700
valid users = %S
[restricted]
valid users = smbuser
path = /home/smbuser/smbtest/
public = no
writable = no
read only = yes
comment = smb restricted share
printable = no
guest ok = no

Ich möchte also nur einen Share haben. Der Name des Shares heisst restricted, es soll kein Gastzugriff möglich sein und nur Leserechte bestehen. Ich hoffe mal, dass die oben genannte Konfiguration stimmt, ich kenne mich damit nicht so aus, wenn nicht, bitte korrigiert mich.

Allerdings kann ich nur vom lokalen Rechner aus zugreifen. Mit

smbclient -U smbuser%(passwort) //localhost/restricted

funktioniert es.

Mit

smbclient -U smbuser%(passwort) //(serverip)/restricted

Bekomme ich folgende Fehlermeldung:

Connection to (serverip) failed (Error NT_STATUS_IO_TIMEOUT)

Die Ports in ufw habe ich geöffnet. Netstat gibt folgendes aus:

$ netstat -aontpu46 | grep smbd
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      20448/smbd       off (0.00/0/0)
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      20448/smbd       off (0.00/0/0)
tcp6       0      0 :::445                  :::*                    LISTEN      20448/smbd       off (0.00/0/0)
tcp6       0      0 :::139                  :::*                    LISTEN      20448/smbd       off (0.00/0/0)

Hab ich irgendwas übersehen? Anpingen kann ich den Server auch.

 

[BFF]

Die Angaben der verwendeten Netzwerke (IP, Subnet, Gateway) fuer das SAMBA-Dingens und den Klient der auf das Share zugreifen soll waehre zielfuehrender.

Wer routet den Krams bei Dir?

BFF

 

[dbeuebeb]

Ich möchte meine IPs jetzt nicht leaken. Es läuft über WAN (also über Internet), es handelt sich um ein VPS. Ich kann auf den VPS via SSH zugreifen. Ich greife über IPv4 zu. Die ersten drei Ziffern der Server IP und meiner IP unterscheiden sich (kenne mich mit Netzwerk nicht so aus, aber ich glaube das bedeutet das /8 er Subnetz ist unterschiedlich).

 

[BFF]

Warum sagst Du das nicht in Deiner Frage das es sich nicht um ein Normalo-Heimnetz handelt?

Pruef nach ob Dein SAMBA-Dienst zugreifende IP von anderen Netzen ausserhalb seines Subnetzes akzeptiert, falls das eingehende VPN nicht gleich sein Netz ist. Wie das geht steht in der Dokumentation.

BFF

 

[memmex]

Wenn deine Sicherheit auf Geheimhaltung der Ip beruht, lass es lieber gleich mit offenen Sambaservern.
Samba im Internet - kommt nichts Gutes bei raus.

 

[dbeuebeb]

Warum sagst Du das nicht in Deiner Frage das es sich nicht um ein Normalo-Heimnetz handelt?

Pruef nach ob Dein SAMBA-Dienst zugreifende IP von anderen Netzen ausserhalb seines Subnetzes akzeptiert, falls das eingehende VPN nicht gleich sein Netz ist. Wie das geht steht in der Dokumentation.

BFF

Und wo in der Dokumentation steht das? Ich habe es leider nirgends gefunden. Wie heisst das Flag?

PS: Der Server ist nicht offen. Ich muss mich mit Passwort und Benutzername einloggen. Und ich hab in der Firewall eingestellt, dass nur meine IP auf den Server zugreifen kann. Die Kommunikation läuft ja auch verschlüsselt (oder?!). Habe min protocol auf SMB3 gestellt.

 

[Yuuri]

Die Kommunikation läuft ja auch verschlüsselt (oder?!). Habe min protocol auf SMB3 gestellt.

Steht aber nicht in der Config. Verschlüsselt läuft es auch nicht zwangsweise, dazu fehlt auch das smb encrypt Setting.

Du bekommst halt ein Timeout, durch was auch immer. Deaktivier erstmal die Firewall und probier es nochmal. Dann weißt du wenigstens ob es an dieser liegt oder du ggf. nen anderen Konfigurationsfehler hast.

Zu deinem Quote: Mach dir darum keine Gedanken. Der Listener läuft bei dir auf 0.0.0.0 bzw. ::, der akzeptiert also von überall Verbindungen.

 

[dbeuebeb]

Habe jetzt folgendes in der [global]-Sektion hinzugefügt:

min protocol = SMB3
smb encrypt = required

An der Firewall liegt es nicht, denn ich habe folgende Regel erstellt:

sudo ufw allow from (meineip) to any

Ich habe desweiteren den Eintrag

hosts allow = (meineip)

In die [global]-Sektion hinzugefügt, aber das ändert auch nichts. Immer noch
(Error NT_STATUS_IO_TIMEOUT)

 

[Yuuri]

Wie gesagt: Firewall deaktivieren. Zusätzliche Regeln hinzufügen, ändern oder löschen... Bringt nichts. Mach sie aus, dann weißt du ob es von der Firewall geblockt wird und kannst sie ausschließen und zum nächsten Schritt springen oder nicht.

 

[dbeuebeb]

Hab sie kurz deaktiviert (ufw disable), hat auch nichts geholfen.

 

[Yuuri]

Wenn du jetzt SMB3 als Minimum eingestellt hast, musst du auch mit -m SMB3 gegenprüfen. Gemacht?

 

[snaxilian]

Da die überwältigende Mehrheit der Leute, die SMB/CIFS im Internet betreiben wollen, dies nicht sauber hinbekommen, sind viele Provider dazu übergegangen diese Ports zu blockieren.
Probiere doch einfach mal dich mit telnet(client)/nc (oder anderem Tool deiner Wahl) nur zu dem TCP Port zu verbinden und mache im besten Fall noch auf dem Server ein tcpdump begrenzt auf das Interface und den Port und höchstwahrscheinlich wirst du da nix sehen.
Wenn doch können wir dann ja immer noch weiter rätseln. Einfachste Lösung: Client und Server per VPN verbinden und SMB/CIFS dadurch tunneln oder eine andere Art der Übertragung nutzen.

 

[dbeuebeb]

Ne, ports sind filtered

$ nmap -p 139,445 (SERVERIP)

Starting Nmap 7.60 ( https://nmap.org ) at 2019-02-28 23:52 CET
Nmap scan report for (IP)
Host is up (0.015s latency).

PORT STATE SERVICE
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds

Egal of Firewall aus oder an ist.

Ergänzung (1. März 2019)

Naja, werde dann wohl einen VPN verwenden. Hat doch kein Zweck..
Ich dachte es gäbe eine einfache Lösung für den Quark, scheint aber nicht der Fall zu sein.
Wobei ne das mit dem VPN funktioniert wohl doch nicht, da meine Fritz.Box kein OpenVPN unterstützt und ich von meinem Fire TV Stick aus auf den Share zugreifen will. Argh.

 

[snaxilian]

Brauchst auch nicht das Rad neu erfinden oder irgendwas mit OpenVPN basteln. Nutze doch einfach die Möglichkeiten, die schon vorhanden sind
https://blog.van-daag.nl/?p=300 <- Dort wird erklärt, wie man einen Raspberry Pi und damit so ziemlich jedes Linux als Client per VPN mit der Fritzbox verbinden kann.

Afaik tauchen VPN-Clients im selben Subnet auf wie interne Clients, zumindest bei der Fritzbox. Du musst dann somit nicht mal ein Routingeintrag setzen nur dem Server eben eine feste IP im privaten Subnetz der Fritzbox zuweisen.
Wenn du es ganz ordentlich machen willst packst dann den VPN Aufbau am Server in eine systemd unit, machst den Samba Dienst davon abhängig und bindest diesen dann auch nur auf das VPN-Interface, sprich der Share ist nur durchs VPN erreichbar.

 

[mensch183]

Ich würde nur ein VPN aufmachen, wenn es wirklich unvermeidbar ist. Ein VPN ist zwar oft fix eingerichtet, aber intern 3 Größenordnungen komplexer als das eigentliche Ziel, also das SMB-Share.

Hab sie kurz deaktiviert (ufw disable), hat auch nichts geholfen.

Du meinst auf dem Samba-Server die Firewall abgeschaltet, richtig? Aber hängt auf dem Weg von deinem Client zum Server nicht noch die Fritzbox dazwischen? Die blockiert in Voreinstellung Ports 139,445 auf dem WAN-Port. Das muss deaktiviert werden, siehe hier Punkt 3.

Probiere dann erstmal aus, ob zwischen Client und Server auf den fraglichen Ports ordentlich Daten ausgetauscht werden können oder ob vielleicht noch immer irgendwas dazwischen blockiert. Also auf dem Server samba erstmal abschalten und mit der Netzkatze testen:

server# nc -l -p 139
client# nc ServerIPAdresse 139

Damit als Test paar Zeichen übertragen und gut. Das gleiche wird auf Port 445 und dann noch auf beiden Ports mit UDP (zusätzliche Option -u auf beiden Seiten) wiederholt. Es sind also 4 Tests.

Wenn die 4 Tests funktionieren, ist die "Leitung" in Ordnung und damit die """notwendige""" Basis sichergestellt. Erst dann samba konfigurieren und anwerfen. Port 139 als auch generell UDP sind verzichtbar für CIFS zwischen Linux<->samba.

 

[snaxilian]

Afaik blockiert die Fritzbox aber nur ingehenden SMB-Traffic? Der TE versucht ja von seinem Netzwerk zuhause auf einen SMB-Share im Internet zuzugreifen, sprich ausgehend vom LAN Richtung WAN.

 

[mensch183]

Kann sein. Keine Ahnung, wie der Filter im Detail aussieht. Hier taucht er jedenfalls auch unter den "outgoing filters" auf.

 

[dbeuebeb]

Danke an mensch183, du hast das Rätsel nun gelöst. Die Fritz Box blockiert tatsächlich standardmäßig die ausgehenden Ports 139 und 445. Meine Fresse. Da wär ich im Leben nicht drauf gekommen. Hahahahaha, was für eine Dreckskiste.

Naja, Problem gelöst.. LEL!