Какой процесс Linux отвечает за пинг?

У меня есть контроллер процесса на базе Linux, который иногда блокируется до точки, когда вы не можете пропинговать его (то есть я могу пропинговать его, тогда он перестает пинговаться без каких-либо изменений сетевых настроек).

Мне интересно, какой процесс / система отвечает за фактическое реагирование на пинги? Похоже, что этот процесс дает сбой.

Сетевой стек ядра обрабатывает сообщения ICMP, отправляемые pingкомандой.

Если вы не получаете ответы, кроме проблем с сетью или фильтрации, и фильтрацию на основе хоста / ограничение скорости / черный-холинг / и т.д. это означает, что машина, вероятно, перегружена чем-то, что может быть временным или сбой ядра, что происходит редко, но может произойти (неисправное оборудование и т. д.), не обязательно из-за трафика ICMP (но при попытке перегрузить его таким трафиком) может быть хорошим тестом в начале жизни сервера, чтобы увидеть, как он поддерживает вещи). В последнем случае сбоя ядра у вас должна быть достаточная информация в файлах журналов или на консоли.

Также обратите внимание, что pingэто почти всегда неправильный инструмент для проверки, работает ли сервис онлайн или нет. По разным причинам, но в основном потому, что по определению он не имитирует трафик реального приложения. Например, если вам нужно проверить, что веб-сервер все еще работает, вы должны вместо этого сделать HTTP-запрос к нему (TCP-порт 80 или 443), если вам нужно проверить почтовый сервер, вы делаете SMTP-запрос (TCP-порт 25), если DNS-сервер, UDP и TCP-запрос к порту 53 и т. д.

Не существует пользовательского процесса, отвечающего за пинг. Ping - это просто утилита для отправки эхо-пакетов ICMP. Они принимаются и обрабатываются сетевым стеком ядра

Само ядро ​​(не какой-либо пользовательский процесс) отвечает за отправку сообщений эхо-ответа ICMP в ответ на сообщения эхо-запроса ICMP . Таким образом, если хост перестает отвечать на эхо-запросы, это обычно происходит по следующим причинам:

• сетевое соединение между вами и хостом, на котором выполняется пинг, возможно, было прервано. Это может быть связано с множеством причин: физическим повреждением кабелей, шумом в случае беспроводного соединения, поврежденными таблицами маршрутов, тем, что вы подвергаетесь DDoS-атаке, проблемными маршрутизаторами / коммутаторами между ними и т. Д. В этом случае вы начнете устранять неполадки используя ethtool(8), iwconfig(8), route(8), ping(8)ее маршрутизатор, и tcpdump(8)т.д. на целевом хосте.

• Настройка брандмауэра на целевом хосте (или на любом маршрутизаторе / межсетевом экране между вами и целевым хостом) может ограничивать количество пингов (или объем трафика трафика). Это также может быть связано с такими инструментами, как fail2ban(8)брандмауэр по требованию. Смотрите, iptables(8)чтобы проверить.

• на целевом хосте произошла программная / аппаратная неисправность. Модуль сетевого ядра на целевом хосте может иметь OOPSed и / или запутаться, или даже целое ядро ​​может иметь PANICked. Вы увидите сообщения о входе в in dmesg(8)на целевом хосте или в виде вывода на экран физической консоли (если физический доступ нецелесообразен, может помочь другая машина с последовательной консолью .) Если проблема заключается в ядре OOPS / PANIC, более новое ядро ​​с лучшими драйверами может помочь, или вы можете обойти системные блокировки с помощью watchdog(8)вспомогательных драйверов. Или вы можете изменить аппаратные части.