CH-J Server Managerуправление на сървъри над SSH
Меню
Всички ръководства и статии →

ping е неуспешен, но SSH и HTTPS работят: защо и проблем ли е това?

Защо сървърът може да игнорира ping и все пак да работи нормално, как да тествате услугите директно и кога блокираният ICMP причинява реални неизправности.

Защо се случва това

ping използва ICMP, а SSH и HTTPS използват TCP портове. Това са отделни потоци трафик и защитната стена може да отхвърля единия и да пропуска другия. Много мрежи и облачни групи за сигурност блокират ICMP echo по подразбиране. Затова липсата на отговор не означава, че сървърът не работи, а полученият отговор не доказва, че услугите му работят.

Тествайте услугата, а не ping

Проверете портовете и протоколите, които действително са ви нужни. Ако тестовете са успешни, сървърът е достъпен за тези услуги, а неуспешният ping показва само филтър някъде по пътя.

nc -vz -w 5 server.example 22
nc -vz -w 5 server.example 443
curl -sSI https://server.example/

Проследете пътя с TCP

Обикновеният traceroute може да показва само звездички, когато ICMP или UDP се филтрира. С TCP към отворен порт често можете да стигнете по-далеч. Това изисква права на root, а traceroute може да се наложи първо да бъде инсталиран, защото минималните системи не го включват.

sudo traceroute -T -p 443 server.example

Потърсете филтъра на сървъра си

Ако управлявате сървъра, проверете защитната му стена и настройката на ядрото, която игнорира echo заявки. Помнете, че блокирането може да е и извън сървъра, в група за сигурност или маршрутизатор, и че доставчикът може да филтрира ICMP в мрежата си, без да виждате правило за това.

sysctl net.ipv4.icmp_echo_ignore_all
sudo nft list ruleset | grep -i icmp
sudo ufw status verbose

Кога блокираният ICMP действително причинява неизправности

Блокирането на echo обикновено е безвредно, но блокирането на целия ICMP не е. Откриването на MTU по пътя разчита на съобщенията за прекалено голям пакет. Без тях малките обмени работят, а големите блокират, например когато влизането през SSH е успешно, но след това сесията блокира при обемен изход. IPv6 зависи от ICMPv6 още повече. Втората команда тества път за MTU от 1500 байта под Linux.

ip route get 192.0.2.10
ping -M do -s 1472 -c 3 192.0.2.10

Сравнение в CH-J Server Manager

Server Diagnostics изпълнява ping чрез системния инструмент, без права на root, наред с отделни тестове за TCP, SSH идентификация, HTTP и TLS, така че неуспешният ping да се разглежда в контекст. Неуспешният ping там означава, че не е пристигнал отговор. Той не показва къде е отхвърлен пакетът и traceroute също може да не даде отговор на този въпрос.

Подробна документация

RFC 4890: ICMPv6 filtering →

man: ping →

Биометрични отключване и сигурност →