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

Question

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

解決済

回答 3

投稿 2015/09/19 22:41 ・編集 2015/09/20 09:55

評価
クリップ 1
VIEW 31K+

tchofu

score 87

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（２）を使うようになっている

          0.0.0.0          0.0.0.0     192.168.11.1     192.168.11.3    276
      192.168.1.0    255.255.255.0            リンク上       192.168.1.1    266
      192.168.1.1  255.255.255.255            リンク上       192.168.1.1    266
      192.168.1.2  255.255.255.255            リンク上       192.168.1.1    266
    192.168.1.255  255.255.255.255            リンク上       192.168.1.1    266
（中略）
          0.0.0.0          0.0.0.0     192.168.11.1     既定

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

[devel@devel sysconfig]$ sudo route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.56.0    0.0.0.0         255.255.255.0   U     0      0        0 eth2
0.0.0.0         10.0.2.2        0.0.0.0         UG    0      0        0 eth0

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

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

sudo tcpdump icmp -i lo
sudo tcpdump icmp -i eth0
sudo tcpdump icmp -i eth1
sudo tcpdump icmp -i eth2
sudo 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にしています。

気になる質問をクリップする

クリップした質問は、後からいつでもマイページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

クリップを取り消します
良い質問の評価を上げる

以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します

評価を下げられる数の上限に達しました

評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる

teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 過去に投稿した質問と同じ内容の質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します

この機能は開放されていません

評価を下げる条件を満たしてません

評価を下げる理由を選択してください
プログラミングに関係のない質問やってほしいことだけを記載した丸投げの質問問題・課題が含まれていない質問意図的に内容が抹消された質問過去に投稿した質問と同じ内容の質問広告と受け取られるような投稿
詳細な説明はこちら

上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。
質問の評価を下げる機能の利用条件

この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
- メールアドレスの認証
  メールアドレスの認証
- 質問評価に関するヘルプページの閲覧
  質問評価に関するヘルプページの閲覧

回答 3 件

評価が高い順
新着順
古い順

0

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

投稿 2015/09/20 08:32

回答の評価を上げる

以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
回答の評価を下げる

下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

2015/09/20 09:09

コメントありがとうございます。

ホストOS／ゲストOSともにファイヤーウォールは止めているんです。

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

キャンセル

0

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

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

問題箇所と解決方法

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

pingが通らない

Windows:

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

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

ping OK

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

Windows:

ブリッジアダプタ（★ココがポイント）
ホストオンリーネットワークアダプタ
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 10:25

回答の評価を上げる

以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
回答の評価を下げる

下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

同じタグがついた質問を見る

score 0 · Accepted Answer · 2015-09-20T00:20

ベストアンサー

0

ホスト側の 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/20 00:20

回答の評価を上げる

以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
回答の評価を下げる

下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

2015/09/20 07:39 編集

アドバイスありがとうございます。

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パケットが出ていないように見えます。

アドバイスありがとうございます。 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パケットが出ていないように見えます。

キャンセル
2015/09/20 08:24

追加情報です。

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

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

キャンセル
2015/09/20 09: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

追加情報です。仮想マシンを再起動した（他に使う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

キャンセル
2015/09/20 09: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が通る

追加情報です。問題が起きている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が通る

キャンセル
2015/09/20 23: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 のネットワーク構成がわからないので推測ですが。

ホストとゲストで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 のネットワーク構成がわからないので推測ですが。

キャンセル
2015/09/21 08:47

お付き合いありがとうございます。

１点修正させてください。
ホストとゲストでMACアドレスは別です。紛らわしい情報ですいません。
今、ホストOSのWindows VirtualBoxでNATを外して、ブリッジをアダプタ１、ホストオンリーネットワークアダプタを２（合計NIC 2枚）にしてやると、ホストOS(192.168.1.1)とゲストOS(192.168.1.101)でpingが通りました。

この後、ホストOSのWindows VirtualBoxでNATを３枚目のNICに指しなおしてどうなるか試してみるつもりです。

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

キャンセル
2015/09/21 10:01

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

詳細は別途記します。
お付き合いありがとうございました。

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

キャンセル
2019/06/22 14:20

同じような症状に悩まされていて、自分の場合は無線LANルータのクライアントアイソレーション（プライバシーセパレータ）が原因でした。

同じような症状に悩まされていて、自分の場合は無線LANルータのクライアントアイソレーション（プライバシーセパレータ）が原因でした。

キャンセル

質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう！

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

PC環境

ホストOS

ゲストOS

現象

ここまでの調査結果

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

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

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

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

問題箇所と解決方法

pingが通らない

ping OK

ご参考

補足

関連した質問

同じタグがついた質問を見る

質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう！

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

PC環境

ホストOS

ゲストOS

現象

ここまでの調査結果

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

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

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

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

問題箇所と解決方法

pingが通らない

ping OK

ご参考

補足

15分調べてもわからないことは、teratailで質問しよう！

関連した質問

同じタグがついた質問を見る

SNSアカウントでログイン

teratailアカウントでログイン