web-dev-qa-db-ja.com

OpenVPN経由でUbuntu / CIFSを介してWindows10共有にアクセスする

目標：LinuxからVPN経由でWindows10ファイル共有にアクセスすること。

このコンテキストでは、「サーバー」は単純なWindows 10マシンであり、「クライアント」はUbuntu18です。

OpenVPNトンネルを設定していますが、接続は良好で、接続でき、サーバーにpingを実行できます。ポートスキャンで正しい結果が得られ、ポート135へのTelnet接続を手動で確立できます。

私は、CIFSを使用して、Linux上のWindows共有にフォルダーをマウントしようとしています。これは、以前に何度も行ったことですが、確かにこの特定のWindowsマシンにはマウントしていません。

私は効果的に使用しています：mount -t cifs //server/share /mnt/shareしかし、結果は常に：

マウント：/ mnt/share：mount（2）システムコールが失敗しました：接続が拒否されました。

dmesg/syslogショー：

CIFS VFS：ソケットへの接続中にエラーが発生しました。操作を中止します。
CIFS VFS：cifs_mountが失敗しました（リターンコード= -111付き）

私は、すべてのセキュリティオプションを含め、考えられるほぼすべてのCIFSフラグを試しました。私が使用している実際の現在のコマンドは次のとおりです。
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ファイアウォールがオフになっていて、共有とフォルダーには、使用しようとしているユーザーアカウント、およびguest、anonymous loginに対する完全なアクセス許可があります。

接続をトリプルチェックするためだけにFTPサーバーをサーバーにインストールしました。

CIFSが接続されないのはなぜですか？ Windowsサーバーで接続に対して何が行われているのかを正確に確認する方法はありますか？および/またはUbuntuのCIFSからより多くのデバッグ出力を取得する方法はありますか？

編集：
nmap -Pn <Host>ポートスキャンは、次の開いているポートを示します。

ポートステートサービス
135/tcp open msrpc
554/tcp open rtsp
2869/tcp open icslap
10243/tcpオープン不明

更新/解決策：

問題と回避策が見つかりました。以下の@grawityからの回答は、サーバーがポート445でリッスンしていないという事実を警告しています。この問題はOpenVPNまたはlinux/CIFSとは何の関係もありません。

  1. Smbサーバーサービスがポート445でリッスンしていないことに注意してください。これは、ms_serverコンポーネントが動作していないことを意味します。
  2. ms_serverはSMBサーバーサービスです。これは、デバイスのネットワーク設定で次のチェックボックスを切り替えることで有効/無効になります：File and Printer Sharing for Microsoft Networks.
  3. この場合、チェックボックスはすでにオンになっています。チェックを外してもう一度チェックすると、問題が修正され、サーバーはポート445でリッスンし、ファイル共有が機能します。ただし、次の再起動までは一時的なものです。
  4. この全体の問題は、かなり最近のWindows Updateが原因で、Windows 10の 既知の問題 のようです。
  5. クリーンな解決策、または実際の問題に対する実際のパッチを見つけることができませんでした。
  6. 短期的な回避策の1つは、効果的に「チェックボックスをオフにしてチェックボックスをオンにする」小さなスクリプトを作成し、ユーザーがログインしたときに実行することです。

この問題を回避するためのPowerShellコマンドは次のとおりです。
Disable-NetAdapterBinding -Name "MyVPN" -ComponentID ms_server
Enable-NetAdapterBinding -Name "MyVPN" -ComponentID ms_server

linuxnetworkingwindows-10network-sharessmb
1
Mtl Dev

ポート135へのTelnet接続を手動で確立できます。

これは正しいポートではありません（RPC-EPMAPポートです）。 SMBはTCPポート445で実行されます。

（古い Win2000以前のクライアント との互換性のためにポート139も表示される場合があります。これは、SMB-over-NetBIOSのみをサポートしていました。これらのクライアントには、UDP 137–138のNetBIOSデータグラムサービスも必要です。）

マウント：/ mnt/share：mount（2）システムコールが失敗しました：接続が拒否されました
CIFS VFS：ソケットへの接続中にエラーが発生しました。操作を中止します。
CIFS VFS：cifs_mountが失敗しました（リターンコード= -111付き）

「接続が拒否されました」は、クライアントがハンドシェイクの試行に応答してTCP RSTを受信したことを意味します。これは通常、サーバーがそのTCPをリッスンしていないことを意味します。 =ポート、または接続をブロックするためにRSTをスプーフィングするファイアウォールがあること。

これは通常、ネゴシエートされるだけのプロトコルバージョンやセキュリティオプションの問題ではありません後 TCP接続が確立されました。

Windowsファイアウォールがオフになっている

どうして？

Windowsファイアウォールは構成可能です。ファイアウォールを通過するプロトコルを許可する場合は、そのプロトコルを許可するルールを作成できます。 （または、SMBまたはICMPを許可する場合は、事前定義されたルールを有効にするだけです。）

Windowsサーバーで接続に対して何が行われているのかを正確に確認する方法はありますか？および/またはUbuntuのCIFSからより多くのデバッグ出力を取得する方法はありますか？

Wiresharkなどのパケットキャプチャツールをインストールします。 tun0またはOpenVPNTAPアダプターでキャプチャを開始します。 TCP RSTが生成される直前に何が起こるかを見てください。

両側に同じパケットが表示されるかどうかに注意してください。クライアントが実際にTCPRSTを受信した場合、サーバーはTCP RSTを送信したことを示しますか？

1
user1686