Исправить «No route to host» в Linux

Если в Linux при подключении вы видите «No route to host», это значит, что ваш компьютер не может достучаться до целевого сервера. Быстрая методика: 1) проверьте, что сервис запущен; 2) убедитесь в доступности порта и корректности DNS; 3) проверьте правила брандмауэра (iptables/ufw) и конфигурации сети; 4) используйте пошаговый чеклист ниже и при необходимости — следуйте процедуре отката.

Сообщение «No route to host» на экране

Когда при попытке подключиться к сервису в Linux вы видите сообщение «No route to host», это означает одно — ваш компьютер не может соединиться с целевым хостом. Это может быть как локальная служба на вашей машине, так и удалённый сервер. В статье разберём причины, пошаговые проверки и методы устранения ошибки.

Основные причины ошибки

Ошибка имеет широкий спектр причин: от отключённого сервиса до проблем на уровне маршрутизации, DNS или брандмауэра. Ниже — типовые категории и быстрые проверки.

1. Хост выключен или сервис не запущен

Первое и самое очевидное — проверьте, доступен ли сам сервер и запущена ли целевая служба.

Статус службы systemctl на сервере

Если у вас Systemd, проверьте статус сервиса командой:

sudo systemctl status SERVICENAME

Если сервис не запущен — запустите и посмотрите журналы:

sudo systemctl start SERVICENAME
sudo journalctl -u SERVICENAME -n 200 --no-pager

Короткое объяснение: systemd — менеджер сервисов в большинстве современных дистрибутивов Linux.

2. Неправильный порт

Возможно, вы пытаетесь подключиться к неправильному порту. Часто администраторы меняют стандартные порты (например, SSH) из соображений безопасности.

Сканирование портов с помощью nmap поможет быстро найти открытые порты:

sudo nmap -sS your.server.ip

Для полного сканирования всех портов используйте флаг -p- (будет дольше):

sudo nmap -sS -p- your.server.ip

3. iptables/брандмауэр блокирует соединение

Правила сетевого фильтра могут блокировать входящие или исходящие соединения. Проверьте правила iptables (или nftables/ufw/firewalld в зависимости от системы).

sudo iptables -S
sudo nft list ruleset
sudo ufw status verbose

Если правило блокирует нужный порт, временно отключите правило или добавьте разрешающее правило и проверьте соединение снова.

4. Проблемы с DNS

Иногда вы видите ошибку при попытке подключения по имени, хотя IP доступен. Проверка ping по IP и по имени покажет различие.

ping -c 3 your.server.ip
ping -c 3 example.domain.tld

Если ping по IP работает, а по доменному имени — нет, то проблема в DNS. Для Systemd-resolved:

systemd-resolve --status

Файл конфигурации Systemd:

/etc/systemd/resolved.conf

Пример записи DNS в resolved.conf:

DNS=192.168.1.1
FallbackDNS=8.8.8.8 8.8.4.4

В системах без systemd проверьте /etc/resolv.conf и добавьте, при необходимости:

nameserver 192.168.1.1

После изменения конфигурации перезапустите сетевые службы или систему.

5. Неправильная конфигурация сети или хостов

Проверьте локальные конфигурационные файлы, которые могут перенаправлять или блокировать соединения:

/etc/hosts — локные сопоставления имён и IP
/etc/hosts.allow и /etc/hosts.deny — правила TCP Wrappers

Содержимое /etc/hosts, пример

Также убедитесь, что сетевой интерфейс настроен корректно: IP, маска, шлюз.

Пошаговая методика (мини-методология для расследования)

Сформулируйте контекст: локальная машина или удалённый сервер? Какой IP/домен и порт? Когда началась проблема?
Проверка доступности хоста: ping по IP.
Проверка доступности порта: nmap или telnet/netcat.
Проверка сервиса на целевой машине: systemctl, журналы.
Проверка правил брандмауэра: iptables/nft/ufw.
Проверка DNS: systemd-resolve / /etc/resolv.conf.
Проверка локальных хостов и TCP Wrappers.
Если всё в порядке, проверьте маршрутизацию (route / ip route).

Пример команды для проверки маршрутизации:

ip route show
ip -4 route get your.server.ip

Если маршрут до адреса не существует, добавьте нужный маршрут или настройте шлюз.

Диагностическая схема (flowchart)

flowchart TD A[Начало: «No route to host»] –> B{Можно ли пропинговать IP?} B – Да –> C{Порт открыт? (nmap/tc)} B – Нет –> D[Проверить локальную сеть/кабель/Wi‑Fi] C – Да –> E[Проверить приложение/сервис на сервере] C – Нет –> F[Проверить брандмауэр и маршрутизацию] D –> G[Проверить IP интерфейса, шлюз, маршрут] F –> H[Проверить iptables/nft/ufw и правила провайдера] E –> I[Проверить логи сервиса и SELinux/AppArmor] G –> H H –> J{Проблема найдена?} I –> J J – Да –> K[Исправить и проверить] J – Нет –> L[Связаться с админом/провайдером]

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

Роль‑ориентированные чеклисты

Чеклист для администратора сервера:

Проверить статус службы и логи (systemctl, journalctl).
Убедиться, что служба слушает на нужном интерфейсе (ss -tulpn / netstat -tulpn).
Проверить правила брандмауэра на сервере (iptables/nft/ufw/firewalld).
Проверить SELinux/AppArmor — нет ли ограничений.
Проверить маршрутизацию на сервере (ip route).
Проверить, не блокирует ли облачный провайдер порт на уровне сети.

Чеклист для пользователя/администратора рабочего места:

Проверить сетевой интерфейс и шлюз (ip addr, ip route).
Проверить DNS (systemd-resolve --status или /etc/resolv.conf).
Пропинговать IP и имя хоста.
Использовать nmap/ss/telnet для проверки порта.
Проверить локальные правила брандмауэра.
Проверить /etc/hosts на конфликтные записи.

SOP/Playbook: быстрый план действий (шаги для воспроизводимого устранения)

Соберите базовую информацию: исходный IP, целевой IP/домен, порт, время ошибки.
Выполните ping по IP и по имени. Запишите результаты.
Сканируйте порт: sudo nmap -sS -p <порт> <хост> или nc -vz host port.
На сервере: sudo systemctl status SERVICENAME, ss -tulpn | grep :<порт>.
Проверьте брандмауэры: sudo iptables -S, sudo nft list ruleset, sudo ufw status.
Если проблема в DNS — смените DNS на известный (например, 8.8.8.8) временно и проверьте.
Если изменения вносятся в правила брандмауэра или маршрут, делайте это последовательно и документируйте.
После исправления — прогоните тесты: ping, подключение к порту, тест приложения.
Если не устранено — откатите последние конфигурационные изменения и свяжитесь с провайдером/командой сети.

Примеры тест-кейсов и критерии приёмки

Критерии приёмки:

Приложение успешно подключается к целевому хосту по заданному порту в течение 5 секунд.
Ping по IP получает ответ в пределах 200 ms (локальная сеть) или приемлемое время для WAN.
nmap показывает целевой порт в состоянии “open”.

Тест-кейсы:

TC1: Ping по IP — ожидается ответ. Результат: PASS/FAIL.
TC2: Подключение к порту с клиента (nc/telnet) — ожидается установленное соединение.
TC3: Проверка DNS: разрешение имени в IP с помощью dig или host — ожидается верный IP.
TC4: Проверка брандмауэра: временно отключить правило и повторить TC2.

Альтернативные подходы и когда они не работают

VPN: если маршрут между сетями отсутствует, временное подключение по VPN может помочь, но если проблема в DNS или на стороне сервера, VPN не решит проблему.
Прямой тест с другого хоста: помогает определить, проблема локальна или на стороне сервера/провайдера.
Перезапуск сетевых служб и системы: обычно решает проблемы с временной конфигурацией, но не исправит системные ошибки конфигурации.

Когда перечисленные подходы не работают — вероятно, проблема на уровне провайдера, облачного firewall или аппаратных сетевых устройств (маршрутизатор, коммутатор).

Безопасность и ограничения

Не открывайте порты без необходимости. Если временно добавляете правило в брандмауэр для теста, удалите его после проверки.
Проверяйте логи безопасности (auditd, fail2ban) — резкие изменения могут указывать на атаку.
Для публичных серверов предпочтительнее использовать ограниченные правила доступа (IP‑белые списки) и VPN.

Частые ошибки и ловушки (edge-case gallery)

Неправильный интерфейс: служба слушает только на localhost (127.0.0.1), а не на внешнем интерфейсе.
Конфликты в /etc/hosts: запись с неверным IP для домена.
Провайдер блокирует порт на уровне сети (часто для SMTP/25 или нестандартных портов).
Маршрутизатор NAT неправильно пробрасывает порты или неправильно настроен DMZ.

Короткий словарь (1‑строчные определения)

DNS — система доменных имён, переводит имена в IP.
nmap — инструмент для сканирования портов и сети.
iptables/nft — системы фильтрации пакетов в Linux.
systemd — менеджер системных служб и демонов.

Краткое резюме

“No route to host” означает отсутствие маршрута или блокировку на каком-то уровне сети.
Начните с простых проверок: ping, nmap, статус сервиса, правила брандмауэра и DNS.
Используйте пошаговый SOP, документируйте изменения и выполняйте откат в случае необходимости.

Важно

Если вы не уверены в влиянии изменений на публичный сервер — выполняйте тесты в рабочее окно и имейте план отката.

Примечание

Если проблема возникает периодически, ведите журнал времени и условий возникновения — это поможет выявить закономерности и связать проблему с задачами обслуживания или нагрузкой.