ICMP: что это такое, как работает и как проверить сервер — инструкция для новичка

Что такое ICMP простыми словами

ICMP (Internet Control Message Protocol, «протокол управляющих сообщений в интернете») — служебный протокол, который сообщает об ошибках и проверяет, отвечает ли узел. Он описан в RFC 792 в 1981 году и имеет номер 1 в заголовке IP (Internet Protocol). Это один из базовых сетевых протоколов, на которых держится интернет.

ICMP не передаёт пользовательские данные: ни страницы сайтов, ни файлы, ни почту. Он работает на сетевом уровне, как и IP, поэтому портов у него нет. Порты есть только у TCP (Transmission Control Protocol) и UDP (User Datagram Protocol).

Допустим, ваш компьютер обращается к серверу 203.0.113.10. Если маршрут оборван, ближайший маршрутизатор вернёт сообщение «адресат недоступен». Если вы выполните ping 203.0.113.10, сервер ответит коротким пакетом: в Windows он занимает 32 байта, в Linux — 64 байта вместе с заголовком ICMP. Как узлы находят друг друга, объясняет материал про IP-адрес.

Протокол решает три основные задачи:

• проверяет, отвечает ли узел на запросы;
• сообщает, что адресат недоступен;
• предупреждает, что время жизни пакета истекло.

Как работает ICMP и какие типы сообщений бывают

ICMP (Internet Control Message Protocol) не переносит данные пользователя, а сообщает об ошибках и проверяет связь. Его сообщение упаковано внутрь IP-пакета, а в заголовке IP номер протокола равен 1. Портов у ICMP нет: он работает на сетевом уровне, поэтому разрешать или запрещать нужно тип сообщения, а не порт.

Каждый узел на пути уменьшает TTL (time to live, время жизни) пакета на 1. Когда значение доходит до 0, маршрутизатор отбрасывает пакет и возвращает отправителю сообщение типа 11. Traceroute использует это: отправляет пакеты с TTL 1, 2, 3 и так до 30, и каждый узел по очереди выдаёт себя.

Если пакет слишком большой, узел отвечает типом 3 с кодом 4 («требуется фрагментация»), так определяют MTU пути (RFC 1191). Блокировка этих ответов вызывает зависания соединений. Как адреса делятся на сети, объясняет материал про маску сети, а свой адрес в интернете покажет проверка внешнего IP-адреса.

Обмен при команде ping 203.0.113.10 выглядит так:

1. Клиент отправляет серверу echo-запрос (тип 8).
2. Маршрутизаторы по пути уменьшают TTL на 1.
3. Сервер возвращает echo-ответ (тип 0).
4. Клиент показывает время обмена в миллисекундах.

Как проверить сервер по ICMP: ping и traceroute пошагово

Проверка занимает пару минут и не требует установки программ: ping и traceroute есть в Windows, Linux и macOS. Команда ping показывает, отвечает ли узел и сколько времени идёт пакет. Команда traceroute выводит путь пакета по промежуточным узлам.

Ниже в примерах используется адрес 203.0.113.10. Подставьте IP-адрес своего сервера. Если сервер удалённый, для проверки с него понадобится SSH (Secure Shell), подробности есть в материале о подключении через PuTTY.

Выполните шаги по порядку, каждый даёт данные для следующего:

1. Откройте терминал. В Windows запустите cmd или PowerShell, в Linux и macOS откройте Terminal. Для удалённого сервера сначала подключитесь по SSH.
2. Запустите ping. В Windows введите ping 203.0.113.10: команда отправит 4 пакета по 32 байта. В Linux введите ping -c 4 203.0.113.10: без ключа -c 4 проверка идёт непрерывно, пакеты по 64 байта, остановка по Ctrl+C.
3. Прочитайте ответ. В строках смотрите time= (задержка в мс) и ttl= (оставшееся число узлов; начальное значение обычно 128 в Windows и 64 в Linux). В итоге проверьте долю потерь: она должна быть 0%.
4. Выполните трассировку: tracert 203.0.113.10 в Windows или traceroute 203.0.113.10 в Linux и macOS. По умолчанию команда проходит до 30 узлов.
5. Для длинной проверки запустите mtr -r -c 10 203.0.113.10. Утилита mtr выполнит 10 циклов и выдаст отчёт по потерям на каждом узле.
6. Если ответа нет, проверьте брандмауэр сервера: он мог заблокировать echo-запросы (ICMP-тип 8) или ответы (тип 0).
7. После правки правил повторите ping -c 4 203.0.113.10 и сравните результат с первым запуском.

Если проверки показывают проблему на стороне сервера, а причина неясна, найдите ответ в разборе частых вопросов о VPS.

Как читать результаты и какой пинг считается нормальным

В ответе на ping 203.0.113.10 важны три поля. time показывает задержку в миллисекундах (мс): за сколько пакет дошёл до сервера и вернулся. ttl (Time To Live, время жизни пакета) — остаток счётчика узлов; начальное значение обычно 128 в Windows и 64 в Linux, поэтому по нему можно примерно прикинуть число пройденных узлов. В итоговой строке packet loss указана доля потерянных пакетов.

Ориентиры зависят от маршрута: 1–20 мс в пределах города, 20–70 мс внутри страны или Европы, 100–200 мс между континентами. Потери выше 1–2% при проверке 100 пакетов считаются сигналом о проблеме. Один скачок до 300 мс среди ответов по 25 мс обычно случаен, а стабильный рост задержки в течение нескольких минут указывает на перегруженный канал или узел.

В выводе traceroute 203.0.113.10 или mtr -r -c 10 203.0.113.10 ищите узел, на котором задержка выросла и осталась высокой на всех следующих строках. Если скачок виден только в одной строке, а дальше значения вернулись к норме, проблемы нет: узел просто отвечает на ICMP с низким приоритетом.

Что учитывать при разборе:

• Звёздочки * * * на промежуточном узле не всегда ошибка: он может не отвечать на ICMP, но пересылать трафик дальше.
• Звёздочки до конца маршрута означают, что ответа нет совсем: проверьте, не закрыт ли ICMP на сервере.
• Если ping чистый, а сайт не открывается, разберите ошибку 522 и проверьте DNS-адреса.

Частые ошибки при работе с ICMP и как их исправить

Большинство «проблем с ping» возникает из-за неверного чтения ответа. Разберём шесть ситуаций: таймаут, «host unreachable», ping без сайта, сайт без ping, закрытый ICMP целиком и звёздочки в traceroute. Пример везде один: сервер 203.0.113.10.

Сначала определите, что вы проверяете. ICMP (Internet Control Message Protocol) показывает доступность узла в сети, а работу сайта определяет TCP-порт.

«Request timed out»

Ответа нет за отведённое время. Причина: брандмауэр режет echo-запрос (тип 8) или узел недоступен. Проверьте правила на сервере и маршрут командой tracert 203.0.113.10 (Windows) или traceroute 203.0.113.10 (Linux, macOS).

«Destination host unreachable»

Это сообщение ICMP типа 3 от маршрутизатора или от вашей системы. Проверьте адрес, шлюз и маску подсети на своей стороне.

Ping есть, а сайт не открывается

ICMP не проверяет TCP-порты 80 и 443. Убедитесь, что веб-сервер запущен и порты открыты: изучите, как работают порты, и разберите проброс портов, если сервер стоит за маршрутизатором.

Ping не проходит, а сайт открывается

На сервере закрыт echo-ответ. Это нормально и часто сделано намеренно. Проверяйте доступность через порт сервиса.

Закрыт весь ICMP, включая тип 3 код 4

Сообщение «требуется фрагментация» нужно для определения MTU пути (RFC 1191). Без него мелкие запросы проходят, а большие передачи зависают. Разрешите служебные типы 3 и 11, а ограничивайте только тип 8.

Неверный вывод из звёздочек в traceroute

Звёздочка на промежуточном узле означает лишь то, что он не отвечает на служебные пакеты. Если следующие узлы отвечают, проблемы нет. Если звёздочки идут до конца из 30 узлов, запустите mtr -r -c 10 203.0.113.10 и оцените потери: выше 1–2% — повод разбираться.

Сначала выясните, на каком уровне пропал ответ: узел, маршрут или порт. Тогда исправление занимает минуты, а не часы.

ICMP и безопасность: когда разрешать и когда ограничивать ping

ICMP-флуд — вид DDoS-нагрузки (Distributed Denial of Service, распределённый отказ в обслуживании): тысячи echo-запросов в секунду забивают канал и загружают процессор сервера. Кроме того, ответы на ping помогают разведке: по ним злоумышленник находит работающие узлы сети. «Ping of death» с гигантским пакетом давно устарел и в современных системах исправлен. О том, как выглядят настоящие атаки, читайте в материале о DDoS-атаках и защите от них.

Блокировать ICMP целиком не нужно: вы потеряете диагностику и часть сетевых функций. Надёжнее ограничить частоту запросов и открыть только нужные типы сообщений.

Вот основные команды и места настройки:

• iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/second --limit-burst 5 -j ACCEPT пропускает 1 запрос в секунду с запасом в 5 пакетов; следующим правилом с -j DROP отбросьте остальные.
• sysctl -w net.ipv4.icmp_echo_ignore_all=1 полностью отключает ответы; чтобы настройка пережила перезагрузку, добавьте строку net.ipv4.icmp_echo_ignore_all = 1 в /etc/sysctl.conf.
• В ufw (Uncomplicated Firewall) правила ICMP лежат в /etc/ufw/before.rules.
• В Windows разрешите ping командой netsh advfirewall firewall add rule name="ICMPv4 Echo In" protocol=icmpv4:8,any dir=in action=allow.

Не закрывайте ICMPv6 целиком: без него IPv6-сеть перестанет работать. Не блокируйте и тип 3 код 4, иначе соединения начнут зависать из-за ошибок с MTU. Если не хотите настраивать фильтры сами, выберите VPS с готовой защитой сети.

ICMPv6 и другие способы проверить доступность сервера

В IPv6 роль ICMP выполняет ICMPv6 (Internet Control Message Protocol for IPv6). Он описан в RFC 4443 и имеет номер протокола 58. Через него соседние узлы находят друг друга, а отправитель узнаёт MTU (maximum transmission unit, максимальный размер пакета) на пути. Закрыть ICMPv6 целиком нельзя: сеть перестанет работать, поэтому ограничивайте только отдельные типы, например echo-запросы.

Если ping не проходит, сервер не обязательно недоступен: ICMP часто фильтруют. Проверьте сервис напрямую по TCP (Transmission Control Protocol). Для сайта это порт 443, подробнее в материале о порте HTTPS. Если сайт стоит за CDN, на ping может отвечать прокси, а не ваш сервер: изучите настройку Cloudflare.

Выберите способ под задачу и учтите, чего он не покажет:

• nc -zv 203.0.113.10 443 в Linux проверяет, принимает ли порт 443 соединения, но не покажет, исправно ли приложение.
• Test-NetConnection 203.0.113.10 -Port 443 в PowerShell делает то же в Windows.
• curl -I https://example.com запрашивает заголовки и показывает код ответа HTTP, но не оценит качество канала.
• ping проверяет только сетевую доступность узла и ничего не говорит о работе сайта.

Для кого ICMP-проверок недостаточно

Ответ на ping показывает лишь одно: узел доступен по сети. Сайт при этом может не открываться, почта не доходить, а база данных не принимать подключения. Веб-сервер слушает TCP-порт 80 или 443, у ICMP портов нет, поэтому ping эти службы не видит.

Поэтому проверяйте то, ради чего вы берёте сервер. Для сайта запросите страницу по HTTPS, для почты откройте порт 25 или 587, для базы данных проверьте порт службы, например 3306 у MySQL. Нагрузку на процессор и диск ping тоже не покажет, как и скорость канала: для неё нужен отдельный замер в мегабитах в секунду. Систему мониторинга удобно строить на проверках портов и сервисов, пример разбирает материал о Zabbix в блоге.

Молчание в ответ на ping не всегда означает поломку. Многие провайдеры и администраторы намеренно отключают echo-ответы, например через net.ipv4.icmp_echo_ignore_all=1. Если ping не проходит, а сайт открывается и порт 443 отвечает, узел работает, просто скрывает себя от эхо-запросов.

Перед покупкой сервера сделайте следующее:

• проверьте задержку до площадки командой ping -c 4 203.0.113.10, подставив адрес из описания тарифа или тестовый адрес хостера;
• запустите mtr -r -c 10 и посмотрите потери по маршруту;
• используйте тестовый период, если он есть, и проверьте реальные сервисы под вашей нагрузкой.

Подобрать площадку под задачу поможет раздел о выборе VPS.