Linux telnet no route to host

Почему ping видит хост, а telnet — нет?

Потому что пинг это ICMP, а телнет это TCP. Телнет подключается к порту по ip адресу, а ты его не указал

А что ты вообще делаешь? Куда хочешь подключиться?

У меня на 10.0.0.2 стоит вебсервер на порту 8811, хочу к нему подключиться телнетом

А правила firewall?

Так ты только filter показываешь. Выхлоп iptables-save покажи.

Теперь ты правильно пишешь, а то что порт закрыт — это фиревале проблемы. Если это CentOS, выключи его командами

Да, если его остановить то всё хорошо. Неясно что с ним не так.

Может ему не хватает ещё одного правила про RELATED, ESTABLISHED?

не смущает что в айпитэйбле не тот адрес? (:

Покажи выхлоп ip r l до и после остановки firewalld.

А какая разница? Там политика ACCEPT.

вижу только icmp

ip явно не сервера, ну как так? (: правда я могу в глаз долбиться, пятница, вечер

А я не смотрел туда, и сейчас не стану)

Смущает, но я его переписал на 10.0.0.2, ничего не поменялось. И вообще он для ping, а не для tcp

Ну это вопрос уже как настроить файервол, потрудись найти мануал и настроить

ну и как так, секция output для пакетов сформированных сервером, а у тебя там только icmp. остальному не положено да ? (:

Политика таблицы filter цепочки OUTPUT и INPUT — ACCEPT. Т.е. глубоко пофигу, каки там разрешающие правила и с какими адресами. Всё разрешено уже на уровне политики.

Если бы это было так, то запуск firewalld не блокировал бы работу с портом

А я тебе выше написал, что ещё надо посмотреть.

я сравнил и не увидел разницы

Значит ты что-то не то скопипастил. В твоём iptables-save всё разрешено.

Покажи тогда iptables -nvL до и после остановки фаера.

Еще не советовали?

Ну и там много ещё всего, но мне кажется, что оно не интересное. Пинги ведь ходят?

У меня все правила слетели уже́.

Работает — это значит, что пингуется в любом случае, а телнетом коннектится только если firewall не запущен.

интересен diff с включенным и выключенным.

Нет разницы

вставляй логирующие правила и смотри где он проходит по цепочкам

REJECT может быть не только в таблице filter, к слову. Так не рекомендуют делать, но от этого работать оно не перестает

-j TRACE в помощь

Так вроде уже все цепочки просветили. Или нет? Я на всякий случай прочитал статью https://www.cyberciti.biz/faq/how-to-list-all-iptables-rules-in-linux/

но как обычно ничего не понял. Я не вижу ни одного REJECT.

REJECT может быть не только в таблице filter

1. выше есть выхлоп iptables-save, где все таблицы
2. получаем no route to host, а в случае reject должно быть Connection refused (а в случае DROP — connection timeout)

помогло вот это:
# firewall-cmd —zone=public —add-port=8811/tcp
success

Но я так и не понял, что это такое было.

«It uses nftables by default.»

получаем no route to host, а в случае reject должно быть Connection refused

Что, даже если там —reject-with icmp-host-prohibited ?

Сдаётся мне у тебя конфликс nftables и iptables. Выбери что-то одно и настраивай через него. Да, они оба работают через Netfilter, но на ЛОРе уже были посты о том, что смешивать управление этими двумя утилитами чревато.

А у тебя еще и firewalld там, надо смотреть через что работает он.

А telnet: Unable to connect to remote host: No route to host не смущает?

вот тут написано что смущать не должно, это нормально, так и должно быть.

Источник

Ошибка «Нет маршрута к хосту» в Linux — что делать

Сталкивались ли вы с «No Route to Host» при попытке получить доступ к серверу в Linux? Эта ошибка подключения к услуге может раздражать, но вы можете исправить ее, как только определите причину.

«No Route to Host» (Нет маршрута к хосту) обозначает проблему в сети, обычно возникающую, когда сервер или хост не отвечает. Это может произойти из-за проблем с сетью или из-за неправильной настройки.

Правильны ли настройки вашей сети?

Прежде чем мы рассмотрим более конкретные причины этой проблемы, убедитесь в правильности настроек вашей сети. Можете ли вы подключиться к сети? Ваш DNS правильно настроен?

Запустите эту команду, чтобы узнать:

Если вы обнаружите там какие-либо проблемы с DNS, вернитесь к конфигурации вашей сети и, если потребуется, повторите ее. Если вы используете стандартную сеть с динамическим IP, номера DNS должны обновляться автоматически.

Чтобы вручную настроить DNS, перейдите в Network Manager и вручную введите IP-адрес на вкладке IPv4.

Если в вашем дистрибутиве Linux нет графического рабочего стола, перейдите в «/etc/systemd/resolved.conf» и найдите строку DNS.

Измените номера на номера DNS, которые вы хотите, и при необходимости сделайте другие конфигурации.

Кроме того, если вы настроили статический IP-адрес, вы можете захотеть вернуться к динамическому IP-адресу и разрешить вашей сети получать информацию о соединении через DHCP.

Не забудьте перезагрузить компьютер, прежде чем пытаться снова подключиться к хосту. Если вы по-прежнему получаете «No Route to Host», продолжайте читать.

Хост-сервер подключен к сети?

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

Если служба не в сети, проверьте, есть ли хост. Иногда служба может быть остановлена ​​или не запущена с самого начала, даже если с самим сервером все в порядке.

Используя systemd, запустите команду…

sudo systemctl status servicename

Если служба работает, вам нужно искать другую причину.

Вы подключаетесь к нужному порту?

Дважды проверьте любую документацию, которую может предоставить хост. Обычно администраторы серверов блокируют порты, которые не используются для повышения безопасности сервера. Злоумышленники часто используют общие порты для нацеливания на службы Linux.

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

Вот команды для установки NMAP в разных дистрибутивах Linux:

CentOS: ням установить nmap

Debian: apt-get установить nmap

Ubuntu: sudo apt-get установить nmap

После установки NMAP проверьте наличие открытых портов с помощью следующей команды:

sudo nmap -sS target-server-ip

Если у вас нет прямого доступа к серверу, вам придется связаться с хостом. Но прежде чем сделать это, рассмотрим некоторые другие возможные причины ошибки «No Route to Host» в Linux.

Правильно ли указано имя хоста?

Вы также можете получить ошибку «No Route to Host», если ваш компьютер и сервер, к которому вы пытаетесь подключиться, используют разные имена хостов. Обе машины должны быть настроены на соединение друг с другом.

Помимо обычной конфигурации хостов, вы должны обратить внимание на файлы hosts.deny и hosts.allow в «/ etc». Если вы пытаетесь подключиться к новому серверу, убедитесь, что вы правильно указали имя хоста сервера.

Iptables блокирует соединение?

iptables очень полезен, когда вы хотите настроить таблицы брандмауэра ядра Linux. Полный контроль над трафиком, который входит и выходит из вашего компьютера, великолепен.

Но из-за простой ошибки конфигурации iptables может заблокировать соединение с портом, к которому вы хотите подключиться, и вызвать ошибку «No Route to Host».

Чтобы проверить, виноват ли iptables, выполните следующую команду:

sudo iptables -S

Посмотрите, блокируют ли установленные вами правила iptables соединение. Возможно, вам придется добавить правило принятия в цепочку INPUT по умолчанию.

Чтобы очистить правила брандмауэра для внешнего брандмауэра, вы можете использовать эту команду:

Заключительные мысли

Как видите, может потребоваться некоторое время, чтобы добраться до сути ошибки «No Route to Host», но описанные выше шаги должны помочь вам. Хотя это может выглядеть как сложная проблема, часто это является результатом конфликтующих конфигураций или простых сетевых проблем.

Вы сталкивались с другими потенциальными причинами и исправлениями этой ошибки? Оставьте нам комментарий и расскажите нам об этом.

Источник

Oracle Labs by Yuri Khazin, Oracle DBA

Experimenting with Oracle technology

Linux 6.7 telnet: connect to address x.x.x.x: No route to host

You are trying to connect with telnet to a freshly unwrapped Red Hat Linux 6.7 (or a derivative, such as Oracle OEL). Why would you use such a commonly despised tool as telnet begs an explanation. Well telnet is still a useful diagnostics tool, sometimes you need to check if you can talk to a web server, to a mail server or, in our case, to Oracle listener on a particular port. And you may run into an interesting problem while trying (other than a fact you need to install telnet binaries as it is not usually included).

So you can ping the other host (which is a Linux 6.7), you can even ssh to it, but the telnet will give you “No route to host” message.

Since ping and ssh do work you rule out the gateway settings (/etc/sysconfig/network) on the client side, the routing table or client side firewall (well, it still could be just it). But a quick check on the target side will show that it’s indeed firewall issue. When you shut down the target’s firewall the telnet message will change to “Connection refused” that is, if you attepmpt to talk to a port where no process is listening. Telnet to a port 1521 returns Oracle listener response. Picture below illustrates just that.

So what to do now? We need to add a rule to the firewall on the target side for a particular protocol and port. For instance, port 1521 for Oracle’s listener. Here are the ‘out of the box’ rules:

Last rule in the INPUT chain is a reject rule. Adding more rules after it is pointless, the new rule has to be added before the ‘reject’.

iptables -I INPUT 5 -m state –state NEW -m tcp -p tcp –dport 1521 -j ACCEPT

This command will add a rule at a position 5 in the INPUT chain, pushing the last rule to position 6. That’s it. Save the iptables current configuration so it is preserved through reboot.

Источник

no route to host

Есть удалённый CentOS на котором поднят httpd с дефолтными настройками.
Когда писал в браузере его ip попадал на страничку апача.
А сейчас даже при телнете показывает:

Видимо, пропал маршрут до хоста.

То есть виноват провайдер ?

а с других машин?

И с работы и из дома такая ситуация.

т.е. на сервере wget -O — localhost:80 всё ок?

На сервере я могу elinks-ом странички просматривать.
вывод wget -O — localhost:80 на сервере:

а почему это connection refused? o0

Подумал что из-за iptables (хотя там ничего особенного), отключил и заного проверил. Такой же вывод.

Ну хотя бы минимум вывод tcpdump с сервера для приличия можно было выложить, а? SYN-ы доходят?

у тебя апач-то не сдох вообще?

Что в логах апача? попробуй его рестартануть.

Для исключения вероятности того, что причастен провайдер: nc -l -p 80 на сервере, telnet server_ip на клиенте. После коннекта на клиенте можно набрать любую строку, если на сервере она появится в той консоли, где делали nc, то виноват не провайдер, а апач.

На всякий случай: nc — из пакета netcat, синтаксис в разных версиях разный (кажется, ключ -p требуется не везде).

В логах апача всё тоже норм.
Он не подыхал
Рестарт апача тоже не помог =(

выхлоп с сервера:

Найди от какого именно роутера тебе приходит сообщение об отсутствии пути (мониторь на клиенете icmp, должно придти сообщение с типом 3). Если приходит от роутера провайдера, тогда он и виноват. По крайней мере, можно это предьявить техподдержке.

погоди, ты апач то остановил перед запуском nc. Хотя можешь для начала проверить не на 80м, а на 81м порту, или 8080 (частные случаи любого свободного порта). Посмотри, кто использует 80й порт в настоящее время. Попробуй перенастроить апач на другой порт, не 80й, а хотя бы на тот же 8080.

Выше писал же, что первым делом надо сделать.

Из предположения, что провайдер блокирует 80 порт, тот факт, что он блокирует другие порты, потенциально служащие для http явно не следует, так что лучше и правда апач остановить.

Это ты сделал замену server_ip на свой айпишник сервера, а в выхлопе обратную замену, или прямо так и написал «server_ip»? Скорее первый вариант, иначе бы тебе ответили «name or service nbt known».. На всякий случай — надо туда подставить реальный айпшиник.

Второй момент (ошибся немного) — порт по умолчанию у телнета 23, так что следует указать на клиенте, на какой порт соединяешься — telnet server_ip 80.

Источник