web-dev-qa-db-ja.com

192.168.0.146からicmp_seq = 1宛先ホストに到達できません

root@prateek-desktop:~# ping 192.168.0.1 
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
From 192.168.0.146 icmp_seq=1 Destination Host Unreachable
From 192.168.0.146 icmp_seq=2 Destination Host Unreachable
From 192.168.0.146 icmp_seq=3 Destination Host Unreachable

root@prateek-desktop:~# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1

Pingできない理由としては何が考えられますか？

ファイアウォールが無効になっています...

192.168.0.1は、DHCPが有効になっているワイヤレスルーターのIPアドレスです。そのルーターへのイーサネットポートには、DHCPによって割り当てられたIPアドレスがあります。私のPCのIPアドレスは192.168.0.146です。ルーターとPCの両方が同じネットワークを使用しています。私のPCでは、ネットワーク設定にデフォルトゲートウェイが192.168.0.146として割り当てられています。他のデバイスは私のPCをpingできますが、私のPCは、自分のPCが直接接続されているルーターを含む他のデバイスをpingできません。

ubuntunetworkingpingcisco
2
prateek manocha

[編集]他のデバイスは私のPCにpingできますが、私のPCは、自分のPCが直接接続されているルーターを含む他のデバイスにpingできません。

別のデバイスで競合するIPアドレスを確認します。

（あなたのpingの結果がこれと一致するかどうかはわかりませんが、ARPに関する私の直感とは完全に一致しません。残念ながら、Google検索結果で同様の組み合わせを見つけられませんでした。おそらく別の問題があるでしょう。または別の問題ですが、確認するのは良いことであり、手掛かりを見つけるのに役立つ場合があります）。

PCで、MACアドレス（「ハードウェアアドレス」）を見つけます。 ip link show dev eth1を実行すると、MACアドレスはlink/etherの後に表示される値になります。

他のデバイスの1つで、IPにキャッシュされているMACアドレス192.168.0.146を慎重に確認します。他のデバイスがLinuxを実行している場合は、ip -4 neighを使用してARPキャッシュを確認できます。他のデバイスがWindowsを実行している場合は、arp -aを使用してARPキャッシュを確認できます（ Windowsコマンドライン 内）。 IP 192.168.0.146に別のMACアドレスが表示される場合は、実際にはPCではなく別のデバイスにpingを送信していました:-)。

前のバージョン：

Pingを実行できない理由として何が考えられますか？

AfroJoe：非常に多くの理由

技術的には、pingに「Destination Host Unreachable」と表示されるのは、かなり具体的なエラーメッセージです。出力はほぼ確実にARP解決が失敗していることを意味します。 192.168.0.146。これはpingを実行したコンピュータと同じで、後で編集するときに確認しました。その場合、ARPの問題を確認する方法は次のとおりです。

$ ping 172.16.8.2
PING 172.16.8.2 (172.16.8.2) 56(84) bytes of data.
From 172.16.8.205 icmp_seq=1 Destination Host Unreachable
From 172.16.8.205 icmp_seq=2 Destination Host Unreachable
From 172.16.8.205 icmp_seq=3 Destination Host Unreachable
^C
--- 172.16.8.2 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3050ms
pipe 4

$ ip -4 neigh
172.16.8.1 dev wlp2s0 lladdr 74:44:01:86:42:d6 REACHABLE
172.16.8.2 dev wlp2s0  INCOMPLETE

成功するARP解決には、次のような交換が含まれます。

$ Sudo tcpdump -n -i wlp2s0 arp or icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
...
13:43:49.469349 ARP, Request who-has 172.16.8.1 tell 172.16.8.205, length 28
13:43:49.470046 ARP, Reply 172.16.8.1 is-at 74:44:01:86:42:d6, length 28
13:43:49.852608 IP 172.16.8.205 > 172.16.8.1: ICMP echo request, id 5246, seq 21, length 64
13:43:49.854600 IP 172.16.8.1 > 172.16.8.205: ICMP echo reply, id 5246, seq 21, length 64
13:43:50.853879 IP 172.16.8.205 > 172.16.8.1: ICMP echo request, id 5246, seq 22, length 64
13:43:50.855867 IP 172.16.8.1 > 172.16.8.205: ICMP echo reply, id 5246, seq 22, length 64
^C
18 packets captured
18 packets received by filter
0 packets dropped by kernel

（pingの実行中に観察され、ip neigh flush dev wlp2s0を使用してARPを強制的に更新します）。

注：この解釈は基本的にpingにのみ適用されます。 sshやcurlなどの「通常の」TCP/IPアプリケーションから「Host Unreachable」メッセージを受け取った場合は適用されません。これは、次のようなICMPエラー応答を受け取ったことを意味する場合もあります。 「管理上禁止されています」（ファイアウォールから）。ただし、pingはICMP応答全体を受信して​​デコードします。したがって、pingは、エラーがjust "Host Unreachable"ではなく、具体的には "管理上禁止されている"ことを示します。

また、このQ＆AはIPv4に関するものです。 IPv6にどのように適応できるかは確認していません。

ARP解決が失敗するのはなぜですか？

AfroJoe：非常に多くの理由

私にはもう1つの秘密の知識があります。 Ubuntuクライアントシステムが意図的に誰かによって構成されていない限り、アドレス192.168.0.146はDHCPパケットの交換を通じて割り当てられました。通常、この交換にはルーターが含まれますが、Windowsサーバーまたはその他の種類のサーバーのみが含まれる場合もあります。 ルーターがDHCPサーバーまたはリレーであるこの場合、システムはすでに交換できましたいくつかルーターとのパケット。

接続を切断して再作成することで、DHCP交換の再トリガーをテストできます。[*]もちろん、問題が「ランダムに」再発し続ける場合、これを行っても根本的な問題は解決されないため、調査することをお勧めします。まだ壊れている間の接続。

（[*] Appleは、DHCP交換を実行できる最適化を記述しました after特定のARPパケットの交換 。たぶん、新しい癖があるこれで、Linuxでの使用はまだ見ていません。）

DHCPとWiFiを使用した接続でこのエラーが発生するのは、ワイヤレス信号がどこかで失われた場合によく見られることです。 （そして、ワイヤレスレイヤーが完全に放棄する前に、あなたはそれをキャッチします...なぜ私がそんなに何度もこれまで見たのかはわかりません、おそらく私はバグのあるシステムまたは不適切に書かれたシステムを観察していました）。ただし、eth1はWiFi接続ではありません。

DHCP for IPv4は、ARPを必要とせずに動作すると思います。少なくとも最初のDHCP交換では。

残りの可能性

あなたの質問の最初のバージョンの事実から、私は特に一般的な個々のシナリオを考えるのに苦労しました。 （私の暗黙の仮定を含みます。誰かがtryingなしでこの質問を投稿して、コンピューターを操作可能なルーターに接続することはありません）。

  • 接続しているネットワークには、アドレス192.168.0.1のデバイスがありません。それがDHCPアドレスを与えたものである場合、それはネットワークから削除されました。接続されていない、またはちょうど死んだ。
  • Eth1を手動で構成し、かつ
    • ubuntuデスクトップでNetworkManagerを使用していない、および
      • 実際にはイーサネットリンクが検出されていません（ethtoolを確認してください）。
      • または、イーサネットリンクが検出されましたが、スイッチでは 802.1X を使用してパスワードまたはその他の認証を提供する必要があります。
      • または、イーサネットリンクが検出されましたが、コンピュータのMACアドレスをネットワーク管理者に登録する必要があります。
    • リンクを検出するのに十分に機能するが、データパケットを確実に伝送するのに十分ではないケーブルがあります。
5
sourcejedi

150億の理由の1つが考えられます。それらのいくつかを以下に示します。

  • デスクトップのネットワーク構成の問題。 （適切なゲートウェイをセットアップしましたか？）
  • Pingに応答しないように構成されたターゲットシステムのファイアウォール
  • ネットワークに接続している不良なネットワークケーブル
  • システムに他のホストからのICMP応答をブロックするファイアウォールルールがあります
  • ファイアウォール構成はネットワーク全体でICMPを除外します（スイッチ構成を含む）

問題はjustで提供される情報で、それ以上の診断を行う方法がまったくないため、この質問が「広すぎる」（フラグが立てられている）ことです。

2
Thomas Ward