web-dev-qa-db-ja.com

説明の必要性：VMwareネットワークアダプタ上のNetBIOS over TCP / IPは、ネットワーク共有へのアクセスを妨害します

（StackOverflowからここに移動）

少し前に、私たちのチームのほぼすべてのワークステーション（Windows XP SP2）は、ネットワーク上の共有にアクセスするときに、断続的ですが頻繁な遅延を示しました。通常、一部のユーザーがアクセスしなかった共有への最初のアクセスその結果、ワークステーションは最大30秒間ほぼフリーズしました。その後、すべてが再び正常に機能し始めました。

SysinternalsからTCPViewを使用すると、この遅延中に、状態がSYN_SENTであったファイルサーバーのnetbios-ssnポートへの接続があったことがわかりました。

最初の試行：

イントラネットネットワークアダプタのNetBIOS over TCP/IPを無効にします。

問題は解決しましたが、イントラネットの集中管理されたネットワーク構成を操作するのは好きではありませんでした。

2回目の試行：

無効NetBIOS over TCP/IP VMWareネットワークアダプタのみ（VMNet1はホストのみの通信に使用）。

問題は再び解決しました！

私の質問：

  • あるネットワークアダプタのNetBIOS over TCP/IPが別のネットワークアダプタのNetBIOS over TCP/IPを妨害するのはなぜですか？
  • この問題はVMWareネットワークアダプタに固有のものですか？
  • 他の誰かがこの現象を見たことがありますか？

追加情報：

  • VMWareWorkstationバージョン6.0.3
  • 問題を真剣に分析し始めたとき、問題が始まったときにシステムに何が変更されたかを知ることはもはや不可能でした。
windows-xptcpipvmware-workstationnetbios
2
gyrolf

私は同様の現象を見てきました。

症状は一見あまり似ていないように聞こえます。ローカルディスクまたはネットワーク共有のどちらにアクセスしたかに関係なく、Windowsエクスプローラーが数秒間ハングすることがあります。

しかし、いくつかの調査の結果、ハングは同様のNetBIOSの問題が原因であると私は信じています。

いくつかのシステムの詳細：

  • Windows XP Pro SP3
  • VMware Server1.0.9がインストールされています
  • VMNet1（ホストのみ）ネットワークアダプターとNetBOIS over TCP/IPが有効
  • VMNet8（NAT）ネットワークアダプターとNetBOIS over TCP/IPが有効
  • システムの唯一の物理ネットワークアダプタの静的IPアドレスは192.168.10.111です。このアダプターは、192.168.10.192を唯一のWINSサーバーとして使用するように構成されています。MACアドレス：00-16-17-FA-2C-D4
  • VMNet1アダプターでは、システムの静的IPアドレスは192.168.137.1です。いいえWINSサーバーが構成されています。MACアドレス：00-50-56-C0-00-01
  • VMNet8アダプターでは、システムの静的アドレスは192.168.145.1です。いいえWINSサーバーが構成されています。MACアドレス：00-50-56-C0-00-08
  • すべてのVMはNATを使用するように構成されていますが、とにかく停止します。

物理アダプタでパケットをスニッフィングするWiresharkを一日中実行していました。 Explorerが数秒間同時にハングしたときはいつでも、NetBIOSネームサービスクエリパケットがWINSサーバーに送信されました。これらのパケットには、送信元IPアドレスとしてVMNetアダプタのアドレスの1つが含まれていました。

疑わしいパケットの1つは次のとおりです。

Frame 25475 (92 bytes on wire, 92 bytes captured)
Ethernet II, Src: 00:16:17:fa:2c:d4 (00:16:17:fa:2c:d4), Dst: 00:15:c5:87:4f:6a (00:15:c5:87:4f:6a)
Internet Protocol, Src: 192.168.145.1 (192.168.145.1), Dst: 192.168.10.192 (192.168.10.192)
User Datagram Protocol, Src Port: netbios-ns (137), Dst Port: netbios-ns (137)
NetBIOS Name Service
  Transaction ID: 0x82a5
  Flags: 0x0000 (Name query)
  Questions: 1
  Answer RRs: 0
  Authority RRs: 0
  Additional RRs: 0
  Queries
    *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>: type NBSTAT, class IN

これは正しくないと思います。代わりに、パケットの送信元IPアドレスを192.168.10.111に設定する必要があります。

WINSサーバーのインターフェイスでパケットをスニッフィングしていません。しかし、192.168.145.0ネットワークに接続されていないため、デフォルトゲートウェイ経由で192.168.145.1に応答を送信することを期待しています。ゲートウェイは、「ネットワークに到達できません」でこのパケットを拒否する必要があります。

これはUDPパケットであるため、SYN​​_SENT状態の接続はありません。ただし、同じ方法で「破損」したTCP SYNパケットは、タイムアウトが発生するまで接続をSYN_SENT状態のままにする必要があります。

この問題を回避しようとしたいくつかのこと：

  1. 両方のVMNetアダプターを無効にします。問題は解決しました。疑わしいパケットはありません。
  2. VMnet1を再度有効にします。エクスプローラーが再びハングし始めることがあります。ソースが192.168.137.1の疑わしいパケット。
  3. VMNet1を無効にして、VMNet8を再度有効にします。エクスプローラーがハングすることがあります。ソースが192.168.145.1の疑わしいパケット。
  4. 両方のVMNetアダプターを有効にしますが、両方のNetBIOS over TCP/IPを無効にします。問題は解決しました。疑わしいパケットはありません。
  5. VMNet1のNetBIOSover TCP/IPを再度有効にします：エクスプローラーが再びハングし始めることがあります。ソースが192.168.137.1の疑わしいパケット。
  6. VMNet1のNetBIOSover TCP/IPを無効にし、VMNet8のNetBIOSを再度有効にします。エクスプローラーがハングすることがあります。ソースが192.168.145.1の疑わしいパケット。
  7. すべてのインターフェイスで、インターフェイスメトリックを自動メトリックから静的値に変更します。メトリックが最も低いLANアダプター：エクスプローラーがまだ時々ハングし、疑わしいパックがキャプチャされます。

ネットワークでアダプタの順序を確認しました[接続]-> [詳細設定]-> [詳細設定]およびnetsh interface ip show configを実行します。ローカルエリア接続は、両方の場所にリストされている最初の接続です。

さらに、いくつかのNTP送信元IPアドレスが192.168.137.1のパケットと192.168.145.1が物理アダプタを介して192.168.10.192（AD DC）に送信されていることに気付きました。

1
DWB

私の経験では、Vmware NATは制限された機能です。他のネットワークモードでも、一部の種類のパケットが返されないことがわかりました。これは、Vmwareがネットワークデータを処理する方法のバグだと思います。

0
jack

ここで同じ問題。 Wiresharkでキャプチャされた疑わしいパケット：プロトコル：NBNS、情報：名前クエリNBSTAT

NATが構成されていますが、vmnet8からのIPを持つパケットは物理ネットワークで送信されます。

  • 「NetbiosoverWAN」を無効にする->物理接続で疑わしいパケットが送信されない（vmnet8のsender-ipを使用）。
  • Vmwareクエストで無効にされたsambaサービス->疑わしいパケットは送信されません

この奇妙なNetBIOSは、vmwareによってNAT処理されていないようです。

Guenter。

0
Guenter