Вопрос или проблема
Отладка программной проблемы привела меня к состоянию, когда попытка установить TCP-соединение выдала сообщение об ошибке “Нет маршрута к узлу”. Это было особенно запутано, так как ping не имел таких проблем:
# netcat -v 172.20.2.24 5565
netcat: подключение к 172.20.2.24 порт 5565 (tcp) не удалось: Нет маршрута к узлу
# ping 172.20.2.24
PING 172.20.2.24 (172.20.2.24) 56(84) байт данных.
64 байта от 172.20.2.24: icmp_seq=1 ttl=63 время=0.466 мс
64 байта от 172.20.2.24: icmp_seq=2 ttl=63 время=0.470 мс
^C
--- статистика ping для 172.20.2.24 ---
2 пакета передано, 2 получено, 0% потеря пакетов, время 1020мс
rtt min/avg/max/mdev = 0.466/0.468/0.470/0.002 мс
В конце концов выяснилось, что firewalld на целевом узле заблокировал порт (т.е. не разрешил его).
Тем не менее, согласно моей памяти, я думал, что заблокированный трафик будет либо
- исчезать в “черной дыре”, в конечном итоге вызывая тайм-ауты соединения, либо
- вызывать ошибку, такую как “соединение отклонено” или “сброс соединения”
но не “нет маршрута к узлу”.
Так что мне интересно:
Было ли недавнее изменение или это просто ошибка где-то (создается неправильное сообщение об ошибке)?
Система, о которой идет речь, это SLES15 SP6 на x86_64, работающая под управлением ядра Linux 6.4.0-150600.23.25-default и firewalld-2.0.1-150600.3.2.1.noarch.
Также между инициатором и целью находится один шлюз (на случай, если это может изменить код ошибки).
Дальнейшие мысли
Согласно ответам до сих пор, источник кода ошибки, похоже, ICMP (Протокол управления интернет-сообщениями), как определено в RFC 792.
Для “type=3” (Назначение недоступно) есть четыре различных “кода”, связанных с этой проблемой:
- 0: “сеть недоступна”
- 1: “узел недоступен”
- 2: “протокол недоступен”
- 3: “порт недоступен”
Так что я бы предположил, что “code=3” был бы правильным, но “Нет маршрута к узлу” похоже указывает на то, что используется “код=1”.
Смотрите также “Назначение недоступно” в “Протоколе управления интернет-сообщениями” (Wikipedia).
Это не ошибка, а эффект конфигурации брандмауэра. Сообщение “нет маршрута к узлу” связано с тем, что брандмауэр отказывает в доступе с помощью сообщения ICMP (цель: ОТКЛОНЕНИЕ), а не просто отбрасывает пакет (цель: УДАЛЕНИЕ).
Поскольку команда ping правильно достигает удаленного узла, “нет маршрута к узлу” не связано с отсутствием маршрута.
Смотрите также: Нет маршрута к узлу с nc, но можно пинговать
Как указывает этот ответ Superuser, рассмотренный firewalld был настроен не просто сбрасывать пакеты, направленные на порт 5565, а возвращать ответ ОТКЛОНЕНИЕ, который принял форму сообщения об ошибке ICMP. Сообщения ICMP довольно общие, так что описание ошибки не было “Firewalld блокирует ваш трафик”, а скорее “Нет маршрута к узлу”.
Брандмауэры часто настраиваются так, чтобы не беспокоиться о возврате ответа об отказе. Чаще всего трафик просто молча отбрасывается. Вот это вы описали как “исчезает в ‘черной дыре'”.
Когда брандмауэры и другие сетевые устройства позволяют трафику достичь целевого узла, но на TCP-порту никто не слушает, TCP-стек на целевом узле обычно возвращает ответ об ошибке TCP. Эта ошибка TCP имеет описание “Соединение отклонено”.
Ответ или решение
Когда вы сталкиваетесь с ошибкой "No route to host" при попытке установить TCP-соединение, а команда ping успешно выполняется, это может вызвать путаницу. Рассмотрим этот вопрос подробно, начиная с сути проблемы и заканчивая возможными решениями.
Анализ проблемы
На первый взгляд, ситуация выглядит противоречиво. Вы можете отправить ICMP-пакеты при помощи команды ping, и они достигают целевого хоста, тогда как TCP-подключение, инициируемое с использованием netcat (или любого другого инструмента), завершается с ошибкой "No route to host". Это предполагает, что проблема связана с маршрутизацией, но при этом пакеты ICMP успешно проходят.
Причины возникновения ошибки "No route to host"
Как выясняется, сообщение об ошибке "No route to host" может возникать в результате конфигурации брандмауэра, который управляет сетевым трафиком. В вашем случае, firewalld на целевом хосте был сконфигурирован так, чтобы отклонять входящие пакеты на порт 5565, не просто игнорируя их, а возвращая ICMP-сообщение о недоступности хоста.
Когда firewalld отклоняет пакеты, вместо того чтобы просто их сбрасывать (DROP), он выдает ICMP-сообщение с кодом ошибки, который может указывать на недоступность порта или хоста. Несмотря на то, что между инициатором и целевым хостом есть маршрутизация, ICMP-сообщение о недоступности создает иллюзию, что хост не находится в сети.
Делая выводы
В вашем случае, firewalld, вероятно, был настроен на реагирование с помощью ICMP-сообщений типа "Destination Unreachable". Это приводит к тому, что вместо стандартного сообщения о том, что соединение отклонено, вы получаете менее информативное сообщение "No route to host". Это сообщение зачастую используется во многих системах для обозначения неполадок на уровне сети, даже если проблема на самом деле является результатом конфигурации брандмауэра.
Рекомендации
-
Проверка конфигурации firewalld: Убедитесь, что порты, необходимые для вашего приложения, открыты и правильно настроены. Вы можете использовать команду
firewall-cmd --list-allдля просмотра текущих правил. -
Изменение политики брандмауэра: В случае, если вы хотите, чтобы трафик на закрытых портах просто игнорировался (DROP), измените настройки firewalld так, чтобы он не выдавал ICMP-сообщения.
-
Тестирование: Всегда проверяйте изменения, используя telnet или netcat, чтобы убедиться, что соединения работают, как ожидалось.
Заключение
Ошибка "No route to host" при блокировке firewalld — это не баг, а следствие особенностей конфигурации брандмауэра. Правильная настройка и тестирование правил брандмауэра могут помочь избежать путаницы и быстро найти решения проблем, связанных с сетевой доступностью.
Совмещение технической информации с практическими рекомендациями поможет вам и вашей команде лучше понять поведение сетевых приложений и устранять возникающие проблемы быстрее.