Aneh: mengapa linux merespons ping dengan permintaan ARP setelah balasan ping terakhir?

12

Saya (dan seorang kolega) baru saja memperhatikan, dan menguji, bahwa ketika mesin Linux melakukan ping, setelah ping terakhir, ia memulai permintaan ARP unicast ke mesin yang memulai ping ICMP. Saat melakukan ping ke mesin Windows, mesin Windows tidak mengeluarkan permintaan ARP di akhir.

Adakah yang tahu apa tujuan permintaan ARP unicast ini, dan mengapa itu terjadi di Linux dan bukan pada Windows?

Jejak Wireshark (dengan 10.20.30.45 menjadi kotak 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

Pembaruan: Saya baru saja mencari lebih banyak di Google untuk permintaan ARP unicast , dan satu-satunya referensi berguna yang saya temukan adalah di RFC 4436 yaitu tentang "Mendeteksi Lampiran Jaringan" (dari 2006). Teknik ini menggunakan ARP unicast untuk memungkinkan host untuk menentukan apakah itu terhubung kembali ke jaringan yang sebelumnya dikenal. Tapi saya tidak melihat bagaimana ini berlaku untuk permintaan ARP sebagai hasil dari melakukan ping. Jadi misterinya tetap ...

— Rabarberski
sumber

4

Linux mengirimkan berbagai permintaan ARP unicast untuk memperbarui cache ARP-nya. Ini untuk mencegah entri cache ARP basi (dan berpotensi berbahaya).

Ada beberapa situasi di mana ARP unicast digunakan, pada dasarnya untuk memvalidasi cache ARP. Jika entri basi, maka fallback adalah untuk menyiarkan ARP.

Ini dibahas dalam RFC1122 2.3.2.1

Saya pikir itulah yang dilakukannya, mengapa, tebakan pertama saya adalah semacam tindakan anti spoofing. Paket ARP selalu tidak pernah dialihkan, jadi saya anggap Anda melakukan ini pada LAN lokal Anda? Apakah situasi ini terjadi secara konsisten setiap kali Anda melakukan ping host atau Anda hanya melacak satu kali? Dalam hal ini, cache ARP untuk host itu mungkin kehabisan waktu secara kebetulan.

OS apa yang dijalankan pada host tempat Anda melakukan ping mesin?

— Philip Reynolds
sumber

Terima kasih atas tautan RFC. Saya pikir time-out adalah cara default untuk menghilangkan entri arp lama dan menjaga ukuran cache arp terbatas. Yang terakhir tampaknya tidak dilakukan dengan melakukan unicast ARP (tapi mungkin ada batas waktu juga). Kami telah mengujinya pada LAN lokal yang diuji 3 kali (dua kali dari mesin Linux dan sekali dari mesin WinXP). Saya juga telah menguji ini pada LAN 'asli' dengan melakukan ping dari PC saya (WinXP) ke VMWare Ubuntu 9.04 yang berjalan di PC saya. Hasil yang sama, waktu yang sama (2 detik).

— Rabarberski

Apakah Anda memiliki tautan ke klaim 'Linux mengirim berbagai permintaan ARP unicast ...'?

— Rabarberski

Saya tidak yakin, tapi itu terlihat seperti penanggulangan spoofing arp. Tapi saya bertanya-tanya seberapa efektif ini, maksud saya, alamat MAC digunakan untuk beralih frame ethernet, menggunakan pesan unicast akan membuatnya langsung ke mesin terakhir dari dengan tujuan mac berasal dari ...

— Hubert Kario

1

Saya pikir itu bug. Jejak berikut dari ping ke alamat yang ada di cache ARP tetapi basi. Saya tidak bisa memikirkan alasan bagus untuk unicast ARP dua kali dalam waktu singkat. Ini dengan 4.14.15 tetapi saya telah melihat perilaku pada banyak versi kernel.

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

— Tony
sumber

Menurut saya sepertinya kedua belah pihak memeriksa validitas cache ARP mereka; kedua simpang susun itu berada di arah yang berlawanan, dan entri mereka pada dasarnya adalah usia yang sama, sehingga waktu habis dan diperiksa pada waktu yang sama.

— Dicuri

-1

Hanya tebakan .. tapi ini bisa menjadi 'fitur' untuk mencatat alamat MAC klien kapan pun mesin menjawab serangkaian ping atau sejumlah ping. Ini bisa menjadi informasi yang berguna untuk melacak spam ping.

— Chris Nava
sumber

Tetapi 'fitur' ini tidak perlu mengirimkan permintaan ARP, karena mesin spam telah bisa mengekstraksi alamat MAC dari permintaan ping ICMP.

— Rabarberski