ホストWindowsからのpingにゲストCentOS6が応答しない原因がわかりません

Windows 7にインストールしたVirtualBoxのゲストOSとしてCentOS 6.6を実行しているのですが、ホストOS（Windows）とゲストOS（CentOS）間のpingが失敗します。

原因として考えられるものは何があるでしょうか？

以下、環境とここまで調べた結果を記します。

PC環境

ホストOS

Windows 7(64bit）
NIC（１）マザーボード上Realtek PCIe GBE Family Controller。192.168.11.3
NIC（２）ASIX AX88179 USB 3.0 to Gigabit Ethernet Adapter。192.168.1.1
VirtualBox 5.0.4

ゲストOS

CentOS 6.6（64bit)
eth0 NATアダプタ（インターネットアクセス用）DHCP
eth1 ブリッジアダプタ（今回使用するNIC）ホストNIC（２）に対応。192.168.1.101
eth2 ホストオンリーネットワークアダプタ。192.168.56.101

現象

WindowsのDOS窓から192.168.1.101に向けてpingするも、DOS窓上「要求がタイムアウトしました」とエラーになります。

CentOSのターミナルから192.168.1.1に向けてpingするも、ターミナル上応答が表示されません（ので強制終了）

ここまでの調査結果

ホストOSWindows側で192.168.1.0はNIC（２）を使うようになっている

shell
1          0.0.0.0          0.0.0.0     192.168.11.1     192.168.11.3    276
2      192.168.1.0    255.255.255.0            リンク上       192.168.1.1    266
3      192.168.1.1  255.255.255.255            リンク上       192.168.1.1    266
4      192.168.1.2  255.255.255.255            リンク上       192.168.1.1    266
5    192.168.1.255  255.255.255.255            リンク上       192.168.1.1    266
6（中略）
7          0.0.0.0          0.0.0.0     192.168.11.1     既定

ゲストOS側CentOSも192.168.1.0/24はeth1を使うようになっている

shell
1[devel@devel sysconfig]$ sudo route -n
2Kernel IP routing table
3Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
4192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
510.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
6192.168.56.0    0.0.0.0         255.255.255.0   U     0      0        0 eth2
70.0.0.0         10.0.2.2        0.0.0.0         UG    0      0        0 eth0

ゲストOS側CentOSでICMPを処理できていない？

ゲストOS側CentOSでtcpdumpコマンドを使って全てのデバイスに対してパケットをモニタしてみました。以下のコマンドは個々別のターミナルで実行しました。

shell
1sudo tcpdump icmp -i lo
2sudo tcpdump icmp -i eth0
3sudo tcpdump icmp -i eth1
4sudo tcpdump icmp -i eth2
5sudo ping 192.168.1.1

ゲストOS（CentOS）のtcpdumpには、以下のようにICMPのrequest/replyが表示されますが、pingコマンドは（Ctrl+Cで止めるまで）何の結果も表示しません。

09:43:32.790296 IP 192.168.1.101 > 192.168.1.1: ICMP echo request, id 50697, seq 18, length 64
09:43:32.790689 IP 192.168.1.1 > 192.168.1.101: ICMP echo reply, id 50697, seq 18, length 64
09:43:33.790061 IP 192.168.1.101 > 192.168.1.1: ICMP echo request, id 50697, seq 19, length 64
09:43:33.790467 IP 192.168.1.1 > 192.168.1.101: ICMP echo reply, id 50697, seq 19, length 64

ファイヤーウォールは止めています

CentOSでもWindowsでも、ファイヤーウォールは止めてやっても現象は変わりません。

CentOSでは、SELinuxもdisabledにしています。

回答3件

解決しました。しかし、私自身で納得できる原因は判りませんでした。

とりあえず問題解消の方法を記します。

問題箇所と解決方法

原因は、ゲストOS(CentOS）でのNICの配置でした。当然ながら、ホストOS上Oracle VM VirtualBox マネージャーでのネットワークアダプタの配置も合わせて変更しています。

pingが通らない

Windows:
0. NAT
0. ブリッジアダプタ
0. ホストオンリーネットワークアダプタ

CentOS:
eth0: DHCP（インターネットアクセス用）
eth1: 192.168.1.101
eth2: 192.168.56.101

ping OK

1枚目のNICをブリッジアダプタにしたところ解決しました。

Windows:
0. ブリッジアダプタ（★ココがポイント）
0. ホストオンリーネットワークアダプタ
0. NAT

CentOS:
eth0: 192.168.1.101
eth1: 192.168.56.101
eth2: DHCP（インターネットアクセス用）

ご参考

pingが通らないように見えるのは、どうやらパケットが激しくロスっている現象だったようです。

例えばある時の様子ですが、ホストOSのWindows側でpingを打った際、たまにICMPが通ることがありました。以下のpingは間髪おかずに実行しています。1回目のpingではrequest/replyが1回のみ。2回目はゼロでした。

ゲストOS（CentOS）でも同様で、ロスり方がもうちょっとマシ程度でした。

D:\temp>ping 192.168.1.101 -S 192.168.1.1

192.168.1.101 に ping を送信しています 192.168.1.1 から 32 バイトのデータ:
要求がタイムアウトしました。
192.168.1.101 からの応答: バイト数 =32 時間 =1ms TTL=64
要求がタイムアウトしました。
要求がタイムアウトしました。

192.168.1.101 の ping 統計:
パケット数: 送信 = 4、受信 = 1、損失 = 3 (75% の損失)、
ラウンドトリップの概算時間 (ミリ秒):
最小 = 1ms、最大 = 1ms、平均 = 1ms

D:\temp>ping 192.168.1.101 -S 192.168.1.1

192.168.1.101 に ping を送信しています 192.168.1.1 から 32 バイトのデータ:
要求がタイムアウトしました。
要求がタイムアウトしました。
要求がタイムアウトしました。
192.168.1.101 からの応答: バイト数 =32 時間 =1ms TTL=64

192.168.1.101 の ping 統計:
パケット数: 送信 = 4、受信 = 1、損失 = 3 (75% の損失)、
ラウンドトリップの概算時間 (ミリ秒):
最小 = 1ms、最大 = 1ms、平均 = 1ms

補足

最近VirtualBoxを4.3から5.0にバージョンアップしたのでそれが関係していると思い、VirtualBoxを4.3にダウングレードしましたが（ドライバは戻ってないかもしれません）結果は同じだったので、おそらくVirtualBoxのバージョンは関係していないと思います。

投稿2015/09/21 01:25

tchofu

総合スコア87

ホストがubuntu、ゲストがWindowsですが、このサイトで2つの事をされておられました試してみては如何でしょうか？
・ usermod -a -G vboxusers user
・WindowsのFireWallのpingの許可

投稿2015/09/19 23:32

Ken.sakanakana

総合スコア1768

回答へのコメント

tchofu

2015/09/20 00:09

コメントありがとうございます。ホストOS／ゲストOSともにファイヤーウォールは止めているんです。

ベストアンサー

ホスト側の NIC(2)、CentOS の eth1 はリンクアップしているでしょうか。
物理的にハブなどに繋がないと、OS側でリンクアップを認識せず、通信できない場合があります。
CentOS 側だと "ip addr show dev eth1" や "ifconfig eth1" で「UP」が表示されるか確認ください。

また、ARP レベルで到達するか、MACアドレスが正しいか確認してください。

(CentOS)
$ sudo arping -I eth1 192.168.1.1
ARPING 192.168.1.1 from 192.168.1.101 eth1
Unicast reply from 192.168.1.1 [MACアドレス]  0.617ms
Unicast reply from 192.168.1.1 [MACアドレス]  0.757ms

  応答のあった MACアドレスがホスト側 NIC(2) であることを確認

投稿2015/09/19 15:20

TaichiYanagiya

総合スコア12054

回答へのコメント

tchofu

2015/09/19 23:16 編集

アドバイスありがとうございます。 MACアドレスは、（１）ホスト側VirtualBoxアダプタ１（ブリッジアダプタ）のMACアドレス＝CentOSのeth1 でした。 ARPレベルで到達しませんでした。CentOSのtcpdumpにも何も表示されませんでした。 $ sudo arping -I eth1 192.168.1.4 [sudo] password for devel: ARPING 192.168.1.4 from 192.168.1.101 eth1 ^CSent 800 probes (800 broadcast(s)) Received 0 response(s) arpingを強制終了させた後、arp -sでキャッシュを作成したところ、CentOSからのICMP requestはeth1に向けて出されるようになりましたが、応答はありません。ホストOSのWindows側でWireSharkを使ってICMPをモニタしているのですが、これにrequestは表示されません。物理ネットワークにつながっているUbuntu（別PC)でもパケットは見られませんでした。なんか、VirtualBoxのブリッジアダプタからゲストOSのICMPパケットが出ていないように見えます。

tchofu

2015/09/19 23:24

追加情報です。ホスト側WindowsのarpテーブルにCentOSが登録されていなかったため、arp -sで登録しましたが、ホスト側WireSharkにrequestパケット（ホストOS→ゲストOS）が表示されるものの、ゲスト側には何も見られませんでした。ゲストOS→ホストOSも同様です。

tchofu

2015/09/20 00:06

追加情報です。仮想マシンを再起動した（他に使うNICを変えてみたりしました）ら、arpingで192.168.1.1（ホストOSのブリッジアダプタに指定しているNICに割り当てたIPアドレス）にはUnicast replyが返るようになりました。しかし、pingは未だ通りません。ゲストOSのtcpdumpでは、request/reqplyが表示されています。 09:04:40.362014 IP 192.168.1.101 > 192.168.1.1: ICMP echo request, id 3850, seq 1, length 64 09:04:40.362321 IP 192.168.1.1 > 192.168.1.101: ICMP echo reply, id 3850, seq 1, length 64 09:04:41.374475 IP 192.168.1.101 > 192.168.1.1: ICMP echo request, id 3850, seq 2, length 64 09:04:41.374799 IP 192.168.1.1 > 192.168.1.101: ICMP echo reply, id 3850, seq 2, length 64 09:04:42.379837 IP 192.168.1.101 > 192.168.1.1: ICMP echo request, id 3850, seq 3, length 64 09:04:42.380181 IP 192.168.1.1 > 192.168.1.101: ICMP echo reply, id 3850, seq 3, length 64

tchofu

2015/09/20 00:21

追加情報です。問題が起きているPCとは別に、物理PC（Ubuntu）を１台追加して192.168.1.4を割り当てました。 CentOSで192.168.1.4に対して何も設定しないと、eth0（NAT用）にrequestを出しました。eth0が使われた理由は謎です。 sudo arping -I eth1 192.168.1.4 するとeth1(ブリッジアダプタ）を使うようになり、別のPCならばpingも通りました。現時点の状態は以下のようになっています。（１）ホストOSにはpingが通らない（２）別のPCならばpingが通る

TaichiYanagiya

2015/09/20 14:15

ホストとゲストでMACアドレスが同じ？ VirtualBox の「ブリッジ」ってそういうものなのでしょうか。同じ MAC アドレスになっていても、ゲストと外部との通信についてはホスト側の VirtualBox のドライバがうまくやってくれるのかもしれません。しかし、ゲストからホストへの通信は、ゲスト自身が持つ MACアドレスとなるため、外に出て行かないのだと思います。もしかしたら、ゲストに VirtualBox のエージェントや NICドライバを入れる(入れ替える)ことで、ゲストからホストへの通信もできるようになるのかもしれません。しかし、「ブリッジ」というのであれば、ゲストに別の MACアドレスを割り当てて、外部から ARPに応えるようにする方がいいと思います。VirtualBox でできませんでしょうか？ (http://www.arubeh.com/archives/429 の図の箇所) ちなみに、ubuntu への通信で eth1 ではなく eth0 が使われたのは、arp_announce, arp_ignore あたりの設定によるものかもしれません。CentOS から見て、ubuntu からの ARP の応答が eth0 に先に到着したのかと。ubuntu のネットワーク構成がわからないので推測ですが。

tchofu

2015/09/20 23:47

お付き合いありがとうございます。１点修正させてください。ホストとゲストでMACアドレスは別です。紛らわしい情報ですいません。今、ホストOSのWindows VirtualBoxでNATを外して、ブリッジをアダプタ１、ホストオンリーネットワークアダプタを２（合計NIC 2枚）にしてやると、ホストOS(192.168.1.1)とゲストOS(192.168.1.101)でpingが通りました。この後、ホストOSのWindows VirtualBoxでNATを３枚目のNICに指しなおしてどうなるか試してみるつもりです。

tchofu

2015/09/21 01:01

どうやら解決したようですが、真の原因はよく判りません。直接の原因は、ゲストOSのCentOSにおけるNATとして使うNICの場所（あるいはブリッジで使うNICの場所）のようです。詳細は別途記します。お付き合いありがとうございました。