Dziwne: dlaczego Linux reaguje na ping z żądaniem ARP po ostatniej odpowiedzi ping?

12

Ja (i mój kolega) właśnie zauważyłem i przetestowałem, że kiedy pingowany jest komputer z systemem Linux, po ostatnim pingowaniu inicjuje żądanie ARP emisji pojedynczej do komputera, który zainicjował ping ICMP. Podczas pingowania na komputer z systemem Windows komputer z systemem Windows nie wydaje żądania ARP na końcu.

Czy ktoś wie, jaki jest cel tego żądania ARP emisji pojedynczej i dlaczego występuje on w systemie Linux, a nie w systemie Windows?

Śledzenie Wireshark (10.20.30.45 to 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

Aktualizacja: Właśnie przeszukałem trochę więcej w przypadku żądań ARP emisji pojedynczej , a jedynym przydatnym odniesieniem, które znalazłem, jest RFC 4436, który dotyczy „Wykrywania przywiązania sieciowego” (z 2006 r.). Ta technika wykorzystuje ARP emisji pojedynczej, aby umożliwić hostowi ustalenie, czy jest on ponownie podłączony do poprzednio znanej sieci. Ale nie rozumiem, jak to odnosi się do żądania ARP w wyniku wykonania polecenia ping. Więc tajemnica pozostaje ...

— Rabarberski
źródło

4

Linux wysyła różne żądania ARP emisji pojedynczej w celu zaktualizowania pamięci podręcznej ARP. Ma to na celu zapobieganie nieaktualnym (i potencjalnie złośliwym) wpisom pamięci podręcznej ARP.

Istnieje kilka sytuacji, w których używa się ARP emisji pojedynczej, w zasadzie do sprawdzania pamięci podręcznej ARP. Jeśli wpis jest nieaktualny, awaryjne jest nadawanie ARP.

Jest to omówione w RFC1122 2.3.2.1

Myślę, że właśnie tak się dzieje, dlatego po raz pierwszy podejrzewam, że to jakiś środek zapobiegający fałszowaniu. Pakiety ARP nigdy nie są routowane, więc przypuszczam, że robisz to w lokalnej sieci LAN? Czy ta sytuacja zdarza się konsekwentnie za każdym razem, gdy pingujesz hosta, czy tylko raz go prześledziłeś? W takim przypadku pamięć podręczna ARP dla tego hosta mogła przekroczyć limit czasu przypadkowo.

Z jakiego systemu operacyjnego działa host, z którego pingowany jest komputer?

— Philip Reynolds
źródło

Dzięki za link RFC. Myślałem, że limity czasu są domyślnym sposobem na pozbycie się starych wpisów arp i ograniczenie rozmiaru pamięci podręcznej arp. Wydaje się, że to ostatnie nie odbywa się przez wykonanie ARP emisji pojedynczej (ale może również upłynął limit czasu). Przetestowaliśmy to na lokalnej testowanej sieci LAN 3 razy (dwa razy z komputera z systemem Linux i raz z komputera z systemem WinXP). Przetestowałem to również w „prawdziwej” sieci LAN, wysyłając ping z mojego komputera (WinXP) do VMWare Ubuntu 9.04 działającego na moim komputerze. Ten sam wynik, ten sam czas (2 sekundy).

— Rabarberski

Czy masz link do roszczenia „Linux wysyła różne żądania ARP emisji pojedynczej ...”?

— Rabarberski

Nie jestem pewien, ale wygląda to na przeciwdziałanie fałszowaniu arpów. Zastanawiam się jednak, jak to jest skuteczne, to znaczy adresy MAC są używane do przełączania ramek ethernetowych, użycie komunikatu emisji pojedynczej sprawi, że przejdzie ono prosto do ostatniej maszyny z docelowym komputerem Mac pochodzącym z ...

— Hubert Kario

1

Myślę, że to błąd. Poniższy zapis pochodzi z polecenia ping na adres, który znajduje się w pamięci podręcznej ARP, ale jest nieaktualny. Nie mogę wymyślić żadnego dobrego powodu do dwukrotnego przeniesienia ARP w tak krótkim czasie. Tak jest z 4.14.15, ale widziałem zachowanie wielu wersji jądra.

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
źródło

Wydaje mi się, że obie strony sprawdzają ważność swoich pamięci podręcznych ARP; te dwie węzły przesuwały się w przeciwnych kierunkach, a ich zapisy byłyby w zasadzie w tym samym wieku, więc zatrzymaj się i sprawdź w tym samym czasie.

— stolenmoment

-1

Tylko zgadnij .. ale może to być „funkcja” do rejestrowania adresu MAC klienta, ilekroć urządzenie odbiera serię pingów lub określoną liczbę pingów. Może to być przydatne informacje do śledzenia spamu ping.

— Chris Nava
źródło

Ale ta „funkcja” nie wymagałaby wysłania żądania ARP, ponieważ spamowany komputer mógł już wyodrębnić adres MAC z żądania ping ICMP.

— Rabarberski