Jaki proces Linux jest odpowiedzialny za reagowanie na pingi?

Mam kontroler procesów oparty na systemie Linux, który czasami blokuje się do momentu, w którym nie można go pingować (tzn. Mogę pingować, a następnie przestaje być dostępny do pingowania bez modyfikacji ustawień sieciowych).

Jestem ciekawy, jaki proces / system jest odpowiedzialny za faktyczne reagowanie na pingi? Wygląda na to, że ten proces ulega awarii.

network-interface ping icmp

— Izzo
źródło

Czy możesz nadal ssh w to, gdy nie reaguje na pingi? A może istniejące sesje SSH blokują się?

— Peter Cordes

@PeterCordes Cały system blokuje się i jest zasadniczo cegłą, dopóki nie wymusi ponownego uruchomienia.

— Izzo

Ok, to zwykle jedyny sposób, w jaki maszyna przestanie reagować na pingi. Byłoby dziwnie, gdyby ping przestał działać, ale działały inne rzeczy, ponieważ obsługa ping działa nawet wtedy, gdy przestrzeń użytkownika jest zamknięta i wszystko jest zablokowane na wejściu / wyjściu dysku do martwego dysku lub montowania NFS lub cokolwiek innego. Spróbuj podłączyć monitor do systemu i sprawdź, czy podczas zamykania się pojawia się komunikat konsoli. (A jeśli można użyć sekwencji magia sysrq klawiaturowych do informacji zrzutu lub Remount tylko do odczytu, force-Sync dyski + restart.

— Peter Cordes

Chociaż twoje pytanie jest interesujące, ping nie jest źródłem problemów twojego systemu, ale raczej konsekwencją niestabilności systemu. Sprawdź dzienniki, aby zrozumieć, co jest nie tak.

— Pedro Lobito,

@PedroLobito Co konkretnie loguje?

— Izzo

Odpowiedzi:

Stos sieciowy jądra obsługuje komunikaty ICMP, które są wysyłane przez pingpolecenie.

Jeśli nie otrzymasz odpowiedzi, oprócz problemów z siecią lub filtrowania oraz filtrowania na podstawie hosta / ograniczania prędkości / czarnego holowania / itp. oznacza to, że maszyna jest prawdopodobnie przeciążona przez coś, co może być przejściowe, lub jądro uległo awarii, co jest rzadkie, ale może się zdarzyć (wadliwy sprzęt itp.), niekoniecznie z powodu ruchu ICMP (ale próba przeciążenia go takim ruchem) może być dobrym testem na początku życia serwera, aby sprawdzić, jak to podtrzymuje). W późniejszym przypadku awarii jądra powinieneś mieć dużo informacji w plikach dziennika lub na konsoli.

Pamiętaj też, że pingprawie zawsze jest to niewłaściwe narzędzie do sprawdzania, czy usługa jest online, czy nie. Z różnych powodów, ale głównie dlatego, że z definicji nie naśladuje on rzeczywistego ruchu aplikacji. Na przykład, jeśli chcesz sprawdzić, czy serwer WWW nadal działa, powinieneś zamiast tego wykonać zapytanie HTTP (port TCP 80 lub 443), jeśli chcesz sprawdzić serwer poczty, wykonaj zapytanie SMTP (port TCP 25), jeśli serwer DNS, zapytanie UDP i zapytanie TCP do portu 53 itp.

— Patrick Mevzek
źródło

@ Wyłączanie innego testu usługi aplikacji zakończy się niepowodzeniem lub upłynie limit czasu, więc obserwowany wynik końcowy będzie taki sam. Nigdy nie przepuszczam okazji, by wygłaszać wykład przeciwko używaniu, pingponieważ powoduje to zbyt wiele fałszywie pozytywnych problemów w rozwiązywaniu problemów, więc myślę, że użytkownicy nie wiedzący dokładnie, co robi ping i jak może dać mylące wyniki, powinni trzymać się czegoś innego.

— Patrick Mevzek,

W większości przypadków przeciążenia jedynymi czynnikami, które nadal reagują, są czynności wykonywane przez jądro. Oznacza to, że komputer zazwyczaj reaguje na ping, niezależnie od tego, jak jest przeciążony. Próby osiągnięcia zamkniętego portu odpowiedzą RST dla TCP i błędem ICMP w przypadku UDP. Pierwsze kilka prób dotarcia do otwartego portu TCP zakończy uzgadnianie. Awaria dysku może prowadzić do prawie takich samych objawów.

— kasperd

@kasperd Widziałem (bardzo) przeciążone serwery (szczególnie te wymieniające się), które nie odpowiadają również na żądania ICMP. I oczywiście do niczego innego. Jądro nie uległo awarii, było po prostu zajęte przez operacje wejścia / wyjścia na dysku.

— Patrick Mevzek

@Nacht Yup. Interfejs sieciowy jest urządzeniem sprzętowym; jako taki istnieje sterownik jądra do współpracy z nim. Druga warstwa zapewnia ogólne interfejsy API do zarządzania / komunikacji. (Nie dotyczy to sieci: ALSA dla twórców audio, wyjścia wideo używają KMS API, USB ma {U, E, X} HCI, następnie usb_storage, usbhid itp.) Tabele routingu sieciowego, reguły zapory ogniowej (przez iptables ), uzgadnianie, składanie pakietów, retransmisje itp. są wbudowane w jądro. Ponieważ ICMP jest protokołem samym w sobie, bez ładunku i bez przetwarzania poza „odpowiedz albo nie”, jądro obsługuje odpowiedzi ICMP bezpośrednio w celu minimalnego obciążenia.

— FeRD

@Nacht: Tak naprawdę nie chodzi o podstawową architekturę komputerową; to wybór implementacji. Mikrojądra będą obsługiwać ICMP w procesie systemu operacyjnego.

— MSalters

Nie ma procesu użytkownika odpowiadającego na pingi. Ping to tylko narzędzie do wysyłania pakietów echa ICMP. Są one odbierane i przetwarzane przez stos sieciowy jądra

— Outurnate
źródło

Samo jądro (nie żaden proces użytkownika) odpowiada za wysyłanie komunikatów odpowiedzi echa ICMP w odpowiedzi na komunikaty żądania echa ICMP . Tak więc, jeśli host przestaje odpowiadać na pingi, zwykle dzieje się tak z następujących powodów:

połączenie sieciowe między tobą a hostowanym pingiem mogło zostać zerwane. Może to wynikać z wielu powodów: fizycznego uszkodzenia kabli, szumu w przypadku sieci bezprzewodowej, zepsutych tablic tras, narażenia się na atak DDoS, problematycznych routerów / przełączników między nimi itp. Rozpocznij rozwiązywanie problemów w tym przypadku przez za pomocą ethtool(8), iwconfig(8), route(8), ping(8)swój router, tcpdump(8)itp na hosta docelowego.
ustawienie zapory na hoście docelowym (lub dowolnym routerze / zaporze między tobą a hostem docelowym) może ograniczać ilość pingów (lub natężenie ruchu). Może to być również spowodowane narzędziami takimi jak fail2ban(8)zapora ogniowa na żądanie. Zobacz, iptables(8)aby sprawdzić.
wystąpiła awaria oprogramowania / sprzętu na hoście docelowym. Moduł jądra sieciowego na hoście docelowym mógł zostać OOPSed i / lub zostać zdezorientowany, a nawet całe jądro mogło mieć błąd PANICked. Zobaczysz komunikaty o wejściu dmesg(8)na hoście docelowym lub jako dane wyjściowe ekranu na konsoli fizycznej (jeśli fizyczny dostęp jest niepraktyczny, może pomóc inna maszyna z konsolą szeregową .) Jeśli problem stanowi jądro OOPS / PANIC, nowsze jądro z lepszymi sterownikami może pomoc lub możesz krążyć wokół blokad systemu ze watchdog(8)sterownikami pomocniczymi. Lub możesz zmienić części sprzętu.

— Matija Nalis
źródło

Dla zainteresowanych, oto odpowiedni kod jądra do obsługi żądań echa ICMP.

— Ruslan,

należy również wspomnieć o bardzo dużym obciążeniu (szczególnie procesorach)

— Guilherme Bernal,

@ GuilhermeBernal nie, nawet wyjątkowo wysokie obciążenie procesora użytkownika (w tysiącach) nie doprowadzi do utraty ICMP (ponieważ jest obsługiwany w jądrze, zanim procesy użytkownika będą miały szansę uruchomić). Ekstremalnie wysoka sieć stawka PPS w połączeniu z niskim sprzętu końcowego może spowodować utratę pakietów, ale takie DDoS spada w kategorii „sieć łączności”

— Matija Nalis