Zugriff auf eine Windows 10-Freigabe über Ubuntu / CIFS über OpenVPN

480
Mtl Dev

Ziel: Zugriff auf Windows 10-Dateifreigaben von Linux über ein VPN.

In diesem Zusammenhang: "Server" ist ein einfacher Windows 10-Computer und "Client" ist Ubuntu 18.

Ich habe einen OpenVPN-Tunnel-Setup, die Verbindung scheint gut zu sein, ich kann eine Verbindung herstellen, den Server anpingen, Portscan liefert korrekte Ergebnisse und ich kann manuell eine Telnet-Verbindung zu Port 135 herstellen.

Ich versuche, einen Ordner auf Linux zu mounten, auf das Windows-Share zuzugreifen, CIFS zu verwenden, etwas, das ich schon oft gemacht habe - allerdings nicht zu dieser bestimmten Windows-Maschine.

Ich benutze effektiv: mount -t cifs //server/share /mnt/shareaber das Ergebnis ist immer:

mount: / mnt / share: mount (2) Systemaufruf fehlgeschlagen: Verbindung abgelehnt.

dmesg / syslog show:

CIFS VFS: Fehler beim Verbinden mit Socket. Vorgang wird abgebrochen.
CIFS VFS: cifs_mount fehlgeschlagen mit Rückkehrcode = -111

Ich habe fast alle CIFS-Flaggen ausprobiert, die ich mir vorstellen kann, einschließlich aller Sicherheitsoptionen. Der aktuelle Befehl, den ich verwende, lautet:
sudo mount -v -t cifs -o vers=3.1.1,username=myuser,pass=mypass,servern=WINDESKTOP,sec=ntlmssp //10.8.0.1/share /mnt/share

Windows - Firewall ausgeschaltet ist, die den Anteil und Ordner haben vollständige Berechtigungen für das Benutzerkonto ich zu verwenden Ich versuche, sowie guest, anonymous login.

Ich habe einen FTP-Server auf dem Server installiert, nur um die Konnektivität zu überprüfen.

Warum verbindet sich CIFS nicht? Gibt es eine Möglichkeit auf dem Windows-Server, genau zu sehen, was mit der Verbindung gemacht wird? Und / oder gibt es überhaupt eine bessere Debugging-Ausgabe von CIFS auf Ubuntu?

Bearbeiten:
Ein nmap -Pn <host>Portscan zeigt die folgenden offenen Ports:

PORT STATE SERVICE
135 / tcp open msrpc
554 / tcp open rtsp
2869 / tcp open icslap
10243 / tcp open unbekannt

Update / Lösung:

Das Problem und eine Problemumgehung wurden gefunden. Die Antwort unten von @ grawity weist darauf hin, dass der Server Port 445 nicht überwacht. Das Problem hat nichts mit OpenVPN oder Linux / CIFS zu tun

  1. Beachten Sie, dass der SMB-Serverdienst Port 445 nicht überwacht. Dies bedeutet, dass die ms_serverKomponente nicht betriebsbereit ist.
  2. ms_server ist der SMB-Serverdienst. Dies wird durch Aktivieren des folgenden Kontrollkästchens in den Netzwerkeinstellungen eines Geräts aktiviert / deaktiviert: File and Printer Sharing for Microsoft Networks.
  3. In diesem Fall war das Kontrollkästchen bereits aktiviert. Durch Deaktivieren und erneutes Überprüfen wird das Problem behoben, der Server überwacht Port 445 und die Dateifreigabe funktioniert. Aber nur vorübergehend bis zum nächsten Neustart.
  4. Dieses gesamte Problem scheint ein bekanntes Problem mit Windows 10 zu sein, das durch ein relativ neues Windows Update verursacht wurde
  5. Ich konnte keine saubere Lösung oder einen echten Patch für das eigentliche Problem finden.
  6. Eine kurzfristige Problemumgehung besteht darin, ein kleines Skript zu erstellen, das das Kontrollkästchen deaktiviert und das Kontrollkästchen deaktiviert, und ausgeführt wird, wenn sich ein Benutzer anmeldet.

Die Powershell-Befehle zur Behebung dieses Problems sind:
Disable-NetAdapterBinding -Name "MyVPN" -ComponentID ms_server
Enable-NetAdapterBinding -Name "MyVPN" -ComponentID ms_server

0

1 Antwort auf die Frage

1
grawity

Ich kann manuell eine Telnet-Verbindung zu Port 135 herstellen.

Das ist nicht der richtige Port (das ist der RPC-EPMAP-Port). SMB wird auf dem TCP-Port  445 ausgeführt .

(Möglicherweise wird auch Port 139 angezeigt, um die Kompatibilität mit älteren Pre-Win2000-Clients zu gewährleisten, die nur SMB-over-NetBIOS unterstützten. Diese Clients benötigen außerdem NetBIOS-Datagrammdienste für UDP 137-138.)

mount: / mnt / share: mount (2) Systemaufruf fehlgeschlagen: Verbindung abgelehnt
CIFS VFS: Fehler beim Verbinden mit Socket. Vorgang wird abgebrochen.
CIFS VFS: cifs_mount fehlgeschlagen mit Rückkehrcode = -111

"Verbindung abgelehnt" bedeutet, dass der Client als Antwort auf seinen Handshake-Versuch ein TCP-RST erhalten hat. Dies bedeutet im Allgemeinen, dass der Server diesen TCP-Port nicht überwacht oder dass eine Firewall ein RST spoofing, um die Verbindung zu blockieren.

Hierbei handelt es sich in der Regel nicht um Protokollversionen oder Sicherheitsoptionen, die erst nach dem Aufbau der TCP-Verbindung ausgehandelt werden .

Die Windows-Firewall ist deaktiviert

Warum?

Die Windows-Firewall ist konfigurierbar: Wenn Sie ein Protokoll durch dieses Protokoll zulassen möchten, können Sie eine Regel erstellen, die das Protokoll zulässt. (Oder aktivieren Sie einfach eine vordefinierte Regel, wenn Sie SMB oder ICMP zulassen.)

Gibt es eine Möglichkeit auf dem Windows-Server, genau zu sehen, was mit der Verbindung gemacht wird? Und / oder gibt es überhaupt eine bessere Debugging-Ausgabe von CIFS auf Ubuntu?

Installieren Sie ein Paketaufnahmetool wie Wireshark. Starten Sie ein Capture auf tun0dem OpenVPN-TAP-Adapter. Sehen Sie sich an, was unmittelbar vor der Generierung des TCP-RST geschieht.

Achten Sie darauf, ob beide Seiten dieselben Pakete sehen. Wenn der Client beispielsweise ein TCP-RST empfängt, zeigt der Server an, dass er eines gesendet hat?

1) Ah, ich verstehe, dass SMBv1 auf den Ports 135..139 ausgeführt wird. Ich weiß, dass SMBv2 + auf Port 445 läuft. Ein Port-Scan (siehe "Bearbeiten" zeigt, dass der Server * nicht * auf Port 445 wartet.) . Zumindest nicht auf der VPN-IP-Adresse. Ich denke, das ist ein Problem, das untersucht werden muss ...) Mtl Dev vor 5 Jahren 0
2) Die Windows-Firewall wurde während des Tests vorübergehend deaktiviert, um sie als mögliche Ursache zu beseitigen. Mtl Dev vor 5 Jahren 0
Sowohl SMBv1 (auch bekannt als CIFS) als auch SMBv2 + verwenden denselben Transport: TCP / 445 für moderne Systeme oder TCP / 139 für alte NetBIOS-Systeme. Die anderen Ports sind nicht wirklich SMB: TCP / 135 ist MS-RPC und UDP / 137-138 sind verschiedene NetBIOS-Dienste. grawity vor 5 Jahren 0
Was nmap zeigt, ist genau das, was das cifs-Modul Ihnen sagt. Es kann keine zusätzlichen Informationen aus der Ferne abrufen, und es weiß nicht, ob ein Port "abhört" - es wird nur angezeigt, ob der Port den Verbindungsversuch akzeptiert hat. Sie müssen also wirklich auf dem Server selbst und / oder auf Router-Firewalls unterwegs nachsehen. grawity vor 5 Jahren 0
OK danke! Der Server lauscht (`netstat -an`) von 445 auf seiner regulären IP-Adresse, aber 445 ist auf seiner VPN-IP nicht geöffnet. Manifestation: Wenn ich auf Windows-Server "\\ serverIP" oder "\\ 127.0.0.1" eingebe, kann ich die Freigaben gut sehen, aber wenn ich "\\ serverVPNip \" eingebe, kann ich die Freigaben nicht sehen. Die Zeit ist abgelaufen Mtl Dev vor 5 Jahren 1
Eigentlich sind Sie in Bezug auf Ihr System richtig: SMBv2 + verwendet keine NetBIOS-Dienste und benötigt daher nur TCP / 445. (SMBv1 kann je nach System entweder TCP / 445 oder TCP / 139 verwenden.) grawity vor 5 Jahren 0
Basierend auf den Ergebnissen von nmap können wir also zu 100% sagen, dass Port 445 nicht auf dem Server wartet. Da der Pfad keine Firewalls enthält, muss das Problem daher sein: Windows File Sharing ist für das TAP-Netzwerkgerät irgendwie deaktiviert? Klingt das eine vernünftige Schlussfolgerung? Mtl Dev vor 5 Jahren 0
Nein, aber aufgrund Ihrer _netstat -an_ -Ergebnisse auf dem Server selbst können Sie sagen, dass dieser Port nicht überwacht wird (zumindest nicht an der richtigen Adresse). Das Protokoll ist möglicherweise im Fenster "Eigenschaften" des Netzwerkadapters deaktiviert. grawity vor 5 Jahren 0
Ein guter Vorschlag, das war eines der ersten Dinge, die ich überprüft habe. Ich habe den folgenden Artikel gefunden (https://social.technet.microsoft.com/Forums/en-US/17ad2cbb-a98b-4da4-b122-9489980024bc/smbv2-not-listeningon-port-445?forum = win10itpronetworking) Bei der Lösung handelt es sich im Wesentlichen um das Deaktivieren der Dateifreigabe, das Schließen und das erneute Überprüfen. Mtl Dev vor 5 Jahren 0
So funktioniert es jetzt, hört auf 445 zu. Lösung: wie in der Microsoft-Hilfe: Häkchen deaktivieren und Dateifreigabe (!) Erneut prüfen. Dieses Update ist nicht unbedingt ein Neustart, ich werde daran arbeiten, als post zurück. Ihre Antwort war hilfreich, um mich darauf hinzuweisen, dass Port 445 nicht geöffnet ist. Wenn ich mit dem Neustart-Survival-Fix zurück bin, können Sie sich bitte zu einer Antwort zusammenfassen, damit ich zustimmen kann. Mtl Dev vor 5 Jahren 0
Ich schätze, wenn Sie bitte die in Frage stehende Lösung überprüfen können. Für den nächsten Benutzer möchten Sie möglicherweise die Antwort mit "" erweitern, wenn der Server Port 445 nicht überwacht. Die Option "Datei- und Druckerfreigabe .." ist markiert. Wenn bereits aktiviert, deaktivieren Sie das Kontrollkästchen "". Glauben Sie, dass ich Ihrer Erfahrung nach, Level, alle Verweise auf openvpn / linux von der Frage entfernen sollte, um rote Heringe zu vermeiden? Mtl Dev vor 5 Jahren 0

Verwandte Probleme