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

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

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

network-interface ping icmp

— Izzo
источник

Можете ли вы по-прежнему использовать ssh, пока он не отвечает на запросы? Или существующие сессии SSH заблокированы?

— Питер Кордес

@PeterCordes Вся система блокируется и по сути является кирпичом до принудительной перезагрузки.

— Иззо

Хорошо, это обычно единственный способ, которым машина перестает отвечать на пинг. Было бы странно, если бы ping перестали работать, но другие вещи продолжали работать, потому что обработка ping работает, даже если пользовательское пространство занято и все блокируется на дисках ввода-вывода на мертвый диск или монтируется NFS или что-то еще. Попробуйте подключить монитор к вашей системе и посмотреть, есть ли консольное сообщение, когда оно блокируется. (И если вы можете использовать волшебные последовательности клавиш SysRQ для выгрузки информации или перемонтирования только для чтения, принудительно синхронизируйте диски + перезагрузите компьютер.

— Питер Кордес

Хотя ваш вопрос интересен, ping - это не источник проблем вашей системы, а скорее следствие нестабильной системы. Проверьте логи, чтобы понять, что не так.

— Педро Лобито

@PedroLobito Что конкретно регистрирует?

— Иззо

Ответы:

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

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

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

— Патрик Мевзек
источник

@Outurnate любой другой тест службы приложения завершится неудачно или по истечении времени ожидания, поэтому наблюдаемый конечный результат будет таким же. Я никогда не упускаю возможности читать лекции против использования, так pingкак это создает слишком много ложных срабатываний при устранении неполадок, поэтому я думаю, что пользователи, не зная точно, что делает пинг и как он может давать ложные результаты, должны придерживаться чего-то другого.

— Патрик Мевзек

В большинстве ситуаций, связанных с перегрузкой, единственное, что все еще отвечает, это то, что сделано ядром. Это означает, что машина обычно отвечает на пинг независимо от того, насколько она перегружена. Попытки достигнуть закрытого порта ответят RST для TCP и ошибкой ICMP в случае UDP. И первые несколько попыток достичь открытого порта TCP завершат рукопожатие. Отказ диска может привести к почти таким же симптомам.

— kasperd

@kasperd Я видел (очень) перегруженные серверы (особенно меняющиеся), которые также не отвечают на запросы ICMP. И, конечно же, больше ничего. Ядро не зависало, оно было просто занято дисковым вводом / выводом.

— Патрик Мевзек

@Nacht Yup. Сетевой интерфейс - это аппаратное устройство; в качестве такового есть драйвер ядра для взаимодействия с ним. Затем второй уровень предоставляет общие API управления / связи. (Это не уникально для сетей: есть ALSA для разработчиков аудио, видео выходы используют KMS API, USB имеет HCI {U, E, X}, затем usb_storage, usbhid и т. Д.) Таблицы сетевой маршрутизации, правила брандмауэра (через iptables ), рукопожатие, сборка пакетов, повторная передача и т. д. все в ядре. Поскольку ICMP сам по себе является протоколом, без полезной нагрузки и без обработки, за исключением «отвечать или не делать», ядро обрабатывает ответы ICMP напрямую с минимальными издержками.

— февраля

@Nacht: Это не совсем о фундаментальной компьютерной архитектуре; это выбор реализации. Микроядра будут обрабатывать ICMP в процессе ОС.

— MSalters

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

— Outurnate
источник

Само ядро (не какой-либо пользовательский процесс) отвечает за отправку сообщений эхо-ответа 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)вспомогательных драйверов. Или вы можете изменить аппаратные части.

— Матия Налис
источник

Для заинтересованных, вот соответствующий код ядра для обработки эхо-запросов ICMP.

— Руслан

Вы должны также упомянуть очень высокую нагрузку (особенно процессор)

— Гильерме Бернал

@GuilhermeBernal нет, даже чрезмерно высокая пользовательская нагрузка на ЦП (в тысячах) не приведет к потере ICMP (потому что она подается в ядро, прежде чем пользовательские процессы получат возможность запуска). Чрезвычайно высокая скорость PPS в сети в сочетании с низкоуровневым оборудованием может привести к потере пакетов, но такая DDoS попадает в категорию «сетевых подключений»

— Матия Налис,