web-dev-qa-db-ja.com

奇妙なことに、Linuxが最後のping応答の後にARP要求でpingに応答するのはなぜですか？

私（および同僚）は、Linuxマシンにpingを実行すると、最後のpingの後にunicastARP要求を開始することに気づき、テストしましたICMPpingを開始したマシン。 Windowsマシンにpingを実行すると、Windowsマシンは最後にARP要求を発行しません。

このユニキャストARPリクエストの目的は何か、そしてそれがWindowsではなくLinuxで発生する理由を誰かが知っていますか？

Wiresharkトレース（10.20.30.45はLinuxボックス）：

No.Time        Source           Destination      Prot  Info
19 10.905277   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
20 10.905339   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
21 11.904141   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
22 11.904173   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
23 12.904104   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
24 12.904137   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
25 13.904078   10.20.30.14      10.20.30.45      ICMP  Echo (ping) request
26 13.904111   10.20.30.45      10.20.30.14      ICMP  Echo (ping) reply
27 15.901799   D-Link_c5:e7:ea  D-Link_33:cb:92  ARP   Who has 10.20.30.14?  Tell 10.20.30.45
28 15.901855   D-Link_33:cb:92  D-Link_c5:e7:ea  ARP   10.20.30.14 is at 00:05:5d:33:cb:92

更新：ユニキャストARPリクエストをもう少しググったところ、唯一の便利なリファレンス私が見つけたのは RFC 4436 で、これは「ネットワーク接続の検出」（2006年から）に関するものです。この手法では、ユニキャストARPを使用して、ホストが既知のネットワークに再接続されているかどうかを判断できるようにします。しかし、pingを実行した結果としてこれがARP要求にどのように適用されるかはわかりません。だから謎は残っている...

linuxkernelpingarpicmp
12
Rabarberski

Linuxは、さまざまなユニキャストARP要求を送信して、そのARPキャッシュを更新します。これは、古い（そして潜在的に悪意のある）ARPキャッシュエントリを防ぐためです。

基本的にARPキャッシュを検証するために、ユニキャストARPが使用される状況がいくつかあります。エントリが古くなっている場合、フォールバックはARPをブロードキャストすることです。

これについては RFC1122 2.3.2.1で説明しています。

私はそれがそれがしていることだと思います、なぜ、私の最初の推測はある種のなりすまし対策であるでしょう。 ARPパケットは常にルーティングされることはないので、ローカルLANでこれを行っていると思いますか？この状況は、ホストにpingするたびに一貫して発生するのですか、それとも1回トレースしただけですか？その場合、そのホストのARPキャッシュが偶発的にタイムアウトした可能性があります。

マシンにpingを実行しているホストで実行されているOSは何ですか？

4
Philip Reynolds

バグだと思います。次のトレースは、pingから、ARPキャッシュにあるが古くなっているアドレスへのトレースです。 nicast ARPをこんなに短い時間で2回する理由は考えられません。これは4.14.15の場合ですが、多くのカーネルバージョンで動作を確認しました。

root@observer:~# tcpdump -nevi eth0 arp
device eth0 entered promiscuous mode
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

13:11:57.362910 42:5f:03:40:00:43 > 42:5f:03:40:00:22, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.2.1 tell 10.1.2.2, length 28
13:11:57.363018 42:5f:03:40:00:22 > 42:5f:03:40:00:43, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.1.2.1 is-at 42:5f:03:40:00:22, length 28
13:11:57.392890 42:5f:03:40:00:22 > 42:5f:03:40:00:43, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.1.2.2 tell 10.1.2.1, length 28
13:11:57.393049 42:5f:03:40:00:43 > 42:5f:03:40:00:22, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 10.1.2.2 is-at 42:5f:03:40:00:43, length 28
1
Tony